1. Introduction
In October 2026, two critical vulnerabilities in PHP were publicly disclosed. Together, they became known as PHP2Shell.
The vulnerabilities could allow an unauthenticated remote attacker to execute arbitrary code on a vulnerable PHP server, potentially gaining control over the PHP worker process and accessing data and files available to that process.
The vulnerabilities are:
- CVE-2026-109618 - Remote Code Execution via Out-of-Memory (OOM) corruption.
- CVE-2026-109619 - Remote Code Execution via stale global state.
Both received a CVSS v4.0 severity score of 9.2 (Critical).
The PHP development team published the security updates on 21 October 2026.
Official PHP security advisory:
PHP: Critical remote code execution vulnerabilities
2. Understanding the vulnerabilities
These are vulnerabilities in the PHP runtime itself, rather than vulnerabilities in a particular CMS such as Drupal or WordPress.
This distinction is important: a vulnerable PHP installation can be exposed even when the application running on top of it has no known vulnerability of its own.
2.1. CVE-2026-109618: Out-of-Memory corruption
PHP uses an internal mechanism called longjmp() to handle certain out-of-memory conditions and abort the current request.
Under specific circumstances, an allocation failure can interrupt PHP while internal request data is only partially initialized.
The subsequent request cleanup process may then access this invalid or uninitialized memory.
An attacker can use carefully constructed requests and memory conditions to trigger this behaviour and potentially achieve remote code execution.
2.2. CVE-2026-109619: Stale global state
PHP maintains internal global state between requests handled by persistent workers.
Some of this state can temporarily point to memory belonging to an individual request. That memory must be properly reset before it is released.
Under certain conditions, PHP can retain references to memory that has already been freed. A subsequent request may then access this stale memory before the normal initialization process replaces it.
This is a use-after-free vulnerability.
With carefully constructed input and memory conditions, an attacker can potentially turn this into remote code execution.
3. Which PHP versions are affected?
The vulnerabilities affect PHP installations serving web requests.
The affected versions in the actively supported release branches were:
| PHP branch | Affected versions | First fixed release |
|---|---|---|
| PHP 8.5 | 8.5.0 - 8.5.11 | 8.5.12 |
| PHP 8.4 | 8.4.0 - 8.4.26 | 8.4.27 |
| PHP 8.3 | 8.3.0 - 8.3.35 | 8.3.36 |
| PHP 8.2 | 8.2.0 - 8.2.34 | 8.2.35 |
PHP 8.1 and older branches were also affected.
These older branches had reached end of life and no longer received normal security updates from the PHP project. Some Linux distributions and commercial vendors could provide backported security fixes, so the actual package build and vendor advisory must be checked rather than relying exclusively on the displayed PHP version.
The PHP project also published minimal source backports for PHP 7.4, 8.0 and 8.1.
4. Which server configurations are exposed?
The vulnerabilities affect PHP installations handling web requests, including:
- Apache with mod_php
- PHP-FPM
- PHP CGI
- FrankenPHP
- LiteSpeed
The PHP development team identified Apache with mod_php as the highest-risk configuration, with a demonstrated exploit capable of triggering the vulnerability before application code runs.
This means that having an up-to-date Drupal or WordPress installation does not, by itself, protect a server running a vulnerable PHP runtime.
An attacker does not necessarily need a Drupal login, an administrator account or a vulnerable Drupal module.
5. Relevance to the website security incident
The old website was hosted using an architecture involving Varnish, Nginx and Apache workers, with the website files shared through NFS.
During the investigation, we discovered suspicious files deployed throughout the shared website filesystem.
These included:
.htaccess
wp-blog-header.php
wp-cron.php
wp-headre.php
Some folders also contained misspelled variations, such as:
wp-headre.php
The files were spread across numerous directories and had matching or very similar timestamps, indicating a bulk deployment.
Many of these files had matching or very similar timestamps, suggesting that they had been deployed in bulk rather than created as part of normal website activity.
The files were WordPress-related in name, despite the affected website being a Drupal installation.
The investigation indicated that this was not simply a case of unwanted WordPress files. The suspicious PHP files and modified configuration files were consistent with a remotely controlled SEO-spam, cloaking or backdoor operation.
The suspicious PHP code was consistent with an SEO-spam and cloaking operation, with functionality capable of retrieving remote content and executing additional PHP code.
Some of the PHP code appeared capable of retrieving and executing additional remote PHP code.
The presence of these files demonstrated that the website environment had been compromised.
The PHP2Shell vulnerabilities are particularly relevant because they provide a possible explanation for how an attacker could obtain remote code execution without first compromising the Drupal application itself.
However, there is an important limitation to this conclusion.
Although the PHP vulnerabilities are a plausible attack vector, we have not established forensic evidence connecting either CVE directly to the compromise of this particular server.
The exact initial entry point remains unconfirmed.
To establish that connection, we would need evidence such as the actual PHP runtime and build in use at the time, relevant web server logs, PHP worker crashes or other forensic indicators associated with exploitation.
6. Security updates and remediation
The PHP development team released the following fixed versions on 21 October 2026:
- PHP 8.5.12
- PHP 8.4.27
- PHP 8.3.36
- PHP 8.2.35
Updating to a fixed PHP release is the only complete remediation.
The PHP advisory also describes temporary measures that can reduce exposure to particular attack paths, but these should not be considered substitutes for applying the security updates.
For systems using end-of-life PHP versions, moving to a supported PHP release is the recommended approach.
7. What we established and what remained unknown
The investigation established that:
- The shared website filesystem contained a large number of suspicious PHP and configuration files.
- The files were spread across many directories, indicating a broad deployment.
- The behaviour was consistent with a remotely controlled compromise, potentially involving SEO spam, cloaking and backdoor functionality.
- The Drupal 7 website was affected by the incident and subsequently experienced a blank-page problem.
However, we did not establish the original entry point.
A specific PHP vulnerability or Drupal vulnerability was not conclusively identified as the initial cause. The possibility of exploitation through an outdated application, PHP component or another exposed service was considered, but the available evidence did not prove which route was used.
We also did not establish evidence of database theft or compromise of visitors’ devices. The absence of such evidence should not be interpreted as proof that no data was accessed.
8. Recovery strategy
Rather than attempting to clean individual suspicious files throughout the shared filesystem, the recovery approach was based on restoring known-clean data and rebuilding the application environment.
The recovery work included:
- Using a known-clean backup as the basis for restoring the website files.
- Preserving the original database so that articles, metadata and historical information could be recovered.
- Keeping the database and uploaded files separate from the application code.
- Rebuilding the web application environment rather than trusting the previously compromised application files.
- Moving towards clean, locally maintained application code for each web worker, instead of relying on a shared writable application-code tree.
The intention was to preserve the site’s content and historical data while replacing the potentially compromised application environment.
9. Why the Drupal migration became necessary
The incident made it clear that simply restoring the old Drupal 7 installation was not a sufficient long-term solution.
There were several reasons to move to a new platform:
- The old Drupal 7 installation was based on an outdated application stack.
- The security incident required rebuilding the application environment from a trusted baseline.
- The old application and its dependencies needed to be replaced with maintained versions.
- The migration offered an opportunity to preserve the existing content while moving to a supported Drupal architecture.
- The original Drupal 7 codebase and contributed modules were increasingly difficult to maintain.
There was also an important lifecycle consideration: Drupal 7 officially reached end of life on 5 January 2025. It no longer receives normal community security updates or support. See the official Drupal 7 End-of-Life announcement.
The decision was therefore not just a routine CMS upgrade. It was part of a wider recovery and security effort.
10. Migration philosophy
The migration was approached with one main objective:
Preserve the site’s content and history, but do not carry forward the old application’s technical problems.
This meant:
- Preserving article IDs wherever possible.
- Preserving article titles, dates, content and metadata.
- Recovering the old BBCode functionality rather than rewriting every article manually.
- Preserving historical visitor statistics.
- Reconstructing the old menu hierarchy.
- Rebuilding the theme and presentation layer using Drupal 10-compatible code.
- Replacing obsolete functionality with maintained Drupal 10 modules or small custom modules where necessary.
The result is a new Drupal installation that retains the historical content and much of the original website’s behaviour, while using a modern application stack.
11. References
- Official PHP security advisory - 21 October 2026
- NHS England - Critical Vulnerabilities in PHP (PHP2Shell)
- PHP supported versions
- CVE-2026-109618 security advisory
- CVE-2026-109619 security advisory
This article documents the two PHP vulnerabilities and their relevance to the website security investigation. It does not claim that either CVE was conclusively responsible for the incident.
- Log in to post comments
- 75 views