PHP2Shell (CVE-2026-109618 and CVE-2026-109619): Critical PHP RCE Vulnerability, Full Timeline, and Patch Guide

Some bugs hide in plain sight for decades. A flaw in PHP’s engine, first noticed in 2004 but never reported or assigned an ID, sat untouched until August 2026, when researchers turned frontier AI models loose on it and produced a working, unauthenticated remote code execution exploit in a week. The result was PHP2Shell (CVE-2026-109618 and CVE-2026-109619), a pair of critical flaws affecting 70% of the web, with one real fix: upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

Why PHP2Shell Matters

PHP is the engine that runs a large part of the web. When you visit a site, a server executes PHP code to assemble the page you see, and Wiz estimates that happens on roughly 70% of all websites, including WordPress, Drupal, Joomla and MediaWiki, the platform behind Wikipedia.  

PHP2Shell was dangerous because it broke that shared engine rather than any one application. A typical web flaw affects only the sites running a specific vulnerable plugin or app. This one affected the layer underneath all of them, which is why a fully patched, well-maintained site was just as exposed as an abandoned one. Wiz showed that even a trivial page with no application logic could be compromised. Wiz demonstrated that even a bare “Hello World” page could be exploited, because the flaw triggered before any of the site’s own code had a chance to run. A flawlessly built site was exposed exactly like a neglected one.

What Happened: A 22-Year-Old Flaw, Leaked a Day Early  

The story of PHP2Shell runs back more than two decades. In 2004, security researcher Stefan Esser found the first remote vulnerability in how PHP handled its memory limit, a bug serious enough that he never released a public exploit. The underlying weakness never fully went away.

In 2020, a developer reported PHP bug #78876, noting that certain long variables could push PHP into an out-of-memory (OOM) condition and leave temporary files behind. It drew little attention at the time. A 2024 PHP audit by OSTIF and Quarkslab rediscovered a related OOM issue but could not prove it was exploitable, so it was left unfixed.

An old bug, made exploitable by AI

The picture changed in 2026. Under OpenAI’s “Patch the Planet” initiative, the security firm Calif picked PHP as a high-impact target, with the PHP Foundation brought in through maintainer Volker Dusch. On August 1, Calif researcher Ryan Austin, working with an AI model and his own knowledge of PHP’s history, turned the long-dismissed OOM weakness into a working remote code execution (RCE) chain, first against WordPress and then against mod_php and PHP-FPM.

Calif reported the first bug to PHP on August 11 and a second on August 21. Wiz Research independently found further attack vectors using Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol, confirmed unauthenticated RCE against Drupal and WordPress, and reported to PHP on August 24. Wiz stated that a single researcher, aided by frontier models, completed in a week what a world-class team would once have needed months to do. Calif made the same point from the other side: the AI did not find the bug on its own prompts, but it collapsed the time between a known weakness and a reliable exploit.

Disclosure under pressure

The coordinated release was set for October 21 at 14:00 UTC, but the embargo broke the day before. On October 20, a Hacker News user named petecooper posted the two CVE identifiers, wrongly claiming a October 22 disclosure and a CVSS score of 10.0. The post was later deleted, but it had already spread across Hacker News, Reddit and Mastodon. watchTowr confirmed the flaws were real and said it had reproduced CVE-2026-109618, a demonstration video attributed to Calif circulated, and CERT-EU advised isolating internet-facing PHP applications.

PHP responded the same evening with an advance notice of an emergency release for two critical flaws rated CVSS v4.0 9.2. On October 21, Chainguard published patched container images ahead of the agreed time, and PHP’s GitHub security advisories went live at 13:34 UTC, minutes before the scheduled release. The response reached well beyond IT teams: the UK NCSC urged organizations to take unpatchable systems offline, and Reuters reported European government websites going dark to apply fixes.

What are CVE-2026-109618 and CVE-2026-109619?

Both CVEs were memory-safety flaws with one shared root cause: PHP did not clean up correctly when a request died abruptly, most often from running out of memory. The leftover, half-valid internal state could then be reused, by the same request or by the next request handled by the same worker, and turned into code execution.

Both the vulnerabilities carried the vector 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. In plain terms: network-reachable, no login and no user interaction, full confidentiality, integrity and availability impact, with high attack complexity and specific attack requirements reflecting the precise timing and memory-layout conditions the chain needed.

CVE-2026-109618: Out-of-Memory corruption

The flaw lies in how PHP handles a failed memory allocation. When a request crossed memory_limit, PHP used longjmp() to abandon the current code path; if this happened while request data was only partly initialized, request cleanup later treated that invalid data as valid and corrupted process memory. According to the advisory, an attacker can force the OOM precisely, because crafted multipart requests (used for forms and uploads) can exhaust memory while still appearing to satisfy PHP’s size limits. On Apache with mod_php, cleanup runs even after a failed request startup, so an unauthenticated request triggers the bug before application code runs; RCE was demonstrated over HTTP with default settings. PHP-FPM, which kills a worker on startup failure, is not exploitable through that exact path, but RCE was separately confirmed on FPM via application-level code paths.

CVE-2026-109619: Stale Global State

Because a PHP worker reuses one process across many requests, it carries global state (error, session, object and extension state) between them. A fatal error, including memory exhaustion or an execution timeout, could interrupt the cleanup of that state, and some non-fatal shutdown diagnostics could repopulate it after cleanup, leaving internal pointers aimed at memory freed by an earlier request. A later request on the same worker could then use that freed memory before initialization reset it, producing a use-after-free that leads to code execution. The advisory confirms two consumers of the stale state: on PHP 8.5, the fatal-error backtrace feature (fatal_error_backtraces, enabled by default), and the session lifecycle on both mod_php and FPM. The session path runs through session upload progress, an upload-tracking feature enabled by default that touches session state early in a request and does not require the application to call session_start().

The four bugs behind the two CVEs

Wiz reported four separate exploitable bugs, yet they map to only two CVEs. That is because all four share one root pattern: PHP hits a fatal error (usually running out of memory) at a delicate moment, leaves some internal state behind that points at memory it has already freed, and a later request on the same worker then trusts that stale state. The two CVEs describe the two ends of that pattern, memory corruption from out-of-memory handling (CVE-2026-109618) and reuse of stale global state (CVE-2026-109619), so each specific bug folds under one of them. Wiz noted that other tracked and untracked variants of the same pattern exist in PHP, which is why the fix had to repair the pattern itself rather than patch four bugs one by one.

Here is what each of the four does.  

Bug 1: Upload-progress unserializer use-after-free

PHP’s session feature can decode session data very early in a request, while handling upload progress, and it stores its working notes for that decoding in a global called BG(unserialize). If an out-of-memory error interrupts this step, PHP throws away the request’s memory but leaves those notes still “published” and pointing at the freed memory. On the next request to the same worker, an attacker can fill that freed memory with their own data, which PHP then trusts as live decoding notes. That gives a strong memory-corruption foothold; combined with the memory-leak bug below (to remove the guesswork about memory addresses), Wiz turned it into unauthenticated remote code execution on WordPress, Drupal and Joomla.

Bug 2: Remote process-memory disclosure (data leak, no code execution needed)

Early in a request, before PHP has fully set itself up, upload-progress handling can create session state and record a session ID in a global called PS(id). If an out-of-memory error aborts the request first, PHP frees the memory but may leave PS(id) pointing at the freed spot. A later upload request on the same worker reaches the cleanup code before PHP resets that pointer, trusts the stale value, and copies whatever is now sitting in that freed memory straight into the PHPSESSID response cookie it sends back. The attacker reads that cookie and gets a chunk of the worker’s live memory, which can contain passwords, session tokens, API keys and certificates belonging to other users’ requests. It works even if the application never uses sessions, and it needs no code execution at all, a Heartbleed-style leak.

Bug 3: Fatal-error backtrace use-after-free

PHP keeps a record of the most recent fatal error’s backtrace in a global called EG(last_fatal_error_backtrace). An out-of-memory error can destroy the request’s memory without clearing that global, so the worker survives with a note still pointing at memory from the previous request. If the next request triggers any early diagnostic, PHP follows that dangling pointer into memory the attacker has since refilled. Wiz developed this into controlled memory corruption and demonstrated unauthenticated remote code execution against Drupal.

Bug 4: OPcache type confusion

OPcache speeds PHP up by storing compiled code in memory shared across all workers. To track it, PHP advances its own local marker first and only publishes the matching shared marker once the work is finished. If an allocation fails in the gap between those two steps, the shared record is left thinking certain memory slots are still free when they are not. When another worker later reuses one of those slots for a different kind of object, PHP reads it as the wrong type, a “type confusion” that corrupts the shared OPcache memory every worker relies on. Wiz used this to build an unauthenticated RCE chain against WordPress.

The WordPress, Drupal and Joomla results are just demonstrations. All four bugs live in the PHP engine itself, so any application on a vulnerable PHP version is exposed, and PHP’s own advisories remain the authoritative reference for which bug sits under which CVE.

Which PHP Versions Are Affected?

Every PHP release from 5.4 through 8.5 was affected by at least one PHP2Shell bug, and only four releases fixed it on October 21, 2026: 8.5.12, 8.4.27, 8.3.36 and 8.2.35. PHP framed the risk around installations that serve web requests, across every common server setup.

The end-of-life problem

PHP 8.1 and older no longer received official updates. Because of the severity, the PHP security team released minimal source backports for PHP 7.4, 8.0 and 8.1, intended for teams that build from source or have no long-term support (LTS) vendor. Linux distributions and LTS vendors received the patches before public release and shipped their own backported packages, with Ubuntu publishing updated packages for 24.04 on release day.

One packaging detail caught many administrators. Users of the volunteer-run rpms.remirepo.net repository were advised to switch to distribution packages or build from source, because that repository had no updates available on October 21.

The exposure extended to appliances that embed PHP. Palo Alto Networks confirmed that all versions of PAN-OS and Panorama were affected, while Fortinet and Cisco opened investigations into 12 and 31 products respectively.

How the PHP2Shell Exploit Chain Works

PHP2Shell was not a one-shot bug but a multi-request chain: crash a worker at the right moment, leak memory to defeat ASLR, then reuse the dangling state to run a command. The attacker toolkit SOCRadar recovered from an exposed server (aslr_exploit.py, labeled a “one-click” exploit for PHP 8.4.26 under Apache mod_php) followed exactly that shape, entirely over ordinary HTTP. The stages below are conceptual and intentionally omit weaponizable detail.

1. Fingerprint the target: The attacker identified the PHP version, the server setup (SAPI) and session settings, because each exploit depended on a specific memory layout. The same toolkit included php2shell_fp.py and deep_probe.py, which screened sites for exactly these preconditions.
2. Force an abort mid-initialization: A crafted multipart (RFC 1867) upload drove the worker into an out-of-memory error during request startup, before normal module initialization finished. Session upload progress, enabled by default, put session state into play in this early window.
3. Leave dangling state behind: The OOM destroyed the request heap, but global pointers such as PS(id), BG(unserialize) or EG(last_fatal_error_backtrace) survived and still pointed at freed memory.
4. Leak memory to defeat ASLR: A follow-up request to the same worker reached cleanup code that trusted the stale PS(id), which URL-encoded freed heap contents into the PHPSESSID response cookie. Those leaked addresses removed the guesswork that address space layout randomization (ASLR) normally forces on an attacker.
5. Reclaim and corrupt: The attacker filled the freed memory with controlled data, so PHP consumed it as live internal structures. This yielded a memory-corruption primitive, used through session upload progress handling to run a shell command.
6. Execute as the web worker: Code ran with the web server account’s privileges, enough to read application secrets, database credentials and API keys, or to pivot inward.

Why the chain was hard, and why that stopped mattering

The chain required landing consecutive requests on the same worker and matching a version-specific heap layout, which is why early mass attempts failed. That barrier eroded quickly. On October 23, VulnCheck disclosed a technique that chained both CVEs, using the memory leak to bypass ASLR and reach RCE on x86-64 systems running PHP’s recommended production error-display setting.

Apache with mod_php carried the highest risk because PHP’s demonstrated exploit fired before any application code ran. No application bug, login or specific CMS was needed, which made a fully patched WordPress site on a vulnerable PHP runtime just as exposed as a neglected one.

PHP2Shell Timeline

The gap between the first known exploit attempt and the patch was four days, and the gap between the patch and mass scanning was under an hour. (All times are UTC)

PHP2Shell Exploitation and Threat Activity

Exploitation attempts began before disclosure and reached millions within a day, yet no successful real-world compromise had been publicly confirmed as of October 23, 2026. That gap reflected the exploit chain’s difficulty rather than any lack of attacker interest, and the activity quickly split between opportunistic botnets grabbing whatever they could and at least one organized actor preparing a focused campaign.

Attacks before the patch

Amazon Threat Intelligence logged a PHP2Shell attempt against its MadPot honeypots on October 17, four days before disclosure, from a commercial anonymization network. How that actor obtained exploit details during the embargo remained unknown. Between 02:00 and 08:00 UTC on October 21, Amazon saw further attempts from varied anonymized infrastructure with differing payloads, consistent with multiple actors operating at once.

Volume after the patch

Cloudflare recorded tens of thousands of attempts within 45 minutes of the announcement, hundreds of thousands within two hours, and millions by early October 22. Previdian logged its first CVE-2026-109618 exploit event at 13:05 UTC on October 21, and watchTowr observed in-the-wild activity through its Attacker Eye honeypot network the same day. Cisco Talos characterized most of it as scanning plus uncoordinated payload delivery using public proof-of-concept (PoC) code.

Notable threats observed

Potassium botnet (Mirai-derived): According to Sophos, three source IPs attempted to install an expanded version of Potassium, a Mirai-derived botnet first flagged in March 2026. Arctic Wolf reported 24 flood commands spanning ICMP, TCP, UDP and OpenVPN, plus a dormant Ethereum Name Service (ENS) command-and-control capability. The flood targets sat within a single Ukrainian network, pointing to DDoS as the immediate goal, and the loader was fetched from 92.118.112[.]100.

Financially motivated crypto tooling: SOCRadar recovered PHP2Shell exploit and screening scripts from an exposed attacker server, tied to an actor focused on cryptocurrency and Web3 targets. Hunt.io linked the same server to 123 targeted hosts, roughly 57 of them running PHP, with none confirmed compromised. The version-fingerprinting and screening scripts indicated a selective approach rather than spray-and-pray.

Opportunistic web shell and secret theft: VulnCheck observed a China-based IP attempting to plant a web shell through a server-side session file, which failed. Separately, Wordfence, Dataminr and Beelzebub recorded attempts to confirm command execution, harvest secrets from environment variables, install persistence and pull second-stage payloads, the broad commodity exploitation expected once a PoC is public.

Suspected DPRK campaign (CYFIRMA): In an advisory published October 23 and updated October 24, CYFIRMA reported a Korean-speaking operator, assessed with moderate confidence to be linked to the Lazarus Group ecosystem, staging a deliberate PHP2Shell campaign. By October 24 the operators had filtered a target set to 216 unpatched hosts, prioritizing government and financial institutions across 12 named countries, and were scanning from 21 compromised nodes using low-and-slow tradecraft. CYFIRMA found no confirmed compromise by this actor and noted the Lazarus link rested on language and tradecraft rather than infrastructure overlap.

Confirmed compromise status

Sophos initially reported one successful exploitation on October 22, then revised that to scanning and a small number of failed attempts. Previdian likewise reported no successful RCE and no dropped PHP files. Honeypot data understates real exposure, though, and VulnCheck’s ASLR bypass on October 23 removed the main reliability barrier that had kept early attempts from landing.

Major Vendor Developments

PHP2Shell triggered one of the broadest coordinated industry responses since Log4Shell, spanning CDNs, cloud providers, Linux distributions and governments. A third PHP flaw, disclosed two days after the patch, kept the story open.

Edge and cloud mitigations

Cloudflare deployed WAF rules for the known exploit vectors before the patch, available to all customers including the free plan, and later confirmed it was seeing early attacks. Wiz credited Google Cloud, AWS, Microsoft, Automattic, Fastly, Akamai, Imperva and Vercel with preparing guidance and out-of-the-box mitigations ahead of disclosure.

Packages and tooling

Ubuntu shipped fixed packages under USN-8948-1 for 22.04, 24.04, 26.04 and 26.10, and Debian and Red Hat released updates, while hosting panels cPanel and Plesk issued their own responses. Searchlight Cyber released php2shell-scanner, an open-source tool that tested hosts for exposure.

A third flaw: CVE-2026-115560

On October 23, PHP published an informational advisory for CVE-2026-115560, a session upload progress issue offering another route to code execution. It required an unusual combination of configuration and application code, so PHP scheduled the fix for its regular release cycle rather than an emergency patch. The October 21 releases did not fix it, but the CVE-2026-109619 mitigations, including disabling session upload progress, also covered it. No exploitation of CVE-2026-115560 had been reported.

Government response

CISA advised organizations unable to update, or still running PHP 8.1 or older, to take PHP-based systems offline until patched. The UK NCSC issued about 50,000 warnings, and the UK government confirmed 32 digital services were unavailable and four partially unavailable during precautionary shutdowns. Government, school and hospital websites across Asia, Europe and North America went offline as a precaution.

How to Patch and Mitigate PHP2Shell

Upgrading PHP and restarting every worker was the only complete fix; PHP core developer Gina Peter Banyard warned that no mitigation would fully block attacks. Configuration changes only bought time, and hunting needed to start from October 17, not from the patch date.

Step 1: Patch

1. Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, preferably through distribution or LTS vendor packages.
2. Restart every PHP worker (PHP-FPM pools, Apache, FrankenPHP, LiteSpeed). PHP2Shell abused state held in long-lived worker memory, so a patched binary does not protect a worker that never restarted.
3. Verify the running version per SAPI. The CLI binary and the web-facing FPM or Apache module can differ, so confirm the version the web server actually loads.
4. Handle end-of-life branches. On PHP 8.1 or older, migrate to a supported branch, use a vendor backport, or apply PHP’s minimal source backports for 7.4, 8.0 and 8.1.
5. Inventory hidden PHP. Check containers, base images, appliances and vendor products that bundle PHP, since many will only be fixed by their vendor.

Step 2: Detect and hunt

• Wiz noted that the bugs executed below the application layer, so application logs often held little context. Hunt across web, PHP and endpoint telemetry from October 17, 2026 onward for these signals:
• Unusual multipart POST requests followed by memory_limit errors or bursts of HTTP 500 responses
• Unexpectedly large or malformed PHPSESSID cookies in server responses, a sign of the memory disclosure bug
• Unexplained PHP worker crashes or churn, and OOM errors logged as “Unknown on line 0” (not PHP2Shell-specific, but worth triage)
• PHP or web server processes spawning shells or downloaders such as sh, bash, curl or wget
• New PHP files in web roots, session files containing code, and outbound connections to the indicators listed above

Because the disclosure bug could leak passwords, tokens and API keys from worker memory, any exposed server that ran a vulnerable version justified rotating the secrets it handled.

Detecting PHP2Shell Across Your Infrastructure

Finding every vulnerable PHP instance is harder than it sounds, because PHP hides in many places: distribution packages, hand-built installs, container images, and appliances that bundle it. Network scanning sees only what is exposed and often guesses the version from a banner, while log parsing misses anything that has not been attacked yet. A more reliable approach is to check the actual installed version on each host, locally and declaratively, using OVAL.

A unified, cross-platform approach with OVAL

OVAL (Open Vulnerability and Assessment Language) is an open standard for describing how to test a system for a given vulnerability or configuration state. Instead of running a different tool for each operating system, you define the check once and run it consistently across the whole estate. For PHP2Shell, that means one definition that asks a single question everywhere: is the installed PHP older than the patched release for its branch? This removes the need for separate OS-specific scripts and gives security and IT teams a single, auditable source of truth for coverage.

Declarative system querying

Rather than probing PHP over the network, OVAL queries the operating system’s own record of what is installed. The exact object it inspects depends on the platform:

• Linux: the package manager database, through the rpminfo test on RPM-based systems (RHEL, Rocky, Alma, SUSE) or the dpkginfo test on Debian and Ubuntu, reading the installed php, php-cli, php-fpm or equivalent package versions.

• Windows: registry keys and file version metadata for PHP binaries, useful where PHP ships inside a stack such as a bundled web platform.

• Containers: the image’s text manifests and package metadata, so images are assessed at rest in the registry before they are ever deployed.

Because the check reads a declared state rather than executing the runtime, the result is deterministic: the host either reports a vulnerable version or it does not.

Passive and safe by design

This detection method is read-only and local. It does not send crafted requests, so there is no risk of triggering the very out-of-memory crash that PHP2Shell abuses, and no chance of destabilizing a production worker. It does not depend on log parsing, which only reveals hosts that have already been probed. Production applications see zero added load and zero disruption, which makes the check safe to run on live, internet-facing systems during an active exploitation window.

Clear patch benchmarks

The detection flags any PHP instance running below its branch’s fixed version:

How Loginsoft Can Help

PHP2Shell showed how little time defenders get: an attack before the patch, millions of attempts within a day, and an exploit window measured in hours. Closing that gap takes more than a patch advisory, it takes knowing which of your assets are exposed, which threats are real, and how to detect them. That is the work Loginsoft has done for cybersecurity product companies and enterprises for over two decades.

For a scenario like PHP2Shell, that translates directly into:

• Vulnerability intelligence that cuts through the noise: Through LOVI (Loginsoft Vulnerability Intelligence), teams get pre-NVD insights, exploit intelligence, EPSS and CISA KEV mapping, ATT&CK context and threat actor attribution, so a critical, actively exploited flaw rises to the top instead of sitting in a backlog. Loginsoft has researched over 30,000 CVEs across open-source packages to support exactly this kind of prioritization.
• Detection content for finding exposure at scale: Loginsoft generates security content in SCAP formats such as OVAL and XCCDF, the standards-based way to query every host for a vulnerable PHP build without touching production traffic, turning “are we exposed?” into a single consistent sweep across the estate.
• Threat detection rules: Loginsoft develops rules in formats like Sigma, OSquery and Splunk, the kind needed to hunt the PHP2Shell signals that matter: worker crashes, anomalous multipart requests and PHP processes spawning shells.
• Threat intelligence integrations: With over 300 security integrations built for TIP, SOAR, SIEM and ticketing platforms, Loginsoft helps teams operationalize indicators and advisories inside the tools they already run, so intelligence drives action rather than sitting in a PDF.

Loginsoft partners with leading vendors including Palo Alto Networks, Splunk, Elastic and IBM Security, and its research also underpins the Vulnerability Research Labs AI Exploitability Index, work that speaks directly to the AI-accelerated exploitation PHP2Shell represents. The goal is simple: help defenders stay ahead of the next flaw, not just react to the last one.

The End of the “Too Hard to Exploit” Era

PHP2Shell marked the point where AI turned a known but “unexploitable” flaw into a working, internet-scale attack. A weakness first spotted in 2004, never reported, and dismissed again in a 2024 audit became pre-authentication RCE within a week of frontier models being applied to it, and attackers were probing it before the patch even existed.

The industry has been here before. Heartbleed in 2014 and Log4Shell in 2021 each forced the whole internet to patch at once, because the broken component sat in software almost everyone ran. PHP2Shell belongs in that lineage, but breaks the pattern in one way: those flaws were found by humans reading code, while this one was a two-decade-old dead end until AI collapsed it into a weapon in days. The risk still lived in the long tail, with Censys assessing more than 34.4 million PHP services as vulnerable on October 23.

That is the lesson that outlasts this one CVE: a hard-to-exploit bug is no longer a safe bug. When AI can turn a forgotten weakness into reliable RCE in a week, the gap between disclosure and mass attack closes to hours, and defense has to match that pace. Organizations that upgraded, restarted every worker, rotated exposed secrets and hunted back to October 17 closed the window; those that leaned on WAF rules alone only narrowed it. LOVI continues to track PHP2Shell exploitation, KEV status and vendor patch releases as the situation develops.

PHP2Shell FAQ

Q1. Is PHP2Shell being exploited in the wild?

Exploitation attempts were widespread, starting October 17, 2026 and reaching millions per day after the patch. As of October 23, no successful real-world compromise had been publicly confirmed.

Q2. Is my website affected by PHP2Shell?

Any server running PHP 5.4 through 8.5 that serves web requests was affected unless it ran 8.5.12, 8.4.27, 8.3.36, 8.2.35 or a vendor-backported build. The application on top did not matter; a fully patched WordPress, Drupal or Joomla site was still exposed through the runtime.

Q3. Is there a public PHP2Shell exploit?

Yes. Public proof-of-concept code circulated from October 21, and VulnCheck demonstrated an ASLR bypass on October 23 that made exploitation viable against production-configured x86-64 systems.

Q4. Does a WAF protect against PHP2Shell?

Partially. WAF rules from Cloudflare and other providers blocked known request patterns, but PHP stated that only the patch fully fixed the flaws.

Q5. Is PHP2Shell in the CISA KEV catalog?

Not as of October 23, 2026. CISA still advised taking unpatchable and end-of-life PHP systems offline until fixed.

Q6. What is CVE-2026-115560?

A separate session upload progress flaw PHP disclosed on October 23. It required an unusual setup, had no reported exploitation, and was mitigated by disabling session.upload_progress.enabled.