PHP2Shell: Two Critical PHP RCE Flaws, What We Know

October 21, 2026




On October 21, 2026, the PHP project released fixes for two critical flaws in the PHP interpreter itself: CVE-2026-109618 and CVE-2026-109619, nicknamed “PHP2Shell.” PHP’s security team rates each 9.2 under CVSS v4.0. Both can lead to remote code execution, and PHP has demonstrated unauthenticated attacks against Apache with mod_php that run before any application code does.

The release came a day early after details leaked on October 20, and several security firms reported exploitation attempts the same day. Whether those attempts have succeeded anywhere is not established yet. If you run PHP on a web server, the action is simple to state: upgrade to a fixed version and restart the PHP processes.

Quick summary

  • Fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, released October 21, 2026. PHP also issued minimal source patches for 7.4, 8.0 and 8.1, which are end of life.
  • What the flaws are: CVE-2026-109618 is remote code execution through out-of-memory (OOM) corruption. CVE-2026-109619 is remote code execution through stale global state.
  • Severity: 9.2 (CVSS v4.0), assigned by the PHP security team.
  • Highest confirmed risk: Apache mod_php, where an unauthenticated request can trigger the attack before the application runs.
  • Mitigations: PHP says updating is the only complete fix. Configuration changes reduce risk at best, and at least one vendor says a popular one does not protect you.
  • Exploitation: attempts reported by Cloudflare, Patchstack, watchTowr, Hadrian and others. Huntress and CISA had not observed exploitation at the time of their latest updates.

What is confirmed and what is not

Item Status Source
Two critical RCE flaws, CVSS v4.0 9.2 each Confirmed by PHP PHP security advisories (GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp).
Unauthenticated RCE against Apache mod_php, before application code runs Confirmed by PHP and independently reproduced PHP advisory; Datadog Security Labs reproduced it on PHP 8.5.11.
PHP-FPM exploitation for CVE-2026-109618 Not demonstrated PHP says source analysis suggests FPM is susceptible, but a complete FPM exploit has not been shown.
Older versions (PHP 5 to 8.1) are also vulnerable Reported by researchers, not by PHP Datadog says they are vulnerable; PHP’s advisory lists 8.2 to 8.5.
Successful exploitation in real environments Not established Attempts reported; no confirmed compromises in the sources I found.

How it unfolded

Date (UTC) Event
Aug 1–11, 2026 Calif finds multiple RCE paths and reports the first bug to PHP on August 11, per Sansec’s timeline.
Aug 24, 2026 Wiz Research reports the vulnerabilities to PHP (Sansec).
Early Oct 2026 Cloudflare begins developing WAF protections as part of a coordinated effort with the PHP Foundation, OpenAI, Wiz and others (Cloudflare).
Oct 20 A Hacker News post, since removed, leaks word of the upcoming disclosure. watchTowr confirms the flaws are real. PHP publishes advance notice of a release for October 21. CERT-EU publishes Security Advisory 2026-018. The original embargo ran to October 22.
Oct 21, 03:02 Cloudflare’s default WAF protections go live, about nine hours before disclosure.
Oct 21, 07:43 Cloudflare’s CTO says the company is seeing early attacks (per Sansec and Tenable’s FAQ).
Oct 21, ~13:00–13:35 PHP releases the fixed versions, ahead of the 14:00 schedule. Sources differ on the exact minute.

The two flaws

CVE-2026-109618: out-of-memory corruption

PHP uses a C mechanism called longjmp() to abandon a request when it runs out of memory. According to the PHP advisory, an allocation failure can interrupt request setup while incomplete state is already reachable, and the cleanup that follows may then act on that invalid state.

Specially built multipart form requests can push a request to that failure while staying within its apparent limits. PHP validated complete remote code execution over HTTP against mod_php with default input and memory limits. I am deliberately leaving out the request details.

The fix replaces the immediate abort with a delayed, graceful “soft” out-of-memory error at a safe point in the engine, plus an immediate “hard” exit if memory use passes a second, higher threshold. Datadog’s analysis of the patch says shutdown no longer runs normal cleanup over a possibly invalid state.

CVE-2026-109619: stale global state

PHP keeps global state that can point to request memory. According to PHP’s advisory as summarized by vendors, that state can survive after the memory is freed, so a later request handled by the same worker can use a dangling pointer (a use-after-free). The confirmed paths are session upload-progress handling and, on PHP 8.5, fatal-error backtrace state. Exploitation may need two requests, one to leave the stale state and one to use it.

Unauthenticated remote code execution was demonstrated against Apache mod_php. The session upload-progress path was also verified against PHP-FPM under suitable application conditions.

Affected and fixed versions

Branch Support status Fixed release
8.5 Active 8.5.12
8.4 Active 8.4.27
8.3 Security fixes only 8.3.36
8.2 Security fixes until Dec 31, 2026 8.2.35
7.4, 8.0, 8.1 End of life Minimal source patches only. Some commercial long-term-support vendors, such as Zend, say their builds were fixed at release time.
5.x, 7.0–7.3 End of life No fix reported. Researchers say they are vulnerable.

Linux distributions have shipped their own packages. Their version numbers may not match upstream because fixes can be backported, so check the package changelog for the CVE IDs instead of trusting a version number alone.

Is it being exploited?

The picture differs depending on who you ask, and the differences are mostly about what counts as exploitation.

  • Attempts seen: Cloudflare says it observed attack traffic and saw attackers modifying payloads to get around its rules. SecurityWeek reports watchTowr saw exploitation attempts around the time of the patch but not successful ones, and that Patchstack, Cloudflare and Vega also saw attempts. Hadrian said it was seeing exploitation “at scale,” mostly through the session upload-progress path.
  • Nothing seen: Huntress said that as of 4:30 pm ET on October 21 it had not observed exploitation on its partner systems. CISA’s October 21 alert said it had not observed exploitation at publication time.
  • Public exploit code: the Dutch NCSC wrote before the release that public proof-of-concept exploits existed, and SecurityWeek reports PoCs emerging.

My reading: attempts are well documented; confirmed compromises are not. Both can be true at once, because scanning traffic is visible long before a victim notices a breach.

How exposed is the internet?

PHP runs a very large share of websites. Sansec says the flaws affect every web server running PHP 5.4 or later, a claim based on researchers’ work rather than PHP’s own advisory. CybelAngel, citing Shodan banner counts from Mallory, reports about 2.24 million internet-facing hosts advertising PHP. About 59% of those that report a version (883,717 of roughly 1.5 million) are on branches with no official fix.

These counts have limits. They count hosts, not websites. About 740,000 hosts hide their version. Shared hosting puts many sites behind one address, and some distributions backport fixes. Treat them as rough.

What to do

1. Update, then restart

Upgrade to the fixed release for your branch, then restart PHP-FPM, Apache or the web server so the patched build is loaded. Replacing files on disk is not enough while old worker processes keep running.

2. Confirm what is actually running

Check the version your web server reports while serving a request. The command-line PHP binary and the web server’s PHP are often different installations. Also inventory containers, control panels, appliances and vendor products that bundle their own PHP.

3. Expect a changed memory behavior

The patched PHP adds a hard memory limit. When a process reaches it, PHP stops it immediately and shutdown functions do not run, according to a writeup of the fix. If you set memory_limit=-1 as a stopgap, set a real limit again after patching.

4. Use mitigations only as a bridge

  • For CVE-2026-109618, PHP’s main configuration mitigation is enforcing memory_limit=-1 so applications cannot restore a finite limit, plus conservative request-size limits at the web server or proxy. PHP calls this incomplete, and it raises the risk of resource exhaustion.
  • For CVE-2026-109619, PHP lists disabling session.upload_progress.enabled and, on PHP 8.5, fatal_error_backtraces=0, each followed by a worker restart. PHP says these close the confirmed paths but not other variants.
  • A warning: Datadog states that mitigations circulating in the community, including disabling upload progress, do not protect you. Treat them as risk reduction only.
  • WAF rules help but are a stopgap. Cloudflare describes its rules that way, and they only cover traffic that goes through Cloudflare. Sansec notes the attack reaches PHP before an application’s own filters.

5. Plan for end-of-life branches

If you run PHP 8.1 or older with no commercial support, treat the machine as exposed. CERT-EU’s advice includes restricting access to affected applications until you can remediate.

6. Look for signs of attack

Datadog suggests checking for large form submissions, memory-exhaustion errors during request initialization, and unexpected shell processes launched by PHP workers. A successful exploit does not always crash the worker. Reduce the privileges and secrets available to the PHP account, since code execution there exposes whatever that account can read.

Claims checked

The longer write-up this article is based on contains a mix of accurate details and statements I could not support.

Claim Status Note
Fixes released October 21, 2026 in 8.5.12, 8.4.27, 8.3.36, 8.2.35; CVSS 9.2 Confirmed PHP advisories and release notices.
Details leaked two days before the announcement Qualified Leak on October 20 against an original embargo of October 22. PHP then released on October 21.
Cloudflare deployed WAF protection about nine hours before disclosure Confirmed Cloudflare’s blog post: live from 03:02 UTC October 21, work begun in early October.
Mass exploitation was underway before the patch Overstated Attempts were reported before release. Successful compromises are not confirmed.
All PHP web servers are exposed Qualified PHP’s advisory lists 8.2 to 8.5 before the fixes. Older versions are reported as vulnerable by researchers. Exploitability varies by server setup.
“PHP-FPM is vulnerable under other conditions” Qualified No complete FPM exploit has been shown for CVE-2026-109618. For CVE-2026-109619, the upload-progress path was verified on FPM under suitable conditions.
“The most severe flaws in PHP’s history” Unsupported No source ranks them. Removed.
“Flaws that can’t be patched away” Incorrect Patches exist for supported branches. It is the configuration workarounds that are incomplete.
The bug traces to a 2024 Quarkslab audit finding, and the fix was delayed by lack of resources Not verified The 2024 Quarkslab audit is real (27 issues, 17 with security impact). I could not open the PHP Foundation post that supposedly links it to these flaws, so I left it out.
Joint ENISA, Europol, NCSC (UK), BSI and Canadian statements Partly verified I confirmed CERT-EU Security Advisory 2026-018, a CISA alert and Dutch NCSC commentary. I did not confirm the other agency statements.
CISA classified the flaws as “not automatable” Not verified I only confirmed that CISA’s alert reported no observed exploitation at the time.
About 70% of websites use PHP Not re-verified A commonly cited W3Techs figure. I did not check the current value.

My take

I haven’t tested these flaws or run an exploit, and this is my reading of the published material.

  • The message to take is “patch and restart,” not “it can’t be fixed.” The fixes exist. The hard cases are old PHP branches and appliances that bundle their own PHP.
  • Be careful with comparisons to Log4Shell. The “PHP2Shell” name invites it, and the reach of PHP is large. But so far the evidence shows exploitation attempts, a specific demonstrated path (mod_php) and gaps (FPM for one flaw). Real-world impact will depend on server configuration.
  • The coordinated-disclosure process held up unevenly. Months of quiet coordination with vendors such as Cloudflare meant protections were live before the release. Yet a leak still forced the release forward by a day, and attackers had a head start. Both parts are worth remembering.

What this means for you

  1. Find every place PHP runs in front of the internet, including shared hosting, containers, control panels and appliances.
  2. Patch internet-facing systems first, then restart the PHP processes and verify the version a real request reports.
  3. If you use managed hosting, ask your provider when it will patch and whether it has already restarted workers.
  4. If you can’t patch today, apply PHP’s temporary mitigations and a WAF, restrict access to sensitive applications, and treat all of it as temporary.
  5. Retire or isolate end-of-life PHP. Plan the upgrade for PHP 8.1 and older, or use a commercial long-term-support build.
  6. Check for compromise on exposed servers, and rotate database passwords and API keys if you find signs of one.
  7. After patching, restore any real memory limit you replaced with memory_limit=-1.

Frequently asked questions

Is updating WordPress or my plugins enough?

No. The flaws are in the PHP interpreter, not in WordPress or any plugin. Updating the application does not fix the runtime. Update PHP on the server, or have your host do it.

Can I rely on a WAF instead of patching?

No. Cloudflare calls its rules a stopgap, and they only cover traffic that passes through it. Sansec warns the attack can reach PHP before an application’s own filtering.

Do I need to restart anything after upgrading?

Yes. Restart PHP-FPM or the web server so the patched build loads. Until the old processes are replaced, you are still running the vulnerable code.

Sources

Tags

You Might Like

Show more
CVEs

Post a Comment

0Comments

Post a Comment (0)
Share to other apps
Copy Post Link