PHP2Shell Attacks: Update the Runtime Behind Your Website

PHP released emergency security updates on October 21 for two flaws that can let an unauthenticated attacker execute code on a web server. [1] Cloudflare says it has already observed attack traffic targeting the bugs, collectively called PHP2Shell, including changes to malicious requests aimed at evading its defenses. Its report does not establish whether those attempts led to successful compromises. [4]

Website owners should update the PHP runtime to 8.2.35, 8.3.36, 8.4.27 or 8.5.12, or install a vendor package that explicitly fixes both CVEs. Updating WordPress, a theme or a plugin does not replace that server-side repair. On managed hosting, ask the provider to confirm the patched package is actually running for your website.

A request can reach the flaw before the website runs

The vulnerabilities are tracked as CVE-2026-109618 and CVE-2026-109619. Both carry a critical CVSS v4.0 score of 9.2. PHP identifies Apache with mod_php as the highest-risk deployment: researchers demonstrated code execution through an unauthenticated HTTP request before the application itself started.

That timing matters. A login check or a carefully maintained CMS cannot protect code that has not started running yet. PHP first has to interpret incoming request data, and some of that work happens below the application’s security controls.

In CVE-2026-109618, an out-of-memory failure can interrupt PHP while internal request structures are only partly initialized. The subsequent cleanup can use those invalid structures. PHP’s advisory describes multipart request handling that can consume far more memory than the request’s apparent size suggests. Successful exploitation runs code with the web worker’s account permissions; it does not automatically grant root access. [2]

CVE-2026-109619 crosses the boundary between requests. A worker can retain internal pointers to memory belonging to a finished request. When that worker handles another request, an operation can touch the stale state before normal initialization replaces it. Session upload-progress handling is one confirmed route. It is enabled by default and does not require the application to call session_start(). [3]

PHP-FPM needs the update too

The strongest mod_php demonstration should not be read as a universal exploit for every PHP deployment. Build options, extensions, application behavior and request handling affect exploitability.

For the out-of-memory flaw, PHP says source analysis supports PHP-FPM susceptibility, while no complete FPM exploit for that specific flaw has been demonstrated. For the stale-state flaw, however, the advisory describes a validated FPM path: a suitable application operation leaves state behind after successful startup, a fatal error interrupts its cleanup, and a later request reaches it through upload-progress handling.

PHP therefore urges updates for all installations serving web requests, including FPM, mod_php, CGI, FrankenPHP and LiteSpeed. The different prerequisites explain the risk; they do not make switching handlers a complete remedy.

Which PHP packages contain the fixes?

Distribution packages can carry the fixes under older-looking version numbers. Ubuntu’s October 21 notice, for example, lists 8.3.6-0ubuntu0.24.04.13 for Ubuntu 24.04 LTS and 8.1.2-1ubuntu2.28 for 22.04 LTS. The full package revision and the vendor’s advisory matter when checking a backport. [5]

PHP 8.1 and older no longer receive supported releases from the PHP project. Some distributions and LTS vendors supply backports, and PHP’s security team has provided minimal source patches for 7.4, 8.0 and 8.1. Those patches do not restore normal support for obsolete branches. Obtain an explicit vendor fix or move to a compatible supported release.

Confirm the web worker was replaced

Inventory each PHP installation that serves traffic, including containers, hosting-panel runtimes and bundled web applications. Apply the relevant vendor update, then restart or replace the affected PHP workers so they load the corrected code. A host with several PHP versions can have one patched website and another still exposed.

The command-line result from php -v identifies that particular executable. It does not by itself prove which runtime an Apache module, FPM pool or container uses. Confirm the handler and package assigned to the website, then check that the application works after the update.

Cloudflare’s observed attempts make a web application firewall (WAF) useful additional protection, but PHP says only an update completely addresses the vulnerabilities. The project’s temporary settings cover particular paths and have operational consequences; disabling upload progress alone does not fix every variant.

Keep the runtime repair separate from incident recovery. If a site has unexpected files, accounts or outbound connections, patching does not establish that earlier access never happened. Preserve relevant logs and investigate those signs. The immediate decision is to get the running web stack onto a confirmed fixed package.

October 23 update: investigate from before disclosure

Amazon’s October 21 report dates a PHP2Shell attempt in its MadPot honeypot network to October 17, four days before public disclosure. It also records further attempts before the embargo lifted. Amazon says it remains unclear whether those attempts would have succeeded on real systems. [6]

For a potentially exposed site, preserve and review available logs from at least October 17, rather than beginning only on patch day. Correlate unusual requests with unexpected process execution and file changes. Amazon cautions that its listed source IPs include shared anonymization infrastructure; a matching address warrants investigation and does not by itself prove compromise.

October 27 update: both flaws are now in CISA’s exploited catalog

On October 26, CISA added both CVE-2026-109618 and CVE-2026-109619 to its Known Exploited Vulnerabilities catalog. Each entry gives an October 29 response date, marks forensic triage as required in the catalog’s response guidance and lists use in ransomware campaigns as Unknown. The addition is stronger evidence of real-world exploitation than a proof-of-concept release; it does not establish that every vulnerable website was compromised or that either flaw was used for ransomware. [7]

For a site owner, prioritize confirming the running web handler’s fixed PHP package and preserving incident evidence alongside the update. The catalog date is not a reason to wait until October 29 on an exposed server. Keep the earlier October 17 investigation window above: the date an issue enters KEV is not the first possible attack date. Replacing a vulnerable runtime closes that exposure, while unexpected processes, files or accounts still need separate investigation.

References

1. PHP Group. Security advisory: Critical remote code execution vulnerabilities. October 21, 2026; accessed October 21, 2026.
2. PHP Security Team. RCE via OOM corruption — CVE-2026-109618. GitHub Security Advisories, October 21, 2026; accessed October 21, 2026.
3. PHP Security Team. RCE via stale global state — CVE-2026-109619. GitHub Security Advisories, October 21, 2026; accessed October 21, 2026.
4. Molteni, D., Jones, D., and Nandwani, K. Cloudflare deploys protections against php2shell vulnerability. Cloudflare, October 21, 2026; accessed October 21, 2026.
5. Canonical. USN-8948-1: PHP vulnerabilities. Ubuntu Security Notices, October 21, 2026; accessed October 21, 2026.
6. Moses, C. J. Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot. AWS Security Blog, October 21, 2026; accessed October 23, 2026.
7. CISA. Known Exploited Vulnerabilities Catalog: CVE-2026-109618 and CVE-2026-109619. Entries added October 26, 2026; accessed October 27, 2026.