PHP2Shell Attacks Are Underway: What Unpatched Servers Face Now

Pandromeda's Security desk covered PHP's emergency patch release for php2shell on October 25, and our Software desk flagged the initial disclosure two days before that. What's changed since then is the threat model. This is no longer a theoretical "patch before someone figures out how to weaponize it" problem. It's an active one: multiple security vendors now say they're observing real exploitation attempts against production PHP servers, days after fixed versions became available.

What's new: attempts are happening now, not hypothetically

The two vulnerabilities were disclosed on October 21, 2026, when PHP's security team published GitHub Security Advisories GHSA-w8hw-w9fx-j79w (CVE-2026-109618) and GHSA-6wmf-4rv5-p3rp (CVE-2026-109619), both authored by PHP core contributor bukka and both rated Critical. Fixed releases — PHP 8.5.12 and 8.4.27 — followed within a day, per PHP's own ChangeLog, with 8.3.36 and 8.2.35 shipping alongside them.

In the days since, the exploitation picture has shifted from "attackers are probably trying" to vendors actively documenting attempts. Sophos's advisory for the flaws, SA-20261021-php2shell, states plainly that active exploitation has occurred, pointing to an exploitation attempt that Amazon Threat Intelligence reported on October 17 — before the advisories were even public — and noting that other security vendors have since reported further attempts. Tanium's response write-up on the two CVEs attributes to researchers at watchTowr the observation that exploitation attempts hit its global honeypot network, and separately notes that Cloudflare's chief technology officer described early attacks against Cloudflare's own infrastructure.

Not every vendor is telling the same story at the same pace, and that's worth being honest about. Huntress's own incident write-up, last updated the afternoon of October 21, said that as of that update it had "not observed in-the-wild exploitation on partner systems," while noting that other researchers were reporting attacks emerging elsewhere. That gap is normal: different vendors watch different slices of the internet, and a flaw can be under active attack against some populations of servers (unpatched honeypots, high-value targets, internet scanners' favorite ports) well before it shows up in any one vendor's telemetry. Taken together, the vendor reporting over the past several days points the same direction: attempted exploitation is real and ongoing, even though a single, universally confirmed "mass compromise" event has not been publicly documented by any one source as of this writing.

The two flaws behind php2shell, briefly

Both bugs live in PHP's request-handling internals rather than in a specific extension or application, which is part of why they're rated so severely.

CVE-2026-109618 stems from how PHP uses longjmp() to bail out of out-of-memory (OOM) errors. In some code paths, request memory becomes reachable before it's fully initialized; if an allocation fails at that point, PHP doesn't cleanly unwind, and the subsequent request-shutdown routine can read or branch on that invalid memory. PHP's advisory says several multipart-parsing patterns — requests without a usable declared content length, parts with unbounded headers, or empty file fields combined with nested field names — can trigger the OOM condition within normal PHP memory limits. The advisory states unauthenticated RCE was validated over HTTP against mod_php running default settings, and considers mod_php and FrankenPHP the most likely targets, with PHP-FPM considered less susceptible (no complete FPM exploit chain was demonstrated in the advisory).

CVE-2026-109619 is a stale-global-state use-after-free. PHP workers that handle multiple requests keep global state — error, session, object and extension state — that can still point at memory from a prior request after that request's heap has been freed. Certain operations that run before normal request initialization can read or free that stale memory. PHP's advisory identifies two confirmed trigger paths: warnings or deprecation notices raised while applying INI settings before request initialization, and session upload-progress handling, which can run before ordinary session setup. The advisory states the confirmed impact is unauthenticated heap use-after-free, memory disclosure, and RCE with the web worker's own privileges — validated against mod_php for the backtrace path, and against both mod_php and PHP-FPM for the session upload-progress path.

Both carry a CVSS v4.0 base score of 9.2 (Critical), with an identical vector — network-exploitable, no privileges or user interaction required, though attack complexity is rated High and the advisories note the attack requires specific request conditions to be present.

Public exploit code is circulating, with mixed reliability

Tanium's write-up, citing exploit-tracking firm VulnCheck, says dozens of public proof-of-concept exploits for the php2shell flaws exist, but that very few actually work, and none have been shown to bypass ASLR protections on x86-64 systems — a meaningful barrier to turning a crash into reliable remote code execution. The same write-up warns that exploit code tends to mature quickly once a patch diff is public (since the diff effectively documents the bug), and flags that fake proof-of-concept repositories posing as working exploits for headline CVEs are a known vector for distributing malware to researchers who go looking for them.

That nuance matters for risk assessment: "exploit code exists" and "exploit code reliably works against a hardened target" are different statements. But for any server still running an unpatched, internet-facing PHP install, the practical takeaway is the same — the barrier to attempting exploitation has dropped substantially since October 21, and probing activity documented by multiple vendors suggests attackers are testing which targets are reachable.

Affected and fixed versions

Both CVEs affect the same four supported PHP branches. PHP versions 8.1 and earlier are no longer supported by the PHP project and do not receive an official fixed release for either flaw.

According to PHP's own ChangeLog, both 8.5.12 and 8.4.27 record the fix under the Core component as resolving GHSA-w8hw-w9fx-j79w and GHSA-6wmf-4rv5-p3rp, describing it as work to "avoid state corruption via bailout." That's the same underlying fix referenced in both GitHub Security Advisories: PHP's OOM handling no longer relies on an unsafe longjmp() escape. Instead, it uses a delayed "soft OOM" check at the next safe point in the virtual machine, plus an immediate hard OOM via _exit() if memory pressure crosses a higher threshold.

Is php2shell in CISA's KEV catalog yet?

As of this writing, no. A direct check of the current CISA Known Exploited Vulnerabilities catalog data — which lists 1,756 entries — turns up no entry for CVE-2026-109618 or CVE-2026-109619. CISA's KEV catalog is reserved for vulnerabilities the agency has independently confirmed are being exploited, and it typically trails vendor-level exploitation reporting by days to weeks. Its absence from KEV right now is not evidence that exploitation isn't happening; it mainly reflects that CISA's own confirmation and cataloging process hasn't caught up yet.

The vulnerability records themselves are in better shape than they were immediately after disclosure. Early last week, some researchers flagged that MITRE and NVD records for both CVE IDs were missing or inconsistent in the hours after the advisories went public — notable, if true, mainly as a sign of how compressed the disclosure timeline was, not as any reason to doubt the underlying flaws. That gap has since closed: NVD's current records for both CVE-2026-109618 and CVE-2026-109619 now carry the status "Analyzed," with a CVSS v4.0 base score of 9.2 sourced directly from PHP's own security team, and were last modified on October 26. The PHP project's GitHub Security Advisories were authoritative from the moment they were published on October 21, regardless of any temporary indexing lag on NVD's side.

Who's still exposed

Precise counts of affected servers vary across vendor exposure scans and aren't something we can independently verify, so we won't repeat a specific figure here. Qualitatively, the exposure is broad: any internet-facing PHP application running an unpatched version of 8.2 through 8.5 — and, separately, any server still running PHP 8.1 or earlier, which gets no official fix at all — is a candidate. mod_php deployments and FrankenPHP are flagged by PHP's own advisory as most directly exposed for CVE-2026-109618, since that's where unauthenticated RCE was validated end to end. Sites relying on PHP-FPM are not confirmed safe; CVE-2026-109619's session upload-progress path was validated against PHP-FPM as well as mod_php, even though a complete FPM exploit chain wasn't demonstrated for CVE-2026-109618 specifically.

Shared hosting environments, content management systems, and any self-managed server where PHP updates aren't automated are the highest-risk category, simply because they're the ones most likely to still be running an unpatched point release five days after the fix shipped.

What to do right now

• Patch first. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36, or 8.2.35 (or your Linux distribution's equivalent backport), then restart PHP-FPM and your web server workers. The PHP advisories and Sophos's write-up both describe patching as the only complete mitigation — interim controls reduce risk but don't eliminate it.
• If you can't patch immediately, security advisories recommend taking internet-facing PHP applications offline or putting them behind network-layer authentication, disabling unneeded file uploads, and rejecting multipart/form-data requests at the web server or WAF layer where feasible.
• Apply the documented interim settings for CVE-2026-109619 specifically: set session.upload_progress.enabled=0, and on PHP 8.5, fatal_error_backtraces=0. These must go in php.ini or your FPM pool/server config — not ini_set() or .user.ini — and workers need a restart to pick up the change.
• Inventory every PHP install you run, including ones that never registered as a tracked application, and prioritize internet-facing servers and mod_php deployments first.
• Review logs retrospectively. Because PHP's advisory and Sophos's guidance both note that patching doesn't tell you whether you were already hit, check web server, WAF, and PHP error logs for worker crashes, malformed multipart uploads, unexpected child processes, and newly modified PHP files.
• If you're stuck on PHP 8.1 or earlier, treat this as a forcing function to move to a supported branch. The PHP project has published only minimal source backports for 7.4, 8.0, and 8.1, explicitly as a stopgap rather than a long-term fix.

What's next

Expect three things to keep moving. First, CISA's KEV catalog addition is plausible in the near term if the agency independently confirms exploitation — that would trigger mandatory remediation deadlines for U.S. federal civilian agencies and is worth watching directly on CISA's site rather than relying on secondhand summaries. Second, exploit reliability is likely to improve; Tanium's sourcing from VulnCheck notes that working exploits tend to mature quickly once a patch diff is public, so the current state of "lots of broken public PoCs" shouldn't be mistaken for a durable defense. Third, expect vendors to keep updating their advisories as incident response engagements turn up (or rule out) confirmed breaches tied specifically to php2shell rather than general attack attempts — that's the detail to watch for before treating any individual compromise claim as established fact.

For now, the operative fact hasn't changed since Sunday: patched versions have existed since October 21, and every day an internet-facing PHP server goes without them is a day it sits in a different, more urgent risk category than it did a week ago.

Written bySana Qureshi

Sana Qureshi runs the security and privacy desk. She reports on actively exploited vulnerabilities, vendor patches and data breaches, and covers the password managers, VPNs and authentication tools readers use to protect themselves. Her alerts cite vendor advisories, CISA and the CVE record directly.

More from Sana QureshiAll Security & Privacy coverage