On 21 October 2026, two critical vulnerabilities in PHP prompted urgent security warnings, with organisations being advised to update their systems immediately or consider taking them offline until the risks could be addressed.
At EM360Tech, we made the decision to temporarily take our website offline as a precaution while our technical team worked through the security concerns. It wasn't ideal timing, particularly with our Impact Index Awards campaign underway. But leaving the website accessible while potentially serious vulnerabilities remained unresolved wasn't a risk we wanted to take.
The warnings concerned two flaws that could allow attackers to run malicious code on affected web servers without needing to log in. And although the technical details aren't particularly straightforward, understanding what went wrong helps explain why a software security warning can have such an immediate effect on a business.
What Is a CVE?
You've probably seen CVE numbers mentioned in cybersecurity news before, usually alongside reports of newly discovered security flaws. They're the identifiers used to keep track of known vulnerabilities in software and hardware. CVE stands for Common Vulnerabilities and Exposures.
The CVE Programme assigns a unique identifier to each vulnerability so that security researchers, software vendors and IT teams can be sure they're discussing the same problem. Each identifier follows a standard format: CVE, the year and a unique number.
So CVE-2026-109618 identifies a specific vulnerability recorded in 2026, while CVE-2026-109619 refers to a separate flaw. The identifier itself doesn't tell you how dangerous the vulnerability is, though. For that, security teams can look at its CVSS score, which stands for Common Vulnerability Scoring System.
According to the FIRST CVSS framework, vulnerabilities are assessed using factors such as how an attack could happen, whether special conditions are needed and what damage exploitation could cause. Scores range from zero to 10, with higher numbers indicating greater severity.
Both PHP vulnerabilities received CVSS v4.0 scores of 9.2, placing them in the critical category. That's a serious warning, although the score doesn't tell us whether a particular website is vulnerable or has already been attacked.
What Are the Critical PHP Vulnerabilities?
PHP is a programming language used to make websites work behind the scenes. It helps websites retrieve information from databases, process forms, manage user sessions and generate the pages visitors see.
It's also used by content management systems and other web applications, which means a vulnerability in PHP itself can affect far more than one website or plugin. The two vulnerabilities disclosed on 21 October affect how PHP handles information in a server's memory.
Both can potentially lead to remote code execution (RCE), which means an attacker could make an affected server run instructions of their choosing from somewhere else, without having legitimate access to the system. That's a particularly serious form of security weakness.
Depending on the access available to the compromised process, malicious code could interfere with website operations, access information or be used as a starting point for further attacks.
CVE-2026-109618
The first vulnerability involves what happens when PHP runs out of memory while processing a request. Servers have limits on how much memory individual processes can use. When PHP reaches one of those limits, it needs to stop the affected operation and clean up safely.
According to PHP's official advisory for CVE-2026-109618, certain out-of-memory errors could interrupt that process before PHP had properly prepared the information it was using. The server could then attempt to work with memory that was in an invalid state.
Researchers demonstrated that an attacker could deliberately trigger this behaviour and achieve remote code execution on servers using Apache with mod_php, even before the website's own application code starts running.
Other PHP server configurations may also be affected, although the advisory distinguishes between demonstrated attacks and configurations where the risk was identified through technical analysis.
CVE-2026-109619
The second vulnerability also involves memory handling, but the problem occurs when PHP continues referring to information after the memory holding it has been released. This is known as a use-after-free vulnerability. Normally, once a program has finished using a piece of memory, it should stop referring to it.
But if an old reference remains, the program might try to use information that no longer belongs to the original operation. PHP's advisory for CVE-2026-109619 explains how information left behind by one web request could be accessed during another. Under the right conditions, an attacker could manipulate that behaviour to execute malicious code.
The exact exposure depends on the PHP version, server setup and other technical conditions. Still, both vulnerabilities are serious enough that organisations running PHP need to establish whether their systems are affected.
How Can Organisations Protect Their PHP Websites?
The UK's National Cyber Security Centre issued an alert advising organisations to identify systems running PHP, prioritise those accessible from the internet and prepare to apply the security updates as soon as they became available. The first step is knowing where PHP is being used.
That includes the main website, but it may also cover applications, services and third-party products that organisations don't immediately associate with PHP. Once those systems have been identified, IT teams need to check their versions against the affected releases and establish which updates are required.
On 21 October, the PHP development team released security patches in versions 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Organisations using PHP 8.1 or earlier won't receive fixes for these vulnerabilities through the official PHP project, so they'll need to move to a supported version. Installing the correct update is essential.
PHP's own guidance makes clear that updating is the only complete fix for these vulnerabilities. But updating a live website also means checking that everything still works afterwards. A change to the underlying software can affect applications and services that depend on it, particularly when an organisation is upgrading from an older version.
That could mean checking whether pages load correctly, visitors can navigate the website, forms submit successfully and content can still be published through the CMS. Integrations, embedded resources and other business-critical features may also need testing. These are examples of the checks organisations might carry out, rather than a description of EM360Tech's internal testing.
The Google Cloud technical guidance also stresses the importance of updating deployed applications and rebuilding services where necessary, so they're actually running the patched PHP version. If an organisation can't apply the update immediately, the NCSC advises considering taking the affected system offline until the risk can be addressed.
Why Did EM360Tech Take Its Website Offline?
For EM360Tech, the decision was to temporarily take our website offline while our technical team addressed the potential security risks. We weren't responding to a confirmed breach, and the shutdown shouldn't be taken as evidence that our website had been exploited. It was a precautionary decision in response to a serious security warning.
The concern was what could happen if an affected system remained accessible before the necessary security work had been completed. With vulnerabilities that potentially allow remote code execution, the consequences of getting that decision wrong can extend well beyond a temporary interruption to the website.
Of course, taking a website offline comes with its own problems, particularly for a business like ours. Our website is where readers access our technology news, expert insights, podcasts, whitepapers and other resources. It's also an important part of how we connect enterprise technology professionals with the content and opportunities they're looking for.
When that website becomes temporarily unavailable, readers can't access those resources in the usual way. Anyone arriving through a search result, shared article or campaign link may find that the page they wanted isn't available. For our editorial team, there's also the question of organic search traffic.
Depending on how an outage is handled and how long it lasts, website downtime could affect search visibility, although we don't have confirmed figures showing that this happened. Then there's our Impact Index campaign. We were in the middle of promoting the awards when the shutdown happened, so the timing couldn’t have been much worse if we’d planned it.
People following campaign links might not have been able to access the relevant pages, and opportunities for engagement could have been interrupted. For an organisation that depends on its website for publishing, audience engagement and lead generation, even a precautionary shutdown has implications beyond the technical team.
But there's a difference between a temporary interruption that an organisation chooses to manage and the potential consequences of leaving a serious security risk unresolved. Our decision reflects that distinction. The technical team needed the opportunity to address the vulnerabilities and establish that the website could operate safely before normal access resumed.
It's also a useful example of why business continuity and cybersecurity can't be treated as separate concerns. Decisions about software security can directly affect content delivery, marketing activity and the services people expect to access.
Final Thoughts: Why Website Security Sometimes Comes Before Availability
Taking a website offline is never an easy decision, especially when people rely on it for information, resources and business activity. But the critical PHP vulnerabilities announced on 21 October show why organisations sometimes need to make that call.
When a security flaw could allow attackers to execute code on affected systems, the priority is understanding the exposure and addressing it properly. That means identifying vulnerable software, applying the right patches and checking that systems are ready to operate safely again.
EM360Tech's precautionary shutdown brought those decisions into our own day-to-day work, from editorial publishing to awards promotion. It's a reminder that responding to a vulnerability involves more than the technical fix. Organisations also need to understand the business consequences of the choices they make, particularly when protecting their systems means temporarily disrupting the services people rely on.
As security threats continue to evolve, EM360Tech will keep following how organisations are balancing vulnerability management, cybersecurity risk and business continuity, and what those decisions mean for the people and services depending on them.
Comments ( 0 )