PHP2Shell Explained: Affected Versions, Risks, and Fixes for the Critical PHP RCE Vulnerability

What Is PHP2Shell?

PHP2Shell is the name for two critical vulnerabilities in the PHP engine itself, CVE-2026-109618 and CVE-2026-109619, that can allow unauthenticated remote code execution on a PHP server. Both were disclosed and patched on October 21, 2026 [1]. The fixes cover PHP 8.2 through 8.5, which leaves PHP 8.1 end-of-life systems and everything older without an official patch.

PHP powers 70% of the world’s websites, according to Wiz [2]. The disclosure landed on what TechCrunch called “a very bad cybersecurity day” for the internet [3].

The official response was blunt. The NSA advised organizations running PHP to update immediately or take their systems offline until they could, and Reuters reported government websites around the world going offline [3].

PHP2Shell had company that day. Node.js patched four high-severity flaws, one of them a remote code execution bug, and attackers published malicious releases of the LiteLLM AI proxy carrying an information stealer aimed at cloud and AI service credentials [3].

TechCrunch noted the incidents were unrelated. Their back-to-back arrival is the signal I’d take from the day, because it shows how fast critical findings now land on security teams.

How Was PHP2Shell Discovered? Researchers Used Frontier AI

PHP2Shell was found by researchers using frontier AI models, and the timeline Wiz published shows the speed. The first flaw was found on August 19, and unauthenticated remote code execution against Drupal was confirmed the next day [2].

The issues went to the PHP security team on August 24, and patches and public disclosure followed on October 21. Attackers did not wait for that date. Amazon Threat Intelligence saw a first exploitation attempt on October 17, four days before disclosure [4].

These flaws had been in PHP for over a decade. Exploiting them required chaining multiple flaws and adapting to each target’s memory layout through repeated testing, work that was hard to do by hand and harder to scale.

Frontier AI removed that barrier for researchers and attackers alike. Wiz’s own measure is that a single researcher completed in a week what previously would have taken a world-class team months [2].

Wiz compares PHP2Shell to Heartbleed and Log4Shell and says its goal is to make this kind of work routine. I take that at face value. AI-driven discovery of critical flaws in core software is becoming a steady cadence, and every finding in that wave ships with a fix for supported software only.

Which PHP Versions Are Affected by PHP2Shell, and Which Are Patched

Supported PHP got its fix on disclosure day. Here is where each branch stands [1].

If your applications run on PHP 8.1 or older, there is no official release to install. PHP 8.1 end-of-life status means none is coming, and the same holds for PHP 7.4 end-of-life systems and everything older.

The population on those rows is large. Mallory counted about 884,000 internet-facing hosts reporting PHP 8.1 or older, roughly 59% of hosts reporting any version [5]. Those are version-banner counts and do not confirm vulnerable systems.

Teams on 8.2 are on the same clock. PHP 8.2 end of life arrives on December 31, 2026, when its security support ends, which puts every team that patched 8.2 this week about ten weeks from having no official fixes.

What Attackers Can Do With PHP2Shell: Remote Code Execution and Memory Disclosure

Both PHP2Shell CVEs are rated CVSS v4.0 9.2, the critical range, by the PHP security team [1]. Wiz says every version since PHP 5.4 is affected by at least one of them [2].

The flaw carries two impacts, and they deserve equal weight.

• Remote code execution: An unauthenticated attacker can execute code on the server. On Apache with mod_php, where PHP runs inside the web server process, the attack triggers before any application code runs, and full PHP remote code execution was demonstrated on default settings [1].
  
• Memory disclosure: An attacker can read the PHP process’s memory without taking over the server. That memory can hold passwords, authentication tokens, API keys, and certificates belonging to other requests or to the server itself.

PHP2Shell lives in the runtime, below your code. A well-written application on an affected version can be vulnerable, and so can a “Hello World” page.

Updating WordPress, Drupal, Laravel, or any other framework leaves the flaw in place. The fix is an updated PHP runtime and a restart of every PHP worker.

The exposure covers every PHP installation serving web requests [1]. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed. The SAPI, the interface between PHP and the web server, sets how high the risk is on a given host, with mod_php at the top.

How to Check If Your PHP Servers Are Vulnerable to PHP2Shell

Hand this list to your platform team today. Each check closes a gap that a version scan leaves open.

• Check the version serving web requests. Tracking PHP vulnerabilities by version only works if you know the version actually serving traffic. The CLI binary on a host can differ from the PHP build that Apache or PHP-FPM loads.
  
• Check how PHP is served, and start with mod_php. Apache with mod_php is the highest-risk configuration because the attack runs before your application code. Those hosts go first.
  
• Don’t trust version numbers blindly. Linux distributions often backport fixes into packages whose version numbers look old. Confirm patch status against the distribution’s own advisory.
  
• Find the PHP you don’t think of as PHP. Internal admin tools, vendor appliances, hosting control panels, container images, and CI/CD images all carry PHP runtimes that rarely appear in an application inventory.
  
• Confirm restarts and rebuilds. A running PHP-FPM master or mod_php inside Apache keeps the old code in memory until restarted, and a container keeps it until it is replaced with a rebuilt image.

Anything this check finds on PHP 7.4 EOL or older goes straight onto the unpatchable list.

For a structured way to run the same exercise across a whole portfolio, see our guide to mapping every unpatched CVE in a legacy system vulnerability assessment.

Why PHP 8.1 End of Life and Older Versions Will Stay Vulnerable After PHP2Shell

In my view, this exposure outlasts the news cycle. Three things keep a PHP 8.1 EOL runtime exposed long after October 21 leaves the headlines.

• Variants exist beyond the two CVEs. Wiz says there are other tracked, and likely untracked, variants in the PHP codebase [2]. Only the patched release fixes the root cause.
  
• Future fixes land on supported versions only. The same AI-driven discovery that found PHP2Shell will keep finding flaws in older code. Supported branches will get the fixes, and unsupported runtimes will get the findings with none of the fixes.
  
• Unpatchable runtimes become the target. My view is that once the patched majority closes the door, attackers concentrate on the systems the patches can’t reach.

That makes the exposure a standing condition. Flaws found in PHP 7.4 or 8.1 next year are likely to arrive with the same answer this one did.

Teams that filed end-of-life as a maintenance date now face it as a security date, and the unpatched findings on unsupported branches will keep accumulating. We have argued before that AI can now read legacy code and surface its vulnerabilities, which ends obscurity as a defense. October 21 showed it at internet scale.

Engine-level PHP bugs do get weaponized. CISA’s Known Exploited Vulnerabilities catalog already lists three flaws in PHP itself, and two are known to have been used in ransomware campaigns [6].

One is CVE-2019-11043, a PHP-FPM vulnerability that could lead to remote code execution on nginx. The other is CVE-2024-4577, a PHP-CGI argument injection flaw.

How PHP2Shell Can Leak Passwords, API Keys, and Other Credentials

PHP2Shell is also a PHP information disclosure vulnerability. It can expose passwords, authentication tokens, API keys, and certificates without the attacker ever taking over the server. The LiteLLM compromise on the same day went after the same prize: cloud and AI service credentials.

Those secrets rarely stay local. A typical PHP application server holds credentials for:

• Databases, including the customer and transaction data behind the application
• Cloud accounts and storage
• Payment systems
• Partner integrations and third-party APIs

An attacker who reads those credentials from memory can walk into systems that never ran PHP. One exposed PHP server becomes an estate-wide problem, and the investigation has to follow the credentials.

How to Tell If Your Servers Were Compromised Through PHP2Shell

Amazon followed its October 17 sighting with more attempts on October 21 from what appear to be multiple actors [4]. Amazon says it is unclear whether those attempts would have succeeded against real systems, and that PHP2Shell is now broadly exploited in the wild.

CISA had not observed exploitation at the time of its October 21 alert, and as of October 22, 2026, neither CVE was in its Known Exploited Vulnerabilities catalog [7]. No reliable source has publicly confirmed a successful breach. Recheck both before you brief your board.

I would start the investigation from October 17 and expect application logs to say little. These attacks execute below the application layer, so the evidence sits in server and runtime behavior [2]. Wiz points to three signals:

• Unusual multipart requests followed by memory-limit errors or repeated HTTP 500 responses
• Unexpectedly large or malformed PHPSESSID response cookies
• Unexplained PHP worker churn

Use those signals to guide the investigation, with patching already done. On each host, also look for web shells, new files in the web root, new cron jobs, and unexpected accounts.

Then rotate credentials on every exposed system, whatever the investigation finds. That is my recommendation, and it follows directly from the memory disclosure path. Patching closes the door, and it does nothing about what may already have walked out.

Running PHP You Can’t Patch? Map What Else in Your Estate Is Exposed

Dependency Map

Risk Heatmap

Modernization Plan (3-5 Days)

+more

Full name

Work email

Claim my $0 Assessment

Do WAF Rules and PHP Config Changes Stop PHP2Shell? Only Partially

Use every stopgap available this week. Then be precise about what each one covers, because none of them removes the flaw.

The WAF gap is the easiest one to miss. If an attacker can reach the origin server directly, by IP address or through a second ingress path, the WAF does nothing. Check that before you count the WAF as coverage.

What Unpatched PHP Means for Audits, Cyber Insurance, and Disclosure

A known critical flaw with no available fix changes the conversation outside engineering.

• Audit: An unpatchable critical CVE on a production system is a finding with no remediation date attached. See the 2026 enforcement landscape for legacy software compliance risk.
  
• Cyber insurance: It becomes a renewal question. See what underwriters now require from legacy systems before renewal.
  
• Disclosure: For public companies, a known unpatched exposure can become a disclosure question under the SEC cybersecurity disclosure rules for legacy systems. Healthcare teams should read it against the HIPAA Security Rule requirements for legacy systems.

PHP2Shell Action Plan for the Next 72 Hours, 30 Days, and PHP 8.2 End of Life

Here is the sequence I would run.

First 72 Hours

• Inventory every PHP runtime serving requests, including the hidden ones flagged above.
• Patch everything on a supported branch and restart every worker.
• Apply stopgaps to everything else.
• Isolate what can’t be protected.
• Check whether any origin is reachable around the WAF.

First 30 Days

• Investigate from October 17 on every exposed system.
• Rotate credentials on those systems.
• Decide, application by application, whether to upgrade the runtime or migrate off it.

Before PHP 8.2 End of Life on December 31, 2026

• Move every PHP 8.2 system onto a supported branch.
• Have a funded plan and timeline for everything on PHP 8.1 and older.

How to Permanently Fix PHP2Shell on Unsupported PHP Versions

I expect more days like October 21. A supported runtime is the only remediation that holds up across them, because supported branches receive the fixes for this flaw and for the ones that follow it.

For older applications, that is rarely a version bump. Each major PHP release removed language features that old code depends on, runtime upgrades drag framework upgrades with them, and thin test coverage means nobody can prove the upgraded application behaves the same.

That is technical debt in a legacy application turning into a project, and projects take longer than security deadlines allow. That is exactly why this one has to start now.

An incremental modernization approach lets the riskiest internet-facing applications move first. If you are already weighing a move off PHP, our decision framework for modernizing legacy PHP to Node.js, Python, and React covers the target options.

References

[1] PHP security advisory, October 21, 2026.

[2] Wiz Research, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”.

[3] TechCrunch, “The internet is having a very bad cybersecurity day,” October 21, 2026.

[4] Amazon Threat Intelligence, PHP2Shell exploitation prior to public disclosure.

[5] The Hacker News, PHP2Shell.

[6] Tenable, PHP2Shell FAQ.

[7] CISA, Critical Vulnerabilities in PHP Require Immediate Patching.