PHP2Shell: the fix shipped on 21 October. Is it on your servers?

PHP2Shell is the nickname for CVE-2026-109618 and CVE-2026-109619, two critical flaws in the PHP runtime itself that can allow unauthenticated remote code execution. The PHP project says all PHP installations serving web requests are at risk. On 21 October 2026, it fixed them in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and Debian, Ubuntu, Red Hat, Alpine and the Docker official images had fixed builds the same day. As of 24 October 2026, an organisation’s exposure depends on how fast its own servers, images and running workers pick them up.

This post covers the flaws, affected versions, how fast the fix travelled, exploitation, why a version number is not proof, and a dated plan.

What is PHP2Shell, and what does the PHP project say?

Both vulnerabilities sit in PHP core (php-src), not in any application built on it. The PHP project rates both critical, at CVSS v4.0 9.2:

• CVE-2026-109618 (GHSA-w8hw-w9fx-j79w). Out-of-memory handling can leave internal request data partially initialised, and request cleanup may then treat it as valid.
• CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp). State from one request can outlive its freed memory and be used by a later request on the same worker.

The advisory covers PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed; the project considers the risk highest for mod_php, where its demonstrated exploit lets an unauthenticated request trigger the attack before any application code runs.

NVD scores CVE-2026-109618 at 9.8 and CVE-2026-109619 at 8.1 (CVSS 3.1). Red Hat rates both Important (8.1) and notes, for CVE-2026-109618, that reliable exploitation requires precise heap manipulation and timing, and that standard RHEL deployments use PHP-FPM rather than mod_php. For CVE-2026-109619, the PHP security team says “Unauthenticated RCE has been demonstrated against Apache mod_php and PHP-FPM.” Record the SAPI to set the order of work, not to decide whether to patch.

Because the flaws sit in the runtime, updating application code does not fix them; php.net says there are no complete mitigations and “updating is the only safe choice”.

Wiz, one of the reporting firms, gave the name to its demonstration exploit and uses it for the wider research (php2shell.com). The PHP project does not use it.

Which PHP versions are affected by PHP2Shell?

The PHP security team’s announcement lists as affected 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27 and 8.5 before 8.5.12. PHP 8.1 left security support on 31 December 2025, so the project issued no 8.1 release for PHP2Shell; for 8.1, 8.0 and 7.4 the team published minimal source backports, and Ubuntu 22.04 LTS ships a fixed php8.1 (8.1.2-1ubuntu2.28).

Branch	Fixed release from the PHP project	Upstream security support until
8.5	8.5.12	31 December 2029
8.4	8.4.27	31 December 2028
8.3	8.3.36	31 December 2027
8.2	8.2.35	31 December 2026
8.1, 8.0, 7.4	No release; minimal source backports	Ended 31 December 2025, 26 November 2023 and 28 November 2022
7.3 and older	No fix from the PHP project	Ended

Wiz says releases back to PHP 5.4 are affected by at least one flaw; that is the reporters’ figure, not the project’s.

Distribution branches are not upstream branches: Red Hat fixed php 8.0 on RHEL 9 and 7.4 on RHEL 8 on 21 October, and 5.4 on RHEL 7 Extended Lifecycle Support (CVE-2026-109619) on 23 October. An end-of-life branch is patched only if a vendor you pay or trust maintains that exact package, or if you build it from the project’s minimal backports.

How fast did the fix reach distributions and images?

The PHP project says “Linux distributions and LTS vendors received the patches in advance”; the record confirms it.

Date and time (UTC)	What happened	Source
20 October 2026, about 15:00	CVE IDs leak with a wrong time and score, no technical details	PHP Foundation
20 October 2026, 19:30	Pre-announcement; release moved from 22 to 21 October	PHP Foundation, php.net
21 October 2026, 13:34	PHP advisories and fixed releases published	GitHub
21 October 2026, 13:45	Debian DSA-6574-1, php8.4 for Debian 13	Debian
21 October 2026, 14:11	Debian DLA-4848-1, php8.2 for Debian 12	Debian LTS
21 October 2026, 15:16	Docker official-images definition updated; fixed tags on Docker Hub by about 16:00	Docker, repo-info
21 October 2026, 16:29 to 16:38	Alpine 3.24 php85 and php84 packages built	Alpine
21 October 2026	Ubuntu USN-8948-1 and USN-8948-2; Red Hat errata for RHEL 8, 9 and 10; Swiss NCSC warning	Ubuntu, Red Hat, NCSC
23 October 2026	php.net advisory on session upload progress (CVE-2026-115560); CERT-EU update	php.net, CERT-EU

By the evening of 21 October 2026, each channel offered fixed builds for its main PHP branches, though not for every stream: when we checked again on 31 October 2026, Red Hat still listed the RHEL 9 php:8.4 stream as affected. The rest belongs to the operator: pull, rebuild, redeploy, restart, verify.

Is PHP2Shell being exploited?

Keep apart three things known on 24 October 2026, then what has been confirmed since.

The leak. On the evening of 20 October, a reporting firm published a video by mistake, which the PHP Foundation says sped up proof-of-concept work.

Reported attempts. Cloudflare said on 21 October that it “observed attack traffic targeting our customers”. Amazon Threat Intelligence reported on 21 October that its MadPot honeypot telemetry holds an attempt dated 17 October, four days before disclosure, and more on 21 October, though “it’s unclear if any of these attempts would have succeeded in real-world systems”. watchTowr says its honeypots observed exploitation of both CVEs on 21 October. VulnCheck reports hundreds of proof-of-concept repositories, “only a very small number” of them legitimate, and at least one failed attempt on its canary hosts on 21 October.

Not confirmed. The Foundation says the security team “did not identify any functional exploits at the time of release/public disclosure”. CISA’s enrichment in the CVE record, dated 21 October 2026, reads “Exploitation: none”, and neither CVE was in CISA’s Known Exploited Vulnerabilities catalogue in its version of 23 October 2026.

Confirmed since. On 26 October 2026, CISA added both CVEs to the catalogue, with a due date of 29 October for US federal agencies. On 28 October it added a Linux kernel flaw, CVE-2026-46300, and noted that it “can be chained with CVE-2026-109618 and CVE-2026-109619 to implant PHP webshells and run commands as root”. On 29 October, Palo Alto Networks’ Unit 42 said the flaws “are being actively exploited against PAN-OS management interfaces”, in a campaign reported by Dream Research that chains them with a Linux kernel privilege-escalation flaw; Unit 42 says it “independently verified the same attacker’s tooling”. Its advice is to remove public internet access to those interfaces.

CERT-EU’s Security Advisory 2026-018 says circulating proofs of concept raise the likelihood of exploitation and advises patching immediately. Switzerland’s National Cyber Security Centre (NCSC) says to update without delay. Schedule the fix as if the flaws were exploited: a KEV entry should confirm the priority, not set it. Here it came five days after the fixed releases.

Why the version number on your server is not proof

Backported packages keep old numbers. On Ubuntu 24.04 LTS the fixed package is 8.3.6-0ubuntu0.24.04.13, numerically below upstream 8.3.36. As the NCSC puts it, “The exact package version and the security information provided by the respective provider are decisive.” Check the package changelog for both CVE IDs (for example apt changelog php8.3 | grep -E 'CVE-2026-10961[89]' or rpm -q --changelog php | grep -E 'CVE-2026-10961[89]') or the vendor’s tracker.

Images keep the PHP they were built with. A container gets the fix only when its image is rebuilt on a fixed base and redeployed, after any pinned base tag is bumped. The Docker official php:8.1 tag was last pushed on 2 January 2026, so rebuilding on it changes nothing.

Running workers keep the old code. The NCSC asks operators to “restart the affected PHP services and any PHP processes running continuously”.

Some PHP is hidden. PHP “may also form part of administration interfaces, internal specialist applications, hosting platforms, containers or appliances”, the NCSC warns. The firewall campaign Unit 42 described on 29 October is that case: the PHP under attack ran inside management interfaces reachable from the internet. Ask each supplier for its status in writing.

The NCSC’s test is whether “the applications actually running are using the patched PHP version”. Keep the evidence: package version, image digest and restart time.

What to do, and by when

Dates are our suggestion, except 31 December 2026, php.net’s end of security support for PHP 8.2.

1. At once, from 24 October 2026: patch or isolate every internet-facing PHP you know of. Install the fixed package or release, rebuild and redeploy images, restart every worker, and check the running instance. If that cannot happen at once, restrict access or take the system off public networks until the fix is applied and verified (CERT-EU); the NCSC warns that “a web application firewall alone is not sufficient”. Since 28 October 2026, add the kernel: on hosts that run PHP, install your distribution’s update for CVE-2026-46300 and reboot into it, because CISA says the two can be chained to run commands as root.
2. By 26 October 2026: finish the inventory, then patch what it finds by 28 October. Include internal and embedded PHP, and record host or image, package source, exact package version, SAPI, exposure and owner. Wazuh, which reports vulnerabilities per server, helps.
3. Until PHP’s next regular bugfix release: set session.upload_progress.enabled=0 in php.ini, the FPM pool or the server configuration, not with ini_set() or .user.ini, and restart workers. php.net’s advisory of 23 October recommends it against CVE-2026-115560, an “unlikely RCE vector” the releases of 21 October do not fix; it says applications that never change session.serialize_handler at runtime can keep it enabled.
4. By 31 October 2026: look for signs of compromise on anything exposed: crashes, unusual requests, modified files, unexpected processes. An update “does not remedy any compromise that has already occurred” (NCSC): if you find one, rebuild and restore from a tested backup taken before the first sign of compromise. On internet-facing systems that ran an unpatched PHP, consider rotating secrets: Wiz says passwords, authentication tokens, API keys and certificates in process memory can be disclosed without code execution.
5. By 31 December 2026: leave PHP 8.2, which gets no security fixes after that date, and any older branch without a named vendor backport. Write “no runtime past security support” into policy.
6. At the next review or renewal: write the patch target down: how fast a runtime fix reaches production, who approves an emergency change and what record you receive. See our CRA supplier questions.

The fix was public: what decides the rest is operations

The coordinated disclosure went as open-source practice intends, despite a leak two days before the planned release date. Researchers reported privately, the PHP security team fixed every supported branch, distributors had the patch in advance, and fixed packages shipped on release day.

The PHP Foundation published its own account on release day: who reported what and when, what slowed the fix, the Ecosystem Security Team it created in May 2026 and the process changes under way. It asks organisations that depend on PHP, public institutions included, to fund that work. A dated, public account of how a fix was made is evidence a buyer can weigh.

Runtime flaws exist in every stack, proprietary ones included. What open source adds is a fix you can inspect and obtain through several independent channels. What it does not add is someone obliged to rebuild your images and restart your workers. Modern practice closes that gap:

• Runtimes in the inventory, with version, package source and SAPI.
• Only supported runtimes, each with its end-of-support date.
• Images rebuilt from pinned, scanned bases, in a registry that rescans on a schedule, such as Harbor with Trivy.
• A patch pipeline that ends with a verified restart, not a merged change.
• Independent, tested backups and a record of advisory, plan, approval and result.

How Pilae fits

Closing that gap is an operator’s job. Pilae operates open-source apps on your premises or on dedicated machines in Pilae Cloud in Switzerland and the EU. On premises, Pilae runs everything from the operating system up; in Pilae Cloud, the whole stack. The split is an annex to your contract, and approvals stay with you.

• Every app and machine on one screen. The console shows each app’s version, machine and health, each machine’s operating system, and pending updates and advisories next to the app they affect.
• Advisories matched to your versions, a critical fix on your desk within hours. Upstream advisories for every app you run are tracked against your versions, on hardened machines with automatic security updates for the base system. The Pilae Agent plans each fix with a verified backup and a rollback; it is applied in your agreed window, or at once if you approve an emergency change.
• Private by default. CERT-EU’s fallback for an unpatched system, keeping it off public networks, is where every app starts: apps answer only on the private network, and the internet sees one hardened gate on port 443, with only the routes you approve.
• Checked and recorded. After a fix, probes confirm the app answers, and the run is written to the audit log, exportable to your SIEM.
• Roles and backups in writing. Under managed operations, the responsibility matrix says who plans, approves and applies, and backups are daily, encrypted and offsite, with a restore test every month on the Enterprise plan.

The fixes for open-source runtimes are public. Getting them onto every server fast, with a record, is work that can go into a contract. To find out how fast a runtime fix would reach production in your estate, talk to an engineer: we go through the apps you run, the runtimes under them, and what running them properly would involve.