PHP2Shell: Critical PHP Remote Code Execution Vulnerabilities

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

The files were spread across numerous directories and had matching or very similar timestamps, indicating a bulk deployment. 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. 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. 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

[hr] 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.