Emergency Patch! PHP2Shell Opens PHP Servers to Remote Code Execution

Developing Story ●

Status: In progress. This post was last updated on October 28th 2026 at 09:19 UTC. 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 immediately. 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. Exploitation attempts have already started: Amazon reports attempts against its honeypots since October 17, four days before disclosure, and public proofs of concept are circulating. CISA added both CVEs to its KEV catalog on October 26, 2026 (CVE-2026-109618, CVE-2026-109619). A previous critical PHP flaw, CVE-2024-4577, drew exploit attempts within a day; this time they came before the fix.

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

Scan for PHP2Shell now, no cost, 14 days →

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 [5]. Amazon, which saw a first attempt on October 17, and watchTowr report exploitation attempts against both vulnerabilities. New Zealand’s NCSC says it is aware of reports of active exploitation. On October 26, 2026, CISA added both CVEs to its Known Exploited Vulnerabilities (KEV) catalog: CVE-2026-109618, CVE-2026-109619. The BSI warning of October 22, 2026, reports no confirmed exploitation. 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

CVE-2026-109618

CVSS 9.2 · Critical EPSS 100.0% (100th)

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.

CVE-2026-109619

CVSS 9.2 · Critical EPSS 100.0% (100th)

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

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. The session setting blocks individual attack paths, but not all of them. In particular, it does not protect against CVE-2026-109618. Against CVE-2026-109619, it only takes effect if it is set administratively on the server and every worker is restarted afterwards; setting it with ini_set() in the application comes too late. Treat configuration changes as an additional measure at most, never as a replacement for the update. CERT-EU additionally recommends isolating internet-facing applications from public networks until the fix is applied. CISA goes further: organizations that cannot update immediately, or that still run PHP 8.1 or older, should take PHP-based systems offline until they are patched or upgraded.

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. Debian, Red Hat and Ubuntu have already published fixed packages, including for branches PHP no longer supports, such as PHP 7.4 and 8.0 on Red Hat Enterprise Linux 8 and 9 [8][9][10][11]. For PHP bundled with control panels, content management systems or appliances, check with the respective vendor. The Dutch NCSC keeps a list of products that include PHP and may be affected, which it is still expanding. Several vendors have already responded: cPanel has fixed its PHP packages, including backports for PHP 7.4, 8.0 and 8.1, and Plesk has published fixed PHP builds and an update for its own management interface. Palo Alto Networks lists all PAN-OS and Panorama versions as affected and has not released fixed versions yet; until then, it advises restricting access to the management interface to trusted internal IP addresses. Web applications such as WordPress, Drupal and Nextcloud run on the PHP installed beneath them, so updating that PHP fixes them.

PHP branch	Status	Fixed version	Notes
8.5	Active support until December 31, 2027	8.5.12
8.4	Active support until December 31, 2026	8.4.27
8.3	Security fixes only until December 31, 2027	8.3.36
8.2	Security fixes only until December 31, 2026	8.2.35	Upgrade to 8.4 or 8.5 recommended
8.1 and older	End of life	No official release	Listed as affected. Minimal source backports for 7.4, 8.0 and 8.1; check your distribution or LTS vendor for backported packages

Recommendations for Your Security Team

• Use the scans from the scan instructions to identify as many PHP installations as possible, and patch wherever you can.
• Not every PHP instance can be patched, for example appliances or PHP as middleware in a software bundle. Shut down internet-facing systems. If that is not possible, at least isolate and monitor them.
• Run PHP services behind an enabled IDS/IPS and check whether PHP2Shell signatures are present.
• If a PHP-based service can be taken offline temporarily, do so. If it has to stay online, apply the measures above and also assess the risk: which data would be affected if it were compromised? Security monitoring, for example with an EDR solution, is then required. Don’t rely on it alone: check whether your EDR has signatures for PHP2Shell, because variants can slip through. One hunting approach is to look for a shell started as a subprocess of PHP.
• Expect more public proofs of concept. In tests, the best confirmed proof of concept so far does not work in every environment, and it is still unclear which variant works against which configuration.

With the patch and the detection we have published, you are well prepared. We cannot guarantee, however, that a new variant won’t change the picture.

How to Find Vulnerable PHP Installations With Greenbone

1. Run an authenticated remote scan, i.e. with credentials stored for the target (instructions). An unauthenticated scan only reads remote information such as banners, which do not always allow conclusions about the version. For unauthenticated scans, set the QoD (Quality of Detection) filter in the results to 0.
2. If remote scans are not permitted in your environment, you can use the Greenbone Agent (instructions). Note: the agent is currently a Technology Preview.
3. For Linux systems, use the “Full and fast” scan config unchanged. It checks installed packages and also searches the file system for PHP executables (php, php-cli, php5, php7, php8). It does not search for php-cgi and php-fpm. For self-compiled applications, or where PHP is bundled as middleware, further checks are required. Please note that scans of running containers are not available.
4. For Windows systems, enable portable app detection before scanning:
   • Clone the “Full and fast” scan config and search for “Options for Local Security Checks” in the search bar.
   • Set “Enable Detection of Portable Apps on Windows” to “yes” and save.
5. Optional: Check whether a version was determined for every PHP software found. Without a version, it cannot be matched against the vulnerability. If PHP was only detected generically without a version, assume that the system may be affected. To find these systems: (1) Open “Results”. (2) Enable the log entries. (3) Search for name~"CPE Inventory" and ~php and not ~"php:php:". (4) The potentially affected host names and IP addresses are displayed. Clicking the blue “CPE Inventory” shows further software and the operating system detected on the same system. We have tested this filter, and it works. Whether it catches every case in every environment is something we can neither test nor confirm. If only a banner was detected and no authenticated scan ran, or it failed, admins should search the entire file system of these systems for PHP executables and confirm their versions.
6. Make sure the feed is current. A manual feed update gets you the PHP2Shell checks immediately, otherwise they arrive with the automatic NVT feed update set up in your environment.

Quicker option: We provide two ready-made scan configs, one for Linux and one for Windows, that are limited to the PHP2Shell checks (download, how to import a scan config). Use them with credentials as described in step 1: SSH credentials for Linux, SMB credentials for Windows. In the Windows config, portable app detection is already enabled. The steps above remain valid.

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 also finds PHP on hosts that don’t advertise a version, within the limits described in the steps above. 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. Exploitation attempts began before the fixes were published, and public proofs of concept are circulating. CISA has since added both CVEs to its KEV catalog. Defenders should update now and make sure to catch every PHP installation: end-of-life versions, hosts that hide their version, and PHP bundled with other software.

Updates

1. October 21, 2026: First published.
2. October 22, 2026: Added exploitation attempts reported by Amazon and watchTowr, public proofs of concept, fixed packages from Debian, Red Hat and Ubuntu, vendor responses from cPanel, Plesk and Palo Alto Networks, and CISA’s guidance for unsupported PHP versions. Greenbone’s feed now includes package-level checks for ten Linux distributions.
3. October 23, 2026: Added a step-by-step guide to detecting PHP2Shell with Greenbone and the EPSS values.
4. October 26, 2026: Expanded the scan instructions with the Greenbone Agent (Technology Preview), the scope and limits of the file system search on Linux, and an optional check for PHP detected without a version. Added recommendations for systems that cannot be patched right away and clarified the limits of the session.upload_progress setting. Added package-level checks for AlmaLinux, SUSE and openSUSE, checks for products that ship PHP, and links to the checks on SecInfo.
5. October 27, 2026: Added ready-made PHP2Shell scan configs for Linux and Windows to download.
6. October 28, 2026: Added the CISA KEV listing of both CVEs and updated the EPSS values.