PHP2ShellCVE-2026-109618CVE-2026-109619Attack Surface ManagementVulnerability Management
8 views

PHP2Shell (CVE-2026-109618, CVE-2026-109619): Find Every Internet-Facing PHP Host Before Attackers Do

By Heeraj NairPublished
PHP2Shell header
On 21 October 2026 the PHP project shipped emergency releases for two critical flaws in the PHP runtime itself. Both allow unauthenticated remote code execution, and both are rated CVSS v4.0 9.2. The details got out before the fix did. Cloudflare says it was already watching attackers adjust their payloads against its firewall rules hours before the patch landed.
Patching the PHP servers you know about is the easy part. The harder job is finding the ones you don't.

What is PHP2Shell?

PHP2Shell covers two separate bugs that share a root cause. PHP can leave memory in a bad state when a request ends abnormally, and an attacker can turn that into code execution as the web server's worker account.
PHP2Shell at a glance: CVE-2026-109618, RCE via out-of-memory corruption, and CVE-2026-109619, RCE via stale global state, both CVSS v4.0 9.2 with no authentication required.
CVE-2026-109618: RCE via out-of-memory corruption (GHSA-w8hw-w9fx-j79w). PHP has used longjmp() to abort a request when it runs out of memory. If that happens while request data is only partly initialised, the shutdown routine can later treat the invalid data as valid. Crafted multipart requests can push PHP into that out-of-memory state while staying inside its apparent limits. The advisory says full RCE was validated over HTTP against mod_php with default input and memory limits. Source analysis suggests FPM, FrankenPHP and LiteSpeed are also susceptible, although no complete FPM exploit had been demonstrated for this bug.
CVE-2026-109619: RCE via stale global state (GHSA-6wmf-4rv5-p3rp). A persistent PHP worker can keep global state that points into memory owned by a request that has already finished. The next request on the same worker can then use that freed memory before normal initialisation. The result is a use-after-free. Two paths are confirmed:
  • the PHP 8.5 fatal_error_backtraces path, which is the basis of the confirmed mod_php exploit;
  • session upload progress, which is enabled by default and was validated against both mod_php and FPM.
Both advisories list CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N. Attack complexity is rated high, but no privileges or user interaction are needed.

Which PHP versions are affected, and which are fixed?

Every release below the fixed version in each supported branch is affected. Updating the package is not enough on its own: the new build only takes effect once PHP-FPM or the web server restarts.
Affected versus fixed PHP versions: 8.5.12, 8.4.27, 8.3.36 and 8.2.35 are fixed; 8.1, 8.0 and 7.4 get source patches only; 7.3 and older get no fix.
BranchUpgrade toWhat php.net says
8.58.5.12Fixed. If you must wait, set fatal_error_backtraces=0
8.48.4.27Fixed
8.38.3.36Fixed
8.28.2.35Fixed. The branch reaches end of life on 31 Dec 2026
8.1, 8.0, 7.4No official releaseMinimal source backports published. Distro or LTS vendor packages may exist
7.3 and older—No fix from the PHP project. Upgrade or isolate
php.net does not give a lower bound for affected versions. CERT-EU says the flaws "could affect all PHP versions from PHP 5 onwards", and Cloudflare's write-up says they affect web servers running PHP 5.4 or later. Linux distributions and LTS vendors received the patches in advance, so check your vendor's packages too.

Who is actually exposed?

Per the php.net security advisory, exposure covers "all PHP installations serving web requests". That explicitly includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. Risk is highest where:
  • mod_php is in use. The out-of-memory exploit fires during request startup, before your application, login page or CMS maintenance mode ever runs.
  • Per-request INI overrides exist. .htaccess php_value lines, or PHP_VALUE parameters sent by nginx, can produce the early diagnostics that CVE-2026-109619 needs.
  • The runtime is end of life. These hosts have no official patch.
  • PHP is bundled in something you don't patch yourself. That includes appliances, hosting control panels and container images. The Netherlands' NCSC tells teams to check these separately, because "updating host PHP does not necessarily update bundled PHP".

Why is PHP2Shell an external attack surface problem?

Most organisations can patch their main web estate within a day. PHP2Shell is dangerous because PHP runs in places nobody is watching:
  • Forgotten marketing and campaign sites built by agencies that have long since moved on.
  • Staging, UAT and "temporary" hosts that got public DNS records and kept them. (We covered how these drift in exposed Swagger files, APIs and staging sites.)
  • Acquired brands and domains still running on the previous owner's hosting.
  • Vendor and partner portals that carry your brand but run on someone else's patch schedule.
Every one of these is reachable over HTTP. If it isn't in your inventory, it won't be in your patch run. The UK NCSC's first recommendation is to "identify systems running any version of PHP across your infrastructure, prioritising internet-facing systems". You can only do that from the outside in. See how to find exposed subdomains for the discovery basics.

Is PHP2Shell being exploited?

The evidence was still incomplete when this post was written, so here is what each source actually says:
  • Cloudflare saw attack traffic before the patch. Its write-up says protections went live for free and paid WAF customers at 03:02 UTC on 21 October. Because the vulnerability leaked early, Cloudflare "observed attack traffic targeting our customers" and saw attackers mutating payloads to get past the rules. CTO Dane Knecht (@dok2001) posted at 07:43 UTC that Cloudflare was "seeing early attacks emerging", and stressed the rules are a stopgap.
  • PHP confirms a working exploit path against mod_php in its own advisory.
  • Public "PoCs" deserve caution. Independent researcher @Stekkz said he audited 29 public repositories and found none that reproduced the alleged upload-progress use-after-free on stock PHP. Treat unvetted exploit code from new GitHub repos as a risk in its own right.
  • Not yet in CISA KEV. Neither CVE appeared in the KEV catalogue (version 2026.10.20) when checked. NVD had received CVE-2026-109618 but not yet analysed it.

PHP2Shell timeline

PHP2Shell disclosure timeline in UTC, from PHP's advance notice on 20 October to the fixed releases and NVD publication on 21 October.
Date (UTC)EventSource
20 Oct 2026PHP pre-announces two critical vulnerabilities (CVSS v4.0 9.2) and schedules a release for 21 Oct, 14:00php.net
20 Oct 2026CERT-EU publishes Security Advisory 2026-018CERT-EU
21 Oct, 03:02Cloudflare WAF protections enabled by default for free and paid plansCloudflare blog
21 Oct, 07:43Cloudflare CTO says early attacks are emerging@dok2001 on X
21 Oct, 10:07UK NCSC urges organisations to prepare to update or take systems offlineNCSC
21 Oct, ~13:41PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 live; GitHub advisories publishedphp.net, @dok2001
21 Oct, 14:17NVD publishes CVE-2026-109618 (status: Received)NVD

The PHP2Shell response checklist

PHP2Shell response checklist: inventory, fingerprint, patch and restart, decide on end-of-life hosts, harden while waiting, treat the WAF as a speed bump, and hunt for compromise.
  1. Inventory internet-facing PHP. Cover every domain, subdomain and IP you own, including cloud origins and acquired estates. Don't stop at the CMDB, because the assets missing from it are the ones most likely to be unpatched.
  2. Fingerprint version and SAPI. Use headers, error pages and application fingerprints, then confirm on the host with php -v and the active SAPI. Prioritise mod_php and anything on 8.1 or older, and treat "version unknown" as exposed.
  3. Patch and restart. Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your distro's patched package. Then restart every PHP worker.
  4. Decide on end-of-life hosts. For 7.4, 8.0 and 8.1, apply PHP's minimal source backports or an LTS vendor's package. For anything older, upgrade, isolate or switch it off. CERT-EU and the UK NCSC both advise isolating or taking offline what you can't fix.
  5. Harden only while you wait. php.net lists these measures as reducing specific attack paths but not making an installation safe:
  6. Treat the WAF as a speed bump. Managed rules only see traffic that passes through them. If attackers can reach your origin directly, the CDN is bypassed, so restrict origins to your proxy's IP ranges.
  7. Hunt for compromise. Look for PHP workers spawning shells, curl or wget, new files in web roots, new cron jobs or accounts, and repeated fatal, out-of-memory or timeout errors. The PHP advisory warns that a clean log is not proof of safety.

What most teams get wrong

  • Patching the application instead of PHP. A CMS update leaves the vulnerable runtime in place.
  • Updating without restarting. Old workers keep running the old build.
  • Trusting the asset register. The staging host from three years ago isn't in it.
  • Treating session.upload_progress as the fix. It blocks one confirmed path for one CVE and does nothing for CVE-2026-109618.
  • Forgetting bundled PHP. Appliances and container images ship their own runtimes.

Key takeaways

  • CVE-2026-109618 and CVE-2026-109619 are critical, unauthenticated RCEs in the PHP runtime, both rated CVSS v4.0 9.2.
  • Fixed releases are 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Branch 8.1 and older has no official release.
  • mod_php carries the highest risk, but FPM, php-cgi, FrankenPHP and LiteSpeed are all in scope.
  • Attack traffic was seen before the patch, and WAF rules are a stopgap, not a fix.
  • The deciding factor is coverage: finding every internet-facing PHP host, not just the ones you already manage.

Is your external PHP exposure ready?

  • ☐ Can you list every internet-facing host that serves PHP, with an owner for each?
  • ☐ Do you know which of them run mod_php, and which run 8.1 or older?
  • ☐ Have you confirmed, from outside, that patched hosts now report a fixed build?
  • ☐ Are vendor-hosted portals and appliances that carry your brand on your patch tracker?
  • ☐ Can your origin servers be reached directly, bypassing your WAF or CDN?

What ScruteX finds here

ScruteX looks at your organisation from the outside, the way an attacker scanning for PHP2Shell would. It continuously discovers your internet-facing assets and checks them for exposed services and outdated technologies. That includes the long tail of staging hosts, legacy sites and acquired domains that rarely make the patch list. Active vulnerability assessment helps you confirm which hosts need attention first, and threat intelligence keeps you up to date as exploitation reports and vendor guidance change.

See your exposure the way an attacker does

Start with a free exposure scan. It's agentless: you provide a domain and a set of keywords, and no credit card is needed. ScruteX sees only what is visible from outside your network. It does not replace patching, host-level forensics or log review inside your environment. Those stay with your internal teams.

FAQ

Q: What is PHP2Shell?

A: PHP2Shell is the informal name for CVE-2026-109618 and CVE-2026-109619, two critical flaws in the PHP runtime that can allow unauthenticated remote code execution. The PHP security team rates both CVSS v4.0 9.2.

Q: Which PHP versions fix PHP2Shell?

A: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP 8.1 and older receive no official release, although PHP published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and LTS vendors provide backported packages.

Q: Does updating WordPress or my CMS fix PHP2Shell?

A: No. The vulnerabilities are in PHP itself. You need to update the PHP runtime and restart the PHP service.

Q: Is disabling session upload progress enough?

A: No. It blocks the confirmed session-based paths for CVE-2026-109619 but not other variants, and it does nothing for CVE-2026-109618. PHP says updating is the only complete fix.

Q: Is PHP2Shell being exploited in the wild?

A: Cloudflare reported attack traffic against its customers before the patch was released. Neither CVE was listed in CISA's Known Exploited Vulnerabilities catalogue at the time of writing.

Sources

Back to all posts