PHP has issued security patches addressing two critical flaws, CVE-2026-109618 and CVE-2026-109619, collectively named PHP2Shell by security researchers. All supported PHP installations require immediate updates. According to the PHP project, both vulnerabilities could enable remote code execution (RCE) without authentication. The PHP security team assigned each vulnerability a severity score of 9.2 under CVSS v4.0.
The patched versions, released on October 21, 2026, include PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. PHP 8.1 and earlier branches have reached end of life and no longer qualify for official updates. However, the PHP security team has made minimal source-level backports available for PHP 7.4, 8.0, and 8.1. Attempts to exploit these vulnerabilities are already underway. Amazon has reported activity targeting its honeypots since October 17, four days ahead of public disclosure, while publicly available proof-of-concept exploits are circulating. As of October 22, 2026, neither vulnerability appears in CISA’s Known Exploited Vulnerabilities (KEV) catalog. The situation resembles the response to an earlier critical PHP vulnerability, CVE-2024-4577, which attracted exploitation attempts within 24 hours of disclosure. In the PHP2Shell case, however, malicious activity began before the patches became available.
Applying updates to supported PHP branches is relatively straightforward. Identifying every PHP deployment across an organization’s infrastructure presents a greater challenge. Some installations cannot be detected externally, while others use outdated releases that the PHP project no longer maintains. Both CERT-EU and Germany’s Federal Office for Information Security (BSI) have published security advisories covering these vulnerabilities.
PHP2Shell and the Risks Facing Unsupported PHP Versions
Four PHP branches currently receive official support. PHP 8.2 and 8.3 are maintained through security updates only, whereas PHP 8.4 and 8.5 remain under active support. Security maintenance for PHP 8.2 is scheduled to conclude on December 31, 2026.
All earlier branches have already reached end of life:
- PHP 8.1: December 31, 2025.
- PHP 8.0: November 26, 2023.
- PHP 7.4: November 28, 2022.
- PHP 5.6: December 31, 2018.
Official PHP security advisories identify all releases earlier than 8.2.35 as affected. For unsupported branches, PHP recommends obtaining backported security patches from Linux distribution maintainers or vendors providing long-term support (LTS). The PHP security team has also released minimal source-code backports for PHP 7.4, 8.0, and 8.1. These are intended for environments where PHP is compiled directly from source. Older releases, including PHP 5.6, receive neither of these options through the PHP project’s published source backports or official releases. Locating systems that still rely on such versions is therefore a necessary first step toward addressing the vulnerabilities.
Outdated PHP deployments remain widespread across internet-accessible infrastructure. Based on Mallory’s analysis of Shodan service banners conducted on October 20, 2026, approximately 884,000 publicly accessible hosts advertise PHP versions that have reached end of life. These systems account for 59% of the approximately 1.5 million hosts whose banners disclose a PHP version. An additional 740,000 hosts provide no version information. These figures represent observations derived from service banners rather than a verified count of systems vulnerable to PHP2Shell.
The absence of PHP version details in a service banner does not establish that PHP is absent from the host. PHP frequently operates as a component of hosting management platforms such as cPanel and Plesk, content management systems, and third-party software products. In such environments, PHP maintenance may depend entirely on the software vendor’s update schedule. Some installations may not receive updates at all.
PHP2Shell Risk Assessment
Details of CVE-2026-109618 and CVE-2026-109619 became publicly accessible before their scheduled coordinated disclosure. Amazon recorded its first exploitation attempt on October 17. Both Amazon and watchTowr have since reported attempts targeting the two vulnerabilities. New Zealand’s National Cyber Security Centre (NCSC) has also acknowledged reports indicating active exploitation. Despite these observations, neither CVE had been added to CISA’s KEV catalog as of October 22, 2026. Germany’s BSI had not independently confirmed exploitation at that time.
The vulnerabilities are nevertheless demonstrably exploitable. According to PHP’s security advisory, researchers successfully validated unauthenticated remote code execution through HTTP requests targeting mod_php. The tests were conducted using default limits for input processing and memory consumption.
Previous PHP security incidents demonstrate how rapidly exploitation can follow public disclosure. Following the announcement of the critical CVE-2024-4577 vulnerability in June 2024, Akamai detected initial exploitation attempts against its honeypot infrastructure within one day.
Technical Analysis of PHP Vulnerabilities CVE-2026-109618 and CVE-2026-109619
The PHP project considers any PHP installation responsible for processing web requests potentially exposed to these vulnerabilities. Affected deployment models include PHP-FPM, Apache running mod_php, php-cgi, FrankenPHP, and LiteSpeed. PHP identifies mod_php as the highest-risk configuration. In this environment, an unauthenticated HTTP request can initiate the attack before the application executes any of its own code. Both vulnerability advisories identify use-after-free (CWE-416) as one of the underlying weakness categories. The PHP ChangeLog associates the two CVEs with a shared correction in the PHP core, described as “Avoid state corruption via bailout.”
CVE-2026-109618
- CVSS: 9.2 – Critical
- EPSS: Pending verification
Remote code execution through memory corruption caused by an out-of-memory (OOM) condition (GHSA-w8hw-w9fx-j79w). This vulnerability arises when PHP exhausts its available memory while internal request structures have not yet been fully initialized. During subsequent request cleanup, the application may incorrectly interpret invalid or incomplete internal data as legitimate.
CVE-2026-109619
- CVSS: 9.2 – Critical
- EPSS: Pending verification
Remote code execution through the reuse of stale global state (GHSA-6wmf-4rv5-p3rp). The vulnerability involves internal state associated with an earlier request remaining accessible inside a persistent worker process after its allocated memory has been released. When the same worker handles another request, it may reference and reuse that outdated state.
Additional technical explanations of both vulnerabilities are available in PHP’s official security advisories.
Vulnerable PHP Releases and Mitigation Measures for CVE-2026-109618 and CVE-2026-109619
All supported PHP deployments should be updated to the appropriate patched release: PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35. Systems running a branch that has reached end of life should be migrated to a supported release. Since security maintenance for PHP 8.2 ends on December 31, 2026, PHP 8.4 or 8.5 represents a more suitable upgrade destination. Where migration cannot be completed immediately, alternative patching options should be evaluated. These include security fixes backported by the operating system distribution or an LTS provider. For PHP 7.4, 8.0, and 8.1, another possibility is compiling PHP using the source-code backports published by the PHP security team.
PHP also documents configuration adjustments that may reduce exposure to particular exploitation techniques when immediate patching is not feasible. Examples include:
- Setting memory_limit=-1 to mitigate specific attack paths associated with CVE-2026-109618.
- Configuring session.upload_progress.enabled=0 to reduce exposure to CVE-2026-109619.
However, PHP explicitly states that these configuration changes do not make an affected installation secure. Installing the relevant security update remains the only comprehensive remediation. CERT-EU additionally advises separating internet-facing applications from public networks until the required patches have been deployed. CISA recommends a stricter response for organizations unable to apply updates promptly or still operating PHP 8.1 and earlier releases. Under those circumstances, PHP-based systems should be taken offline until the vulnerabilities have been addressed through patching or an upgrade.
Linux distribution maintainers sometimes incorporate security corrections into their PHP packages without modifying the reported PHP version number. PHP confirms that distribution providers and LTS vendors received the patches before public release. Updated packages should therefore be obtained through the relevant vendor’s distribution channels.
Debian, Red Hat, and Ubuntu have already released packages containing the necessary corrections. Some packages also cover PHP branches that no longer receive upstream support, including PHP 7.4 and 8.0 on Red Hat Enterprise Linux 8 and 9. For PHP components distributed as part of hosting control panels, content management systems, or software appliances, patch availability must be confirmed with the respective product vendor. The Dutch National Cyber Security Centre maintains an expanding inventory of products that incorporate PHP and may therefore be affected.
Several technology providers have already issued responses:
- cPanel has updated its PHP packages and included backported security corrections for PHP 7.4, 8.0, and 8.1.
- Plesk has released corrected PHP builds alongside a separate security update for its management interface.
- Palo Alto Networks identifies every version of PAN-OS and Panorama as affected. Patched versions have not yet been released. In the meantime, the vendor recommends limiting access to management interfaces to trusted internal IP addresses.
Web applications such as WordPress, Drupal, and Nextcloud depend on the underlying PHP runtime. Accordingly, updating the PHP installation used by these applications addresses the vulnerabilities for those deployments.
| PHP Branch | Support Status | Patched Release | Additional Information |
| 8.5 | Active support through December 31, 2027 | 8.5.12 | |
| 8.4 | Active support through December 31, 2026 | 8.4.27 | |
| 8.3 | Security updates only through December 31, 2027 | 8.3.36 | |
| 8.2 | Security updates only through December 31, 2026 | 8.2.35 | Migration to PHP 8.4 or 8.5 is recommended. |
| 8.1 and earlier | End of life | No official patched release | Identified as affected. Minimal source-level backports are available for PHP 7.4, 8.0, and 8.1. Distribution maintainers and LTS providers should be consulted regarding updated packages containing backported fixes. |
Identifying Vulnerable PHP Deployments Using OPENVAS (Enterprise)
OPENVAS SCAN (an enterprise version of a well-known network vulnerability scanner) provides vulnerability checks for CVE-2026-109618 and CVE-2026-109619 that can operate both with and without authentication. However, these scanning approaches differ significantly in the information they can obtain.
Unauthenticated scanning relies on details that a remote server makes externally accessible. When a host does not disclose its PHP version, the scanner cannot reliably determine which release is installed. Detection accuracy therefore depends on the completeness and correctness of the version information returned by the server.
Authenticated scanning provides additional visibility by accessing the target system with valid credentials and examining its installed software. This approach can identify PHP installations on hosts included in a credentialed scan, regardless of whether the server publicly advertises its PHP version.
On Windows systems, enabling portable application detection can support a more comprehensive search for PHP deployments. The configuration procedure involves the following steps:
- Open the relevant scan configuration for editing. A duplicate of the Full and fast scan profile can be used as an example.
- Navigate to the Network Vulnerability Test Preferences section.
- Locate Options for Local Security Checks.
- Change Enable Detection of Portable Apps on Windows to yes.
- Save the updated configuration.
Authenticated vulnerability assessments generally require more time than unauthenticated checks. They also place additional processing demands on the systems being examined. The scope and schedule of these scans should therefore account for their potential impact on the target environment.
Summary
CVE-2026-109618 and CVE-2026-109619 are critical PHP security vulnerabilities that may enable unauthenticated remote code execution.
The PHP project has addressed both flaws in versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Unsupported PHP branches must instead rely on available backported corrections or migration to maintained versions.
Exploitation attempts were observed before the official patches became available, and publicly accessible proof-of-concept exploits are already circulating. Immediate patch deployment is therefore essential, but updating known systems alone is insufficient. Comprehensive remediation also requires locating PHP installations that may have been overlooked, including unsupported releases, hosts that conceal their PHP version, and PHP components distributed within third-party software.
