2026 · Security

PHP2Shell: the two PHP flaws that put most of the web at risk

Last reviewed 26 October 2026

In October 2026 two critical memory-safety bugs in PHP itself, CVE-2026-109618 and CVE-2026-109619, leaked before the fix was ready. They let an attacker with no account run code on servers running PHP versions going back to 5.4.

What PHP2Shell is

PHP2Shell is the name researchers at Wiz gave to two vulnerabilities in the PHP language runtime, tracked as CVE-2026-109618 and CVE-2026-109619. PHP rated both 9.2 out of 10 under version 4 of the CVSS severity scale. watchTowr scored them 10.0, and the post that leaked them also claimed 10.0. The nickname comes from what a successful exploit gives an attacker: a shell, meaning the ability to run commands on the web server.

What made the bugs alarming is where they sit. They are in PHP’s engine, not in any one application, so a WordPress, Drupal or Joomla site can be vulnerable even when its own code and plugins are fully up to date. W3Techs data puts PHP behind roughly 69% of websites whose server-side language is known. PHP is also bundled with hosting control panels such as cPanel and Plesk, with vendor appliances and with some Windows software, where administrators may not know it is running.

Affected versions reach back to PHP 5.4, released in 2012. No password, account or user interaction is needed. The attacker only has to be able to send web requests to the server.

How the bugs work

Both flaws are memory-safety errors in the code that sets up and tears down each web request. CVE-2026-109618 is triggered when PHP runs out of memory partway through setting up a request. PHP then jumps straight to its error handling, skipping normal cleanup, and leaves internal data half-built. Code that runs later trusts that data, and an attacker who controls what fills the memory can plant forged structures there.

CVE-2026-109619 is about stale state. Internal pointers outlive the request memory they point to, so the next request handled by the same PHP worker process can act on leftover data. Wiz described a use-after-free in the session upload-progress feature and, separately, problems involving fatal-error backtraces and the OPcache extension.

The confirmed attack path runs through session upload progress, a feature added in PHP 5.4 and switched on by default. According to Akamai’s analysis, an attacker needs only a page that accepts file uploads, even one that ignores them, plus offsets that match the exact PHP build on the target. The application does not have to use sessions at all.

There is also a quieter risk. Wiz showed that the same memory errors can leak data from other users’ requests back to the attacker inside a session cookie. That data can include passwords, login tokens, API keys and certificates, and the leak works even when the attacker never gets code execution.

How an attacker could backdoor a server

Remote code execution means the attacker’s commands run with the permissions of the PHP worker, usually the web server account (often called www-data on Linux). From there the standard playbook is well documented. The attacker drops a web shell, which is a small PHP file in the website’s folder that accepts commands over ordinary web requests. They may also add scheduled tasks or cron jobs, create new accounts, download further tools, or read database passwords from configuration files.

Datadog’s researchers noted that some exploit chains could leave a malicious include active inside a PHP worker after a single successful request. They also pointed out that the attack happens below the application layer, so WordPress or Drupal logs may show very little.

Updating PHP closes the hole but does not remove anything an attacker has already planted. A backdoor installed before the patch keeps working after it. That is why incident responders advised checking for new files in the web root, unfamiliar cron entries and accounts, and PHP processes that start shells or download tools, as well as rotating credentials that could have leaked from memory.

An important caveat: as of 22 October 2026, we found no published report from a security company confirming web shells or other backdoors installed through PHP2Shell in the wild. SentinelOne said on 21 October that no confirmed compromise had yet been reported. The scenarios above describe what the bugs make possible, not documented incidents.

Who found it, and the role of AI

According to reporting on the disclosure, a PHP core developer noticed the out-of-memory error behind one of the bugs during an audit in 2024. It was not fixed, because the team could not agree on a fix and no one had shown it could be exploited.

In August 2026 the security firm Calif found the first exploitable bug using OpenAI’s GPT-5.6 Sol model, during an audit of PHP’s source code funded through OpenAI’s Patch the Planet programme. Wiz Research says it found the first flaw on 19 August using its own Wiz Atlas tool together with Google’s Gemini 4 Argon and GPT-5.6 Sol, confirmed unauthenticated code execution against Drupal on 20 August and WordPress on 21 August, and reported to PHP on 24 August. PHP acknowledged the reports on 21 September. Accounts differ on who found which bug first, and PHP’s advisories credit Calif, Wiz and OpenAI.

The episode is one of the clearest examples so far of AI models finding serious flaws in core internet software. Our explainer on AI and security looks at what that means for attackers as well as defenders.

How it leaked

The plan was a coordinated disclosure on Thursday 22 October 2026, with fixes ready. On 20 October a post on Hacker News claimed that two critical PHP remote code execution flaws would be announced that week. watchTowr confirmed on X that the leak was real and the bugs were under embargo. Calif also published a proof-of-concept video by mistake.

At 19:33 UTC on 20 October PHP posted an advance notice of an out-of-cycle release for 14:00 UTC on 21 October, and said it would release sooner if details spread or exploitation began. Both happened. Recorded Future found that an archive with leaked vulnerability details was uploaded to VirusTotal at 02:29 UTC on 21 October. The software supplier Chainguard shipped patched builds early, which let others compare old and new code to work out what had changed. Proof-of-concept code and partial write-ups circulated before the embargo ended.

PHP published its fixes on 21 October shortly before the scheduled time. Sources put the release between about 13:34 and 13:52 UTC.

Exploitation and impact

Attackers were moving before the patch existed. Amazon’s threat intelligence team reported an exploitation attempt against its MadPot honeypots on 17 October, four days before disclosure. Cloudflare saw early attack attempts and enabled firewall rules for all customers at 03:02 UTC on 21 October. Patchstack reported several active exploitation incidents from hosting partners that morning, and watchTowr’s honeypots recorded exploitation of both bugs the same day. The US cybersecurity agency CISA said it had not observed exploitation as of 21 October. No public figure exists for how many sites were actually compromised.

The exposure is very large. Scans by Modat counted about 4.4 million PHP services on 1.9 million hosts, and about 79% of those that reported a version were on a branch PHP no longer supports. These are counts of version banners, not confirmed vulnerable systems.

Many organisations chose to go offline rather than gamble. Government sites in the Netherlands, Finland and France were taken down as a precaution, as were some Canadian government services. The Wikimedia Foundation shut down supporting services and the Internet Archive briefly went offline. CERT-EU and the UK’s National Cyber Security Centre advised isolating systems that could not be patched straight away, and the US National Security Agency issued an alert.

What to do

The fixed releases are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. PHP also published source-code backports for the end-of-life 7.4, 8.0 and 8.1 branches, without official binaries. Linux distributions, cPanel and CloudLinux shipped their own packages. PHP 7.3 and older, including PHP 5, have no fix. The only safe option there is to upgrade or take the site offline.

watchTowr warned that no php.ini setting fully closes the hole, and PHP’s maintainers called temporary mitigations incomplete. Find every copy of PHP, including copies inside control panels, containers and appliances, and update it. Then look for signs of compromise from 17 October onwards and rotate passwords, tokens and keys the server could reach.

PHP2Shell landed in the same week as the eMudhra certificate failure and a Node.js security release fixing a remote code execution bug. Our eMudhra explainer covers the certificate side of that week.