PHP2Shell (2026)

What PHP2Shell is

PHP2Shell is the name used by the security firm Wiz, one of the groups that found them, for two critical vulnerabilities in PHP, the most widely used server-side programming language on the web. They are tracked as CVE-2026-109618 and CVE-2026-109619, and both were fixed and made public on October 21, 2026.¹²

PHP’s own advisories do not use the name. They call the flaws “RCE via OOM corruption” and “RCE via stale global state.”² The disclosure website php2shell.com carries a Wiz copyright notice.³

RCE stands for remote code execution: an attacker on the internet can make the server run commands of their choosing. Both PHP2Shell flaws can allow this without the attacker logging in, which PHP’s advisory calls unauthenticated remote code execution.² The attacker’s code then runs with the permissions of PHP’s web worker process.³

Both flaws are rated 9.2 out of 10 on version 4.0 of the Common Vulnerability Scoring System (CVSS), the standard scale for how serious a security flaw is.⁴ The scoring notes that an attack is complex and depends on certain conditions being present, but needs no account and no action by a user, and can fully compromise the server’s data and availability.⁵⁶

Because PHP runs 69.3% of websites whose server-side language is known, as of October 22, 2026, the flaws reached a large share of the web at once.⁷

How the flaws work

A PHP-powered web server handles each page request with a worker process. To save time, the same worker usually handles many requests one after another. Both flaws involve memory that a worker keeps or reuses after something goes wrong in a request.⁶⁸

Cloudflare summarized the shared root cause: both involve PHP mishandling memory after an error while it processes an HTTP request.⁸

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

When a PHP request runs out of memory (an OOM error), PHP abandons the work in progress using a C programming shortcut called longjmp(). According to PHP’s advisory, some request data can be reachable before it is fully set up. If the out-of-memory error happens at that moment, the data is left invalid, and PHP’s cleanup at the end of the request may then read it and act on it as if it were valid.⁵

The Debian security tracker, quoting the PHP report, notes that “multiple OOM strategies can consistently trigger this condition,” meaning an attacker has more than one way to force it.⁹

CVE-2026-109619: stale global state

PHP keeps some information in global state that lasts for the life of a worker, such as error, session and extension data. The advisory explains that this state can point to memory that belonged to a request that has already finished and been freed.⁶

When a later request on the same worker uses that information before PHP resets it, the program reads freed memory. This kind of bug is called a use-after-free. It is dangerous because an attacker may be able to control what now sits in that memory.⁶

The advisory names fatal errors, out-of-memory errors and some late warnings as the events that leave stale state behind. Settings applied before a request starts and PHP’s session upload progress feature, which reports how much of a file upload has arrived, can then use it. The confirmed exploit used fatal error backtraces, an option in PHP 8.5 that records where a fatal error happened.⁶

Wiz’s description

Wiz describes the research as several bugs grouped under the two CVE numbers. Its write-up links CVE-2026-109618 to a use-after-free in the upload progress handling of PHP sessions, plus a separate way to leak a server’s memory. It links CVE-2026-109619 to the fatal error backtrace bug and to a type confusion bug in OPcache, PHP’s built-in cache that stores compiled code in shared memory.¹

Wiz said it turned these bugs into working attacks with no login against WordPress, Drupal and Joomla, using the latest container image of each. It stressed that the attacks do not depend on the application, because the flaws are in PHP itself.¹

Who was affected

PHP’s advisory says every PHP installation that serves web requests is at risk. That includes PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed.² These are different ways of connecting PHP to a web server. mod_php runs PHP inside the Apache web server itself, while PHP-FPM runs a separate pool of PHP workers, often behind Nginx.

PHP rated the risk highest for mod_php, where, it said, a demonstrated exploit lets an unauthenticated request trigger the attack before any of the website’s own code runs.²

The two advisories give more detail on each setup:

Sources for the table: the two PHP advisories on GitHub.⁵⁶

Versions

Every PHP release before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 is affected.⁵ Wiz and Cloudflare both say the affected versions go back to PHP 5.4, and Wiz says every PHP version released in the last decade has at least one of the flaws.¹⁸

That matters because many websites still run old PHP. Among sites that use PHP, W3Techs counts 26.9% on PHP 7 and 7.7% on PHP 5, as of October 22, 2026.⁷ Neither branch gets updates from the PHP project.¹⁰

Applications and devices

Since the bugs are in PHP, every PHP application on an unpatched server is exposed, whatever it is. WordPress.org said no WordPress update was required or planned for the issue.¹¹ Cloudflare noted that updating website code or plugins alone does not fix it.⁸

PHP also runs inside products that are not websites. Help Net Security reported that Palo Alto Networks listed all versions of its PAN-OS and Panorama software as affected, with no fixed PAN-OS releases as of October 22, and that Fortinet and Cisco were still checking their products.¹² The UK’s National Cyber Security Centre (NCSC) told organizations to watch for updates from vendors whose appliances and services include PHP.¹³

Discovery and the role of AI

The PHP Foundation’s account of the discovery starts two years earlier. In 2024 the security firm Quarkslab audited PHP, in a project organized by the Open Source Technology Improvement Fund and paid for by Germany’s Sovereign Tech Agency. While fixing one of its findings, a PHP core developer spotted the first signs of the out-of-memory problem. At that time a possible exploit had only been theorized.¹⁴¹⁵

The fix then stalled for months. The PHP security team worked by consensus, and competing fixes each had trade-offs. The foundation later called this “a structural failure.”¹⁴

Three teams, two timelines

According to the PHP Foundation, the security firm Calif began an audit of PHP on July 30, 2026 under its Patch the Planet program. On August 11, Calif reported an unconditional remote code execution with the same root cause, and OpenAI reported it the same day. From then on, fixing the problem was the security team’s top priority. Wiz reported on August 24, and OpenAI reported further attack paths on September 18.¹⁴

Wiz’s own timeline covers its part. It says it found the first vulnerability on August 19, confirmed attacks with no login against Drupal on August 20 and WordPress on August 21, and reported to the PHP security team on August 24. Wiz says PHP acknowledged the reports and began a coordinated fix on September 21.¹

The two accounts do not conflict on dates, but they credit discovery differently: the foundation’s starts with Calif and OpenAI on August 11, while Wiz’s begins with its own finding on August 19.¹⁴¹ PHP’s GitHub advisories credit reporters from all three groups, under their GitHub user names.⁵ The php2shell.com site names the four Wiz researchers, Amy Burnett of OpenAI’s Codex Security team and Ryan A. of Calif.³

AI models

Wiz said it used its own Wiz Atlas tool and two AI models, Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol, throughout the work. It said the models helped find the bugs, build exploits, adapt them to different PHP versions and memory layouts, and check the fixes, which cut the specialist effort needed for each target.¹ Help Net Security reported Wiz’s view that frontier AI models had substantially lowered the barrier to turning long-standing flaws into working attacks.¹²

The PHP Foundation said AI was changing its workload. Earlier in 2026, Alpha-Omega and Anthropic’s Claude Mythos had scanned PHP, and OpenAI’s Daybreak Red was later added to help check reports and exploits. The security team had published 15 CVEs since July 1, 2026 and handled more than 100 reports that were invalid, duplicates or could not be reproduced.¹⁴

The foundation said AI helps it check and group reports, but that a person makes every decision and works on every fix.¹⁴ In May 2026 it had already set up an Ecosystem Security Team, funded by an Alpha-Omega grant, to help PHP projects handle security reports.¹⁶

Disclosure and the leak

Serious flaws are normally handled through coordinated disclosure. The finders tell the maintainers privately, a fix is prepared, and everyone involved agrees to keep the details secret until a set time. That agreement is called an embargo. For PHP2Shell, Linux distributions and long-term support vendors received the patches in advance so they could ship updates on release day.²

The embargo did not fully hold. Accounts of what leaked, and when, differ between sources.

October 20

According to the PHP Foundation, the two CVE numbers began circulating online at about 15:00 UTC on October 20, with a wrong release time and a wrong severity score of 10.0. No technical details leaked at that point.¹⁴ SecurityWeek reported that public reports, which already used the name PHP2Shell, came from the sites 0x4148.com and jackalsyn.com, and that CERT-EU, going by the severity scores, said both flaws could be exploited without a login.¹⁷

Infosecurity Magazine reported that a pseudonymous Hacker News user leaked details on October 20, before patches were ready.¹⁸

At 19:30 UTC the PHP project published its advance notice and moved the release forward one day, from October 22 to October 21 at 14:00 UTC.¹⁴ The notice warned that PHP might release earlier still if details became public or attacks appeared.⁴

At about 20:00 UTC, according to the foundation, Calif mistakenly published a video showing its proof-of-concept exploit (a demonstration that an attack works). The video was deleted, but copies spread. The foundation added that mitigation advice given to some critical infrastructure providers may also have leaked.¹⁴

Some organizations did not wait. Infosecurity Magazine reported that French public administrations, the Dutch National Cyber Security Centre and the University of Vienna took websites offline.¹⁸

October 21

At 3:02 a.m. UTC, Cloudflare switched on web application firewall rules against the attacks, nearly 11 hours before the 14:00 UTC release (Cloudflare’s post says about nine). A web application firewall (WAF) is a filter that inspects incoming requests and blocks ones that look like attacks. Cloudflare said it had started building the rules in early October and turned them on for every plan with its WAF, including the free plan.⁸

At 07:41 UTC, Chainguard published container images that already contained the fix, more than six hours early. The PHP Foundation described this as breaking the embargo.¹⁴

At 14:00 UTC, PHP released the fixed versions and its advisory, and published the two technical advisories on GitHub.²⁵⁶ The foundation said it had watched the proof-of-concept code circulating after the leak and had not identified a working exploit at the time of disclosure.¹⁴

Exploitation

Reports of attack attempts began before the official release. An attempt means someone sent attack traffic. The reports below do not say how many attempts succeeded.

• October 17. Amazon’s threat intelligence team said MadPot, its honeypot network (decoy servers built to attract and record attacks), caught a PHP2Shell attempt four days before disclosure. It came from an address tied to a commercial anonymizing service. Amazon believed a threat actor was responsible but did not know how that actor got details early.¹⁸
• Early October 21. Amazon said its sensors saw further attempts from several actors between 2 a.m. and 8 a.m. GMT, and broad exploitation after the patches shipped. Amazon said it was unclear whether the early attempts would have worked against real systems.¹⁸
• Cloudflare. Cloudflare said it saw attack traffic against its customers and attackers changing their payloads to get past its rules.⁸ Its chief executive, Matthew Prince, wrote on X that the company saw thousands of attempts in the 10 hours before disclosure, then tens of thousands within 45 minutes, hundreds of thousands within two hours, and later millions, as reported by Infosecurity Magazine.¹⁸
• Other firms. Beelzebub, Ellio, Recorded Future, VulnCheck, watchTowr and Wiz also reported attempts against one or both flaws.¹⁸

Before the release, watchTowr and Huntress had said they saw no attacks, while the security firm Sansec predicted mass exploitation within 15 minutes of the patches coming out.¹⁷ After the release, several proof-of-concept exploits were published.¹⁸

The record is mixed on one point: the PHP Foundation reported no working exploits at disclosure, while Amazon says it recorded an attempt on October 17 and Cloudflare’s chief executive reported thousands of attempts before the release. None of these sources says whether those early attempts succeeded.¹⁴¹⁸ Cloudflare said the vulnerability had leaked before the official date.⁸

Fixes, workarounds and official advice

Fixed versions

Sources for the table: PHP’s advisory and its supported-versions page.²¹⁹

PHP 8.1 and older no longer get updates from the PHP project. Because the flaws were so severe, the PHP security team still published minimal source code fixes for PHP 7.4, 8.0 and 8.1, for people who build PHP themselves or have no long-term support vendor.²

Linux distributions

Many servers get PHP from their Linux distribution rather than from php.net, and PHP told users to check their vendor for updated packages.² Several distributions shipped fixes on October 21:

• Ubuntu rated the issue critical and released fixed packages for its supported releases, including PHP 8.1 on Ubuntu 22.04, PHP 8.3 on 24.04 and PHP 8.5 on 26.04, with fixes for older releases through its paid Ubuntu Pro service.²⁰
• Debian issued fixed packages for PHP 8.4 on Debian 13 and PHP 8.2 on Debian 12.⁹
• AlmaLinux said on October 21 that it was shipping backported fixes for its supported PHP versions on AlmaLinux 8, 9 and 10, ahead of an update from Red Hat. Older PHP versions that had reached end of life under Red Hat Enterprise Linux, such as PHP 7.2, 7.3 and 8.0 on AlmaLinux 8 and PHP 8.1 on AlmaLinux 9, were left out of the first round, and AlmaLinux advised users of those versions to move to a supported one.²¹

This is why a server can show an older version number, such as 8.1.2 on Ubuntu, and still be patched.²⁰

Workarounds

PHP said there were no complete mitigations and that updating was the only safe choice. For servers that could not update at once, it listed settings that reduce exposure to specific attack paths without making a server safe:²

• Remove the PHP memory limit (memory_limit=-1) in a way applications cannot override, and keep request sizes low, for example post_max_size at 8M when uploads are not needed.²
• Turn off session upload progress (session.upload_progress.enabled=0) and, on PHP 8.5, fatal error backtraces (fatal_error_backtraces=0), then restart every worker.²
• Use container or cgroup memory limits as a safety boundary, but not the RLIMIT_AS or RLIMIT_DATA limits, which can trigger the bug.²

A web application firewall can block known attacks while a server is patched. Cloudflare said the PHP runtime itself still has to be updated.⁸ BleepingComputer quoted Cloudflare’s chief technology officer, Dane Knecht, describing the protections as temporary, and PHP core developer Gina Peter Banyard saying that no mitigation fully blocks attacks.²²

Signs of an attack

Wiz suggested watching server logs for unusual multipart requests (the kind used for file uploads) followed by memory-limit errors or repeated HTTP 500 errors, unexpectedly large or malformed PHPSESSID session cookies, and PHP workers restarting for no clear reason.¹

Government and platform advice

The UK’s NCSC published six priority actions on October 21:¹³

1. Find every PHP installation, starting with systems that face the internet, including ones whose version may not look out of date.
2. Update to the latest PHP version and keep watching for further updates.
3. If updating is not possible, apply the temporary mitigations PHP has published.
4. If mitigations cannot be applied, or would take too long, consider taking the system offline.
5. If a system can be neither updated nor taken offline at once, check it for signs of compromise and backdoors (hidden ways back in left by an attacker), with outside incident-response help if needed.
6. Watch third-party vendors whose appliances and services include PHP, and apply their updates as they arrive.

In the NCSC’s words, organizations unable to mitigate should “consider taking the system offline until it can be fully mitigated.”¹³

WordPress.org said no WordPress update was needed, that web hosts might already be updating PHP and adding firewall rules, and that people managing their own servers on PHP versions older than 8.2 should consider taking those servers offline while they prepare to update.¹¹

Significance

Two earlier critical PHP flaws were narrower in scope. CVE-2012-1823 affected PHP only when it ran as a CGI program, and CVE-2024-4577 affected CGI setups on Windows.²³²⁴ PHP2Shell’s confirmed attack works against Apache with mod_php, and PHP says every installation serving web requests is at risk.²

It also showed how AI is changing security research. Wiz said AI models cut the expert effort needed to turn old bugs into working attacks, and the PHP Foundation said AI-assisted research had brought it far more reports than before.¹¹⁴

The foundation used its post to admit process failures. It said the first signs of the underlying bug were found in 2024 and that the fix stalled for months, which it blamed on its decision process and a lack of resources. It said it had begun changing its processes so the security team can decide by majority and leadership can help steer stalled fixes, and that resolving complex fixes faster was now a priority.¹⁴

The incident may also have a long tail. Help Net Security reported warnings from the forensics expert Hal Pomeranz about forgotten and embedded PHP installations that may never be patched.¹² On the PHP project’s own schedule, PHP 8.2 stops getting security fixes on December 31, 2026, so sites on that branch will need to move again soon.¹⁹

Timeline

1. October 21, 2026PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35 at 14:00 UTC with fixes for both flaws²
2. October 21, 2026Ubuntu rates the flaws critical and publishes patched PHP packages²⁰
3. October 21, 2026Chainguard publishes fixed container images at 07:41 UTC, which the PHP Foundation calls an embargo break¹⁴
4. October 21, 2026Cloudflare says it switched on firewall rules against the attacks at 03:02 UTC⁸
5. October 20, 2026PHP pre-announces a critical security release and moves it forward a day¹⁴
6. October 20, 2026The two CVE numbers circulate online with a wrong 10.0 score; a Calif exploit video is posted by mistake¹⁴
7. October 17, 2026Amazon says its honeypot recorded a PHP2Shell attack attempt¹⁸
8. September 21, 2026PHP acknowledges Wiz's reports and starts a coordinated fix, according to Wiz¹
9. September 18, 2026OpenAI reports further attack paths to PHP¹⁴
10. August 24, 2026Wiz reports its findings to the PHP security team¹
11. August 21, 2026Wiz confirms code execution with no login against WordPress¹
12. August 20, 2026Wiz confirms code execution with no login against Drupal¹
13. August 19, 2026Wiz finds its first PHP2Shell bug using AI models¹
14. August 11, 2026Calif and OpenAI report an unconditional remote code execution flaw to PHP¹⁴
15. July 30, 2026Calif begins an audit of PHP under its Patch the Planet program¹⁴
16. 2024While fixing a Quarkslab audit finding, a PHP developer spots the first signs of the out-of-memory problem¹⁴

What it means for your website

See also

• PHP
• WordPress
• Heartbleed (2014) (coming soon)
• Apache HTTP Server (coming soon)
• Website builder vs WordPress vs web designer
• Web hosting
• WordPress review

References

1. PHP2Shell. Wiz Research (Sagi Tzadik, Shir Tamari, Nir Ohfeld and Tomer Schwartz). 2026-10-21. accessed October 22, 2026.
2. Security advisory: Critical remote code execution vulnerabilities, update now. The PHP Group. 2026-10-21. accessed October 22, 2026.
3. PHP2Shell: AI uncovers critical vulnerabilities in the backbone of the web. php2shell.com (Wiz, Inc.). 2026-10-21. accessed October 22, 2026.
4. Upcoming Critical PHP Security Release. The PHP Group. 2026-10-20. accessed October 22, 2026.
5. RCE via OOM corruption (GHSA-w8hw-w9fx-j79w, CVE-2026-109618). PHP project on GitHub. 2026-10-21. accessed October 22, 2026.
6. RCE via stale global state (GHSA-6wmf-4rv5-p3rp, CVE-2026-109619). PHP project on GitHub. 2026-10-21. accessed October 22, 2026.
7. Usage statistics and market share of PHP for websites. W3Techs. 2026-10-22. accessed October 22, 2026.
8. Cloudflare deploys protections against php2shell vulnerability. Daniele Molteni, Dan Jones and Kuber Nandwani, Cloudflare blog. 2026-10-21. accessed October 22, 2026.
9. CVE-2026-109618. Debian Security Bug Tracker. 2026-10-21. accessed October 22, 2026.
10. Unsupported Branches. The PHP Group. accessed October 22, 2026.
11. Critical PHP Security Release. John Blackbourn, WordPress.org News. 2026-10-21. accessed October 22, 2026.
12. PHP2Shell: Critical PHP vulnerabilities patched, update now. Mirko Zorz, Help Net Security. 2026-10-21. accessed October 22, 2026.
13. Critical security issue affecting PHP. UK National Cyber Security Centre. 2026-10-21. accessed October 22, 2026.
14. Today's PHP Security Release, and How We're Strengthening PHP Security. The PHP Foundation. 2026-10-21. accessed October 22, 2026.
15. PHP Core Security Audit Results. The PHP Foundation. 2025-04-10. accessed October 22, 2026.
16. Announcing the Ecosystem Security Team at The PHP Foundation. The PHP Foundation. 2026-05-18. accessed October 22, 2026.
17. PHP2Shell: Mass Exploitation Looms for Leaked Critical PHP Flaws. Ionut Arghire, SecurityWeek. 2026-10-21. accessed October 22, 2026.
18. PHP2Shell Exploitation Attempt Detected by Amazon Four Days Before Vulnerability Disclosure. Kevin Poireault, Infosecurity Magazine. 2026-10-22. accessed October 22, 2026.
19. Supported Versions. The PHP Group. accessed October 22, 2026.
20. CVE-2026-109618. Ubuntu Security, Canonical. 2026-10-21. accessed October 22, 2026.
21. php2shell (CVE-2026-109618, CVE-2026-109619): Patched PHP packages released. Jonathan Wright, AlmaLinux blog. 2026-10-21. accessed October 22, 2026.
22. PHP ships emergency patches for critical PHP2Shell flaws. Sergiu Gatlan, BleepingComputer. 2026-10-21. accessed October 22, 2026.
23. CVE-2012-1823 Detail. National Vulnerability Database, NIST. accessed October 22, 2026.
24. Security Alert: CVE-2024-4577, PHP CGI Argument Injection Vulnerability. DEVCORE. 2024-06-06. accessed October 22, 2026.
25. Site Health Screen. WordPress.org Documentation. accessed October 22, 2026.

Web Building Encyclopedia. First published October 22, 2026. Last reviewed October 22, 2026. Every fact on this page is linked to a source we opened. Spotted an error? Write to [email protected].