PHP2Shell: What the Critical PHP Vulnerabilities Mean for Your Organization

On October 21, 2026, the PHP project released patches for two critical vulnerabilities that allow adversaries to execute code on web servers without authentication. Every PHP installation that serves web requests is affected, from the WordPress blog to the firewall interface. This advisory tells you what to do and what to look for in your logs.

Audience

Operators of web applications and appliances in Germany, Austria and Switzerland, CISOs, heads of IT, SOC, hosting managers

Regulation

NIS2 / BSIG Section 30 · DORA · ISO 27001:2022

Classification

TLP:CLEAR, sharing permitted

As of

October 23, 2026, 9:00 a.m., version 1.4

Sources

PHP project, BSI, ENISA, CERT-EU, CIRCL, CERT-FR, NCSC UK, NCSC-NL, BACS, CERT.at, CISA, FBI, Amazon, Wiz, VulnCheck, Sansec, ELLIO, Dataminr, CrowdStrike, Datadog, Cloudflare, Imperva, Unit 42, Palo Alto, Fortinet, Cisco, Netgate, OPNsense, QNAP, Synology, Debian, Ubuntu, Red Hat

Changes

Version 1.4 of October 23, 2026, 9:00 a.m. New: NCSC-NL is investigating first signs of successful exploitation, exploit status from VulnCheck, vendor overview (PAN-OS, Fortinet, Cisco, pfSense, OPNsense, QNAP, Synology), Debian bookworm and Red Hat corrected, regression in 8.4.27 and 8.5.12. Earlier versions: 1.3 (Oct. 22, 5:30 p.m.), 1.2 (Oct. 22, 10:00 a.m.), 1.1 (Oct. 21, 10:30 p.m.), first version Oct. 21, 6:00 p.m.

The vulnerabilities are not in WordPress, TYPO3 or pfSense but in the runtime underneath, which receives every request before the application runs. Confirmed paths: the session upload progress feature, which is enabled by default, and, in PHP 8.5, the backtraces of fatal errors. This is how the attack works:

On the state of exploitation as of October 23: Amazon confirms a honeypot attempt under embargo as early as October 17 and, since disclosure, has seen several actors with anonymized infrastructure, without knowing whether any of them would have succeeded against real systems. ELLIO saw Mirai loaders, DDoS booters and a Go remote access agent as payloads: botnet operators, not targeted adversaries. VulnCheck has its own exploit for PHP 8.4.10 to 8.4.26 and knows of no other that executes code on several versions; of the hundreds of PoCs on GitHub, only a few are genuine, and one bypasses ASLR on x86-64, but only on 8.4.26 with a standard heap. Sansec therefore considers mass exploitation less likely than assumed on the first day, and Dataminr sees only scans and unusable exploits. On the other hand, NCSC-NL has been investigating “first signs of successful exploitation” since October 22, without details. The BSI knows of no confirmed compromise in regulated industry or the federal administration and considers reports of bypassable patches refuted; the KEV catalog does not list the vulnerabilities. Quiet is still no proof: a successful attack leaves hardly any traces (see below), and according to the BSI, the number of vulnerable systems worldwide remains very high.

According to the PHP project, all installations that serve web requests are affected. The risk is not the same everywhere, and the order of patching should reflect that.

With distributions, the package version counts, not the major version: Debian and Ubuntu backport the fix, and php -v still shows 8.3.6. Red Hat (Important, CVSS 3.1: 8.1) published errata for RHEL 8, 9 and 10 on October 21; php:8.4 on RHEL 9 and RHEL 7 are still pending. Rebuild Docker images. For appliances, the vendor delivers the fix, and the status is mixed (Palo Alto, Fortinet, Cisco and Sophos know of no exploitation against their products; NCSC-NL and the BSI list further vendors):

Taking systems offline remains the fallback option for systems that receive neither the patch nor the interim measures; the BSI, NCSC UK, NCSC-NL, FBI and CISA recommend it this way, and QNAP explicitly does so for its NAS devices. Since October 22, Sansec no longer considers it necessary for online shops. If you can patch, patch and stay online.

CrowdStrike describes how a successful attack leaves almost no trace. The worker remains stable, the response is HTTP 200, and the application logs stay empty because no application code runs. The only reliable server-side trace is said to be a single memory-limit error in the error log, which is dismissed as noise in operations. If you do not evaluate these lines, you will not see the attack.

There are still no confirmed indicators: the BSI does not recommend the IOC lists in circulation, and CIRCL calls its observation points hunting approaches. Amazon, VulnCheck and ELLIO have named source IPs but ask that they be investigated rather than blocked, because anonymization and hosting addresses rotate. What holds up is the behavior, not the address. A quick search is still worthwhile: VulnCheck saw scanners with self-named user agents (php2shell-scan, php2shell-verify, php2shell-poc), trivial to change, but found in the access log in seconds.

Instructions for IT, in this order

1. Secure the logs: web server access and error logs, PHP-FPM, application, host/syslog, proxy and WAF, retroactively from October 17 (earliest known attempt, Amazon) and before workers are restarted.
2. Search access logs from October 17 for multipart POSTs with HTTP 500, for burst patterns per source IP, for POSTs with PHP_SESSION_UPLOAD_PROGRESS on endpoints without uploads and for the php2shell user agents.
3. Check the length of Set-Cookie: PHPSESSID in the response logs, if it is logged at all. If it is not logged, note it as a gap: it cannot be reconstructed after the fact.
4. Review error logs for “Allowed memory size exhausted” before script start, for segfaults and for OOM kills of the workers.
5. Host side: new PHP files in the web root, modified .htaccess, executable files in /tmp, child processes of the web user, outbound connections to unknown destinations.
6. Document a positive or negative finding for each system. The negative finding is what you will later need for customer communication and as audit evidence.

Four core signals:

For the error log to show anything at all: log_errors=On, a working error_log and error_reporting=E_ALL, according to the PHP project. An overlong PHPSESSID cookie means leaked credentials and tokens, which must be rotated after the patch.

On the “exploits” in circulation: CERT.at and Tenable warn of malicious code in them. The real attack does not write a web shell to the web root; it bends memory in the running process. Any short script that drops a file and calls it is a fake.

All information comes from the linked sources; times in CEST, as of October 23, 2026, 9:00 a.m. (version 1.4). Observations of attack attempts are vendor statements (Amazon, VulnCheck, ELLIO and others) and are marked as such; the mapping to ISO 27001:2022 A.8.8 and to the CIS Controls is our own classification. The advisory will be updated as soon as exploitation is confirmed or reliable indicators are published.

Glossary

Worker

PHP process that handles many requests one after another; its state is at the core of CVE-2026-109619

Multipart

HTTP format for forms with file uploads; the entry point for CVE-2026-109618

Backport

Fix in an older package version; the version number stays the same, the patch is included

KEV

Known Exploited Vulnerabilities: CISA catalog of vulnerabilities proven to be exploited