Developing Story ●
Status: In progress. This post was last updated on October 23rd 2026 at 11:15 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. Neither CVE is listed in CISA’s KEV catalog as of October 22, 2026. 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 → 
- Run an authenticated remote scan, i.e. with credentials stored for the target. An unauthenticated scan reads remote information such as banners, which do not always allow conclusions about the version. Important for unauthenticated scans: set the QoD (Quality of Detection) to 0 in the results filter so that all vulnerabilities found are displayed.
- For Linux systems, use the “Full and fast” scan config unchanged. It covers PHP2Shell there completely, and no additional scan config is needed.
- 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.
- Make sure the feed is current. A manual feed update gets you the PHP2Shell checks immediately, otherwise they arrive with the nightly update.
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. As of October 22, 2026, neither CVE is in CISA’s KEV catalog, and BSI has not 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.
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 on October 21 look for executables and binaries across the system to determine the PHP version. The feed also includes package-level checks for Arch, Rocky Linux, Amazon Linux, Red Hat, Oracle Linux, Ubuntu, Debian, Slackware, Fedora and Mageia. Checks for further distributions will follow as their vendors publish advisories. To get the new checks right away, trigger a feed update manually. Otherwise, the feed is downloaded automatically overnight. OPENVAS SCAN includes a free two-week trial of the ENTERPRISE FEED, with over 250,000 vulnerability tests and counting.
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 [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. 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.
How to Find Vulnerable PHP Installations With Greenbone
- Run an authenticated remote scan, i.e. with credentials stored for the target. An unauthenticated scan reads remote information such as banners, which do not always allow conclusions about the version. Important for unauthenticated scans: set the QoD (Quality of Detection) to 0 in the results filter so that all vulnerabilities found are displayed.
- For Linux systems, use the “Full and fast” scan config unchanged. It covers PHP2Shell there completely, and no additional scan config is needed.
- 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.
- Make sure the feed is current. A manual feed update gets you the PHP2Shell checks immediately, otherwise they arrive with the nightly update.
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. Exploitation attempts began before the fixes were published, and public proofs of concept are circulating. 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
- October 21, 2026: First published.
- 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.
- October 23, 2026: Added a step-by-step guide to detecting PHP2Shell with Greenbone and the EPSS values. Removed the mention of agent-based scans.












