The vulnerability was
A website can work perfectly and still be exposed to a critical vulnerability.Pages load normally,…
A website can work perfectly and still be exposed to a critical vulnerability.
Pages load normally, forms respond, users can access their accounts, and services continue to operate without any apparent incidents. There are no visible errors or signs suggesting that anything requires our immediate attention.
Until a security advisory appears and completely changes the situation.
On 21 October 2026, the PHP development team released urgent updates to fix two critical vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, both with a score of 9.2 out of 10 according to CVSS v4.0.
The flaws were related to the internal handling of memory and request state. Under certain conditions, they could allow an attacker to execute code remotely without needing to authenticate. The official recommendation was to update affected installations that processed web requests immediately, as temporary mitigation measures did not provide complete protection.
The seriousness of the incident soon extended beyond the strictly technical sphere. The United States National Security Agency (NSA) recommended that organisations using PHP prepare the updates and consider temporarily taking systems offline where it was not possible to fix them immediately.
The response also came from the platforms themselves. Drupal.org and other related services were temporarily taken offline while those responsible applied the fixes. The Drupal Association clarified that the issue was not in Drupal, but in PHP, and that its usual protection mechanisms did not address this vulnerability.
What was particularly concerning was not only the seriousness of the vulnerabilities, but where they were located.
We are not necessarily talking about an error in a WordPress plugin or a feature developed without the necessary precautions. The flaws were in the PHP interpreter, a technology on which many web applications depend.
This means that an organisation could have maintained its application properly, applied its updates and followed standard security recommendations, yet still remain exposed because of a vulnerability in one of the components it needed to operate.
For years, we have associated much of web security with keeping our software up to date, fixing programming errors and properly configuring the tools we use. These are essential practices, but incidents like this remind us that an application's security also depends on elements we do not always see and over which we have no direct control.
The fact that a website works properly does not mean that everything it needs in order to work is secure.
The vulnerabilities published on 21 October invite us to examine not only how a critical flaw is fixed, but also what it means to maintain the infrastructure on which an application operates.
The code we do not write can compromise us too
When we develop a web application, we tend to focus much of our security effort on the code we write: validating the data we receive, controlling access permissions, protecting sessions, or preventing malicious input from being executed as an instruction.
However, before our application can carry out any of these operations, other technologies are involved in receiving, interpreting and processing requests.
In an application developed with PHP, some of this work is handled by the interpreter itself. It is the component responsible for executing our code, but it also performs internal operations related to memory management, sessions and the processing of HTTP requests.
The CVE-2026-109618 and CVE-2026-109619 vulnerabilities affect precisely this layer.
The first is related to error handling when available memory is exhausted. The second concerns the incorrect reuse of certain internal states between requests. In both cases, the flaws may allow an attacker to alter the interpreter's behaviour and execute unauthorised code.
What is particularly significant is that, according to the technical analysis published by Datadog Security Labs, exploitation can occur before PHP even executes the application code.
We may have properly developed our authentication mechanisms, applied controls to forms and reviewed the features exposed externally. But if a malicious request exploits a flaw in PHP's internal processing, those protections may not even have the chance to come into play.
This does not mean that all installations are equally vulnerable, nor that any request can compromise a server. Actual exposure depends on versions, configurations and runtime conditions.
The point is that the security of our code and the security of the environment that runs it are different, though inseparable, responsibilities.
We can control how we develop an application, but we cannot always fix defects directly in the tools on which it runs. In such cases, we depend on the fixes released by those responsible for them and on our ability to incorporate them correctly.
And this is where a new challenge emerges: once the provider releases a solution, we still have to ensure that the fix reaches our systems safely.
Updating is not the same as being protected
When a fix for a critical vulnerability is released, the recommendation is usually immediate: update as soon as possible. But between a patch becoming available and being certain that a system is protected lies a process that is not always as straightforward as it seems.
One aspect that can cause confusion is version numbering.
Distributions such as Ubuntu maintain certain PHP versions for years and apply security fixes to them through a process known as backporting. This makes it possible to incorporate patches from later versions without having to change the entire interpreter branch, something especially important on production servers where applications depend on specific versions.
For example, PHP 8.1 distributed by Ubuntu 22.04 can receive specific security fixes even if that branch no longer receives updates from the PHP project. We should not confuse support from the distribution vendor with support from the original project.
An apparently old version does not necessarily mean that it is vulnerable, just as a newer version does not in itself guarantee that it includes a particular fix.
In the case of the vulnerabilities of 21 October, Ubuntu released fixed packages for its supported distributions. The appropriate check was not merely to look at the PHP version, but also to verify the source of the packages and that the fixes corresponding to the CVEs had actually been incorporated.
But verification does not end once the packages have been installed. It is also necessary to check which version the web service is actually using, whether the processes have been restarted where appropriate, and whether the applications continue to work correctly.
An update may have completed without errors and still leave processes running old code, or cause incompatibilities that are not detected until someone uses a particular feature.
That is why it is useful to distinguish between three situations: having a fix available, having installed it, and having checked that it is applied in the environment that is actually providing the service.
Security should not be based solely on the confidence that comes from having updated, but on the ability to demonstrate what has been fixed and what continues to work.
And that verification requires something we cannot always improvise during an emergency: time to intervene, verify the results and react if problems arise.
Security is also a matter of time
One of the most significant aspects of this incident is the role of artificial intelligence in the investigation. According to OpenAI, Calif identified one of the flaws with the help of GPT-5.6 Sol; independently, Wiz discovered and reported both issues, also using AI models in its research, according to Google Cloud. These tools contributed to the technical analysis and the verification of the fixes.
This does not mean that artificial intelligence has replaced security researchers. Discovery, risk assessment and coordination with those responsible for PHP still required human involvement. But it does demonstrate how these tools can expand the capacity to analyse large amounts of code and identify problems that are difficult to detect using traditional methods.
If we can increasingly discover vulnerabilities more quickly, are we prepared to fix them at the same pace?
Identifying a flaw does not mean that all affected systems can be updated immediately. Fixes must be developed, distributed and applied across infrastructures with very different characteristics. Some organisations have specialist teams and automated deployment processes. Others depend on manual interventions, external providers or legacy applications that require additional checks.
Artificial intelligence can help reduce the time needed to discover a vulnerability, but it does not automatically eliminate the work required to fix it in production. And this acceleration can also benefit those looking to exploit flaws before organisations have applied the updates.
That is why the real challenge is not merely to detect more problems and do so earlier. We also need to reduce the time between learning of a vulnerability and getting affected systems operating again with the necessary fixes.
The speed of discovery is changing. Our capacity to respond will have to change too.
The day of the emergency is not the time to find out what we have
When a critical vulnerability is announced, one of the first questions should be relatively straightforward: which of our systems are affected?
However, answering it is not always easy.
In many organisations, technological infrastructure has evolved over the years. Applications have been migrated, new providers have been engaged, services have been incorporated, and old servers have been retained because they still host some necessary functionality. Some of this information is documented, but some depends on the knowledge of those involved in each project.
While everything is working, this situation can go unnoticed. The problem emerges when we need to intervene urgently.
Identifying which servers use a particular version of PHP, which applications depend on it or which repositories supply the updates can then become an investigation that consumes especially valuable time.
We also need to know whether recoverable backups exist, whether we can test changes before applying them in production, and what procedure we will follow if an update causes an incompatibility. Even seemingly secondary matters, such as available disk space, can affect an urgent intervention.
The difference does not lie only in having monitoring tools or a specialist team. It also lies in much more basic decisions: keeping the technology inventory up to date, documenting relevant configurations, defining responsibilities and regularly checking that recovery mechanisms work.
These tasks rarely have the visibility of a new development or a feature that improves the user experience. Their value usually becomes clear precisely when something goes wrong.
During this incident, some organisations also chose to temporarily take certain services offline while applying the security fixes. This was the case for ICANN and the European Patent Office. These decisions show that responding to a vulnerability does not always mean keeping everything running: in certain circumstances, temporarily interrupting a service may be the most prudent option for reducing exposure while a solution is applied.
That is why a prepared organisation is not one that can guarantee it will never have security issues. It is one that, when a threat emerges, does not need to begin by finding out how its own infrastructure works.
The ability to respond to a vulnerability is not built during the emergency. It is the result of the maintenance and decisions we have made long before it appears.
Conclusion
PHP vulnerabilities remind us that no system can guarantee the absolute absence of flaws. Good development practices and maintenance reduce risks, but they do not eliminate the possibility of unknown vulnerabilities emerging in established technologies.
Perhaps, then, we should stop understanding security as a state we achieve after installing certain tools or completing a series of checks.
Security is not something we achieve once and can consider finished. It is a responsibility we must sustain over time.
This means accepting that, sooner or later, one of the technologies we use will need an urgent fix. And that our ability to identify the problem, assess its scope, intervene and verify the results will be as important as the preventive measures we have adopted.
A reliable infrastructure is not one that never needs intervention, but one that can deal with changes and incidents without losing control over how it operates.
Ultimately, we cannot guarantee that no technology will fail, but we can decide how prepared we are to respond when it does.
And that is the question worth asking even when our systems have not been affected:
Do we know our infrastructure well enough to respond when a technology we depend on is no longer secure?
Do you know the state of your web infrastructure?
A critical vulnerability should not be the moment when you discover how your servers are configured or who is actually responsible for maintaining them.
At ITDO, we can help you review your infrastructure, identify potential risks and define a maintenance and update strategy tailored to the needs of your project.
Sources:
- PHP — versions and security advisories
- USN-8948-1: PHP vulnerabilities | Ubuntu security notices
- Google Cloud — Responding to core PHP vulnerabilities
- Datadog Security Labs — PHP2Shell: detection, analysis, and remediation
- OpenAI — Patch the Planet: global response coordination
- NSA — Advisory: PHP Updates (21/10/2026)
- Drupal — Critical PHP Update (21/10/2026)
Comments