php2shell: Critical PHP Vulnerabilities, What to Do Now

Summary

The PHP project has released PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 to fix two critical vulnerabilities that can allow unauthenticated remote code execution. PHP says all users should update immediately and that updating is the only safe choice. PHP serves a very large share of the web, from WordPress and other content management systems to custom business applications, so most organisations run it somewhere, often without knowing.

If you run PHP, update now. Below we separate what PHP has confirmed from what is only reported, and list what to do, including for systems that cannot be updated today.

Timeline

Newest first. Each entry says who stands behind it.

1. 21 October 2026 Debian advisory
   Debian publishes advisory DSA-6574-1: php8.4 in Debian 13 (trixie) is fixed in version 8.4.27-1~deb13u1 for CVE-2026-109618 and CVE-2026-109619, which Debian describes as incorrect memory state tracking that could result in the execution of arbitrary code. Source: Debian
2. 21 October 2026 Confirmed by PHP
   PHP's advisory says the volunteer-maintained Remi repository will not have updates today, and urges its users to switch to distribution packages or build from source. It also says PHP 8.1 and older no longer receive updates from the PHP project, and points to minimal source backports for 7.4, 8.0 and 8.1. Source: PHP.net
3. 21 October 2026 Confirmed by PHP
   PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing CVE-2026-109618 and CVE-2026-109619, two critical flaws that can allow unauthenticated remote code execution. PHP says updating is the only safe choice. Source: PHP.net
4. Morning of 21 October 2026 Reported, not confirmed
   Cloudflare reports early attacks against PHP sites and deploys WAF rules.
5. 20 October 2026 Reported, not confirmed
   Information about the flaws is reported to have leaked before the coordinated disclosure, which was originally planned for 22 October. The leaked reports claimed CVSS 10.0; PHP's official rating is 9.2.
6. 20 October 2026 Confirmed by PHP
   The PHP security team announces an upcoming critical security release for Wednesday 21 October 2026 at 14:00 UTC (16:00 CEST), fixing two vulnerabilities, both rated CVSS v4.0 9.2. Source: PHP.net

What we know

Confirmed by the PHP project

• PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix CVE-2026-109618 and CVE-2026-109619, both critical (CVSS v4.0 9.2), which can allow unauthenticated remote code execution.
• CVE-2026-109618: out-of-memory handling can interrupt PHP while internal request data is only partially initialised, and request cleanup may then treat the invalid data as valid. See the GitHub advisory .
• CVE-2026-109619: request-owned internal state can survive after its memory has been freed, and a later request handled by the same worker may use that stale state. See the GitHub advisory .
• Affected versions, per both GitHub advisories: everything before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 in their respective branches. Both are rated critical, CVSS v4.0 9.2: reachable over the network, no privileges and no user interaction needed, but with high attack complexity. The listed weaknesses are use after free, improper handling of exceptional conditions, access of an uninitialised pointer, improperly controlled sequential memory allocation and incorrect initialisation of a resource.
• Who is at risk: all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. PHP considers the risk highest for mod_php, with a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.
• PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes; PHP advises contacting your vendor or upgrading. PHP also provides minimal source backports for 7.4 , 8.0 and 8.1 .
• Linux distributions and LTS vendors received the patches in advance, so check your vendor for updated packages.
• The volunteer-maintained Remi repository will not have updates today, and PHP urges its users to switch to distribution packages or build from source.
• PHP 8.2 reaches end of life on 31 December 2026.
• There is no complete mitigation. The measures PHP lists reduce exposure to specific attack paths but do not make an installation safe.

Reported, not confirmed by PHP

• The flaws were nicknamed "php2shell" by watchTowr , which says it reproduced CVE-2026-109618.
• The flaws are reported to reach back as far as PHP 5.4. PHP's advisories list affected versions only as everything below the fixed releases of the supported branches, and do not say how far back they go.
• Details are reported to have leaked before the coordinated disclosure, which was planned for 22 October, and the leaked reports claimed CVSS 10.0 against PHP's official 9.2.
• Attacks against PHP sites were reported on the morning of 21 October, and security researchers expect mass exploitation now that the fix is public.

Who is affected

Any organisation running PHP: content management systems such as WordPress , Drupal , WooCommerce and Adobe Commerce, custom PHP applications, internal portals and intranets, and container images that bundle PHP. If you are not sure whether you run PHP, ask whoever hosts or maintains your website and business applications.

PHP is not only found on web servers. In some cases it also runs on small devices such as IP phones or printers, typically behind their web administration page. These are easy to leave out of an inventory, and a fix for them may depend on the manufacturer releasing a firmware update. Include them in your check, and ask the vendor.

What to do now

1. Update first the systems reachable from the internet to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 (downloads ), or to your vendor's patched package.
2. Inventory every server, container image and hosting account running PHP, with its version, and add any small devices that may run it, such as IP phones and printers.
3. PHP 8.1 or older: check whether your vendor ships a backported fix, or plan the upgrade.
4. Check your package source. If you rely on the Remi repository, do not wait for it today: switch to your distribution's packages or build from source, as PHP advises.
5. Rebuild container images, not just hosts.
6. Put a WAF or reverse-proxy protection in front of internet-facing PHP applications where you can. It reduces risk; it is not a fix.

If you cannot update immediately

PHP says these measures reduce exposure to specific attack paths but do not make an installation safe. They are a stopgap until you can update, and they are PHP's wording, not ours.

• For CVE-2026-109618: set memory_limit=-1, preferably where applications cannot override it; set a low post_max_size (8M for applications without file uploads, 32M with them) with upload_max_filesize below it; and enforce limits at the web server or proxy on decoded request size and on the number of input variables, multipart parts, headers and uploads, and lower max_input_nesting_level; if the application does not use multipart requests, block them there. Do not use RLIMIT_AS or RLIMIT_DATA, which can cause the vulnerable failure.
• For CVE-2026-109619: set session.upload_progress.enabled=0 in php.ini or the FPM pool or server configuration (not with ini_set() or .user.ini) and restart every worker. This blocks the confirmed session paths but not other variants. On PHP 8.5, fatal_error_backtraces=0 blocks the confirmed fatal backtrace path only. The advisory also suggests removing attacker-reachable fatal errors and configuration diagnostics, and, if performance allows, pm.max_requests=1. It says there is no complete generic configuration mitigation.

Debian and Ubuntu

Debian and Ubuntu publish PHP fixes through their own security channels, usually as a patched build of the same PHP version, so a package that still reports an older number such as 8.1.2 or 8.3.6 is not necessarily unpatched. Do not judge your exposure from php -v alone. Debian has published an advisory for these flaws (DSA-6574-1 ); we had not yet seen an Ubuntu notice.

• Debian 13 (trixie). Advisory DSA-6574-1, dated 21 October, covers CVE-2026-109618 and CVE-2026-109619 and recommends upgrading the php8.4 packages; the fixed version is 8.4.27-1~deb13u1. Debian describes the flaws as incorrect memory state tracking that could result in the execution of arbitrary code.
• What each release ships by default (from recent advisories): Debian 12 PHP 8.2 (we have seen no advisory for it yet) and Debian 13 PHP 8.4 ; Ubuntu 22.04 PHP 8.1, Ubuntu 24.04 PHP 8.3 and Ubuntu 26.04 PHP 8.5 (see USN-8564-1 ).
• Ubuntu 22.04 and PHP 8.1. PHP 8.1 is end-of-life upstream. Whether and when Ubuntu publishes a fix for it is for Ubuntu to say; watch its security notices.
• Where to look: the Debian Security Tracker and the Ubuntu Security Notices , searching for the CVE identifiers above.
• To apply an update: run apt update, then apt list --upgradable and look for your PHP packages. apt changelog <package> shows which CVEs a given build fixes.
• Third-party repositories. If you installed PHP from an outside repository or PPA rather than from Debian or Ubuntu, check that repository's own announcement. We have not seen any statement from them.

After you update

• Restart every PHP worker, so that running processes use the new code.
• If you do not use session upload progress, keep session.upload_progress.enabled=0 even after patching: the CVE-2026-109619 advisory recommends it.
• Attacks were reported before the patch was public, so updating alone does not show you were not compromised. Review web server and application logs from 20 October onward, and look for unexpected files, processes and outbound connections.

How Exosys can help

• Emergency patching of PHP servers and containers, as part of our Secure Infrastructure work.
• Compromise assessment if you suspect something has already happened.
• PHP application code audit for the longer term, through our Software Audit service.

If you are not sure whether you are affected, or you would like help, call us on +41 27 508 02 86 or send us a message. Tell us you are asking about php2shell and we will take it from there.

Sources

• PHP.net: security advisory and releases (21 October 2026), and the advance notice (20 October 2026)
• GitHub advisory for CVE-2026-109618
• GitHub advisory for CVE-2026-109619
• BleepingComputer
• Tenable: php2shell FAQ
• Debian Security Tracker
• Ubuntu Security Notices
• Sansec: php2shell