Emergency Patch! PHP2Shell Opens PHP Servers to Remote Code Execution
●Developing Story
Status: In progress. This post was last updated on October 21st 2026. We will update it as new information becomes available.
PHP has released fixes for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, dubbed PHP2Shell by researchers. Every supported PHP installation should be updated today. According to PHP, both flaws can allow unauthenticated remote code execution, and the PHP security team rates both at CVSS v4.0 9.2. The fixed releases, published on October 21, 2026, are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older have reached end of life and no longer receive official updates, although PHP’s security team has published minimal source backports for PHP 7.4, 8.0 and 8.1. So far, no exploitation in the wild has been reported, and neither CVE is listed in CISA’s KEV catalog. Acting now keeps it that way: a previous critical PHP flaw, CVE-2024-4577, drew exploit attempts within a day.
Updating the supported branches is the easy part. The harder part is finding every PHP installation in your network, including the ones you can’t see from the outside and the ones the PHP project no longer updates. CERT-EU and Germany’s BSI have issued advisories for both vulnerabilities [1][2].
Check Your Network for PHP2Shell With Greenbone
Greenbone’s OPENVAS ENTERPRISE FEED includes version checks for CVE-2026-109618 and CVE-2026-109619 on Linux and Windows. Authenticated scans released today look for executables and binaries across the system to determine the PHP version. Package-level checks for Linux distributions will follow as the distributions publish their advisories. The checks are included in OPENVAS ENTERPRISE FEED version “Wed Oct 21, 07:20:00 2026”. To receive them today, trigger a feed update manually. Otherwise, the feed is downloaded automatically overnight and the checks will be available on your appliance tomorrow. OPENVAS SCAN includes a free two-week trial of the ENTERPRISE FEED, with over 250,000 vulnerability tests and counting.
What PHP2Shell Means for End-of-Life PHP
PHP currently supports four branches: 8.2 and 8.3 receive security fixes only, while 8.4 and 8.5 are in active support. Security support for PHP 8.2 ends on December 31, 2026. Every older branch is end of life: PHP 8.1 since December 31, 2025, PHP 8.0 since November 26, 2023, PHP 7.4 since November 28, 2022, and PHP 5.6 since December 31, 2018. PHP’s advisories list every version below 8.2.35 as affected [3][4]. For end-of-life branches, PHP points to distributions and LTS vendors that provide backported fixes, and its security team has published minimal source backports for PHP 7.4, PHP 8.0 and PHP 8.1 for people who build from source. Older branches such as PHP 5.6 get neither. Before you can fix these systems, you have to know where they run.
There is a lot of old PHP on the internet. According to Mallory’s count of Shodan banners on October 20, 2026, around 884,000 internet-facing hosts advertise an end-of-life PHP version, 59% of the roughly 1.5 million hosts that show a version at all. Another 740,000 or so don’t reveal their version. These are banner counts, not confirmed vulnerable systems.
A hidden version banner doesn’t mean there’s no PHP behind it. PHP also runs inside control panels such as cPanel and Plesk, content management systems and vendor software, where it’s updated on someone else’s schedule, or not at all.
A Risk Assessment of PHP2Shell
Information about both vulnerabilities leaked before the planned coordinated disclosure, and PHP released its fixes a day earlier than originally scheduled [5][6]. As of October 21, 2026, watchTowr and BSI report no confirmed exploitation in the wild, and neither CVE is in CISA’s KEV catalog. The flaws are exploitable in practice, though: PHP’s advisory states that unauthenticated remote code execution was validated over HTTP against mod_php with default input and memory limits.
Attackers have moved quickly on PHP flaws before. When the critical PHP flaw CVE-2024-4577 went public in June 2024, Akamai saw the first exploit attempts against its honeypots within a day.
The Technical Details for CVE-2026-109618 and CVE-2026-109619 in PHP
PHP considers all PHP installations serving web requests at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It rates the risk highest for mod_php, where an unauthenticated request can trigger the attack before any application code runs. Both advisories list use-after-free [CWE-416] among the weaknesses, and the ChangeLog records both under a single fix in PHP’s core (“Avoid state corruption via bailout”).
The two CVEs fixed in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, each shown with its CVSS severity band and EPSS exploitation-probability score
RCE via OOM corruption (GHSA-w8hw-w9fx-j79w): when PHP runs out of memory while internal request data is only partially initialized, request cleanup can treat the invalid data as valid.
RCE via stale global state (GHSA-6wmf-4rv5-p3rp): internal state owned by one request can survive in a persistent worker after its memory has been freed, and a later request handled by the same worker can use it.
PHP’s advisories have the full technical details [7][8].
Affected Versions and Mitigation for CVE-2026-109618 and CVE-2026-109619 in PHP
Update every supported PHP installation to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. If you run an end-of-life branch, upgrade to a supported one. Since security support for PHP 8.2 ends on December 31, 2026, PHP 8.4 or 8.5 is the better target. If you can’t upgrade yet, check whether your distribution or LTS vendor provides a backported fix, or build from PHP’s source backports for 7.4, 8.0 and 8.1.
If you can’t update immediately, PHP lists configuration changes that reduce exposure to specific attack paths, for example enforcing memory_limit=-1 against CVE-2026-109618 and setting session.upload_progress.enabled=0 against CVE-2026-109619. PHP is clear that these measures do not make an installation safe and that updating is the only complete fix. CERT-EU additionally recommends isolating internet-facing applications from public networks until the fix is applied.
Linux distributions sometimes backport fixes to their own PHP packages without changing the version number. PHP says distributions and LTS vendors received the patches in advance, so check your vendor for updated packages. For PHP bundled with control panels, content management systems or appliances, check with the respective vendor.
How to Find Vulnerable PHP Installations With Greenbone
The checks for CVE-2026-109618 and CVE-2026-109619 work in unauthenticated and authenticated scans, but the two see different things. An unauthenticated scan only sees what a server chooses to reveal. If a host hides its PHP version, the scan can’t tell which version it runs, and the result is only as reliable as the version information the server sends. An authenticated scan logs in and looks at the installed software, so it finds PHP on every host you scan with credentials, whether or not it advertises a version. For a deeper search on Windows hosts, enable portable app detection before scanning: edit your scan config (for example a copy of Full and fast), scroll down to Network Vulnerability Test Preferences, find Options for Local Security Checks, set Enable Detection of Portable Apps on Windows to yes, and save. Authenticated scans take longer and put more load on the scanned systems, so plan the scope and timing of the scan accordingly.
Summary
CVE-2026-109618 and CVE-2026-109619 are two critical vulnerabilities in PHP that can allow unauthenticated remote code execution. PHP has fixed them in 8.5.12, 8.4.27, 8.3.36 and 8.2.35, while end-of-life branches depend on backports. No exploitation has been reported so far, but a previous critical PHP flaw, CVE-2024-4577, drew exploit attempts within a day. Defenders should update now, then find every PHP installation they forgot about: end-of-life versions, hosts that hide their version, and PHP bundled with other software.
Updates
- October 21, 2026: First published.
