What is PHP2Shell? The critical PHP flaw, explained

In October 2026, two serious flaws were disclosed in PHP, the programming language that runs a very large share of the web. They were given the nickname PHP2Shell. This is part 1 of a 4-part series. It explains what happened without assuming you know any programming. Part 2 goes deep on how the bugs work, part 3 covers how they were found (AI played a part), and part 4 is the patching guide.

First, what is PHP, and why does a bug in it matter?

PHP is a programming language that websites use to build pages on the fly. WordPress, which runs a huge number of websites, is written in it. So are Drupal, Joomla, Magento, Laravel, Nextcloud and phpMyAdmin. Wiz, one of the companies that found the flaws, puts PHP at roughly 70 percent of websites (its own estimate, as reported by The Next Web). Qualys, a security company, counted about 167 million PHP installations in data from around 12,000 of its customers. See the Qualys write-up.

Most security news is about a mistake in one product, such as one plugin or one app. This one is different. The mistake is in the engine underneath. Every website that runs on a vulnerable PHP version is exposed, even if the website's own code is perfect.

What does "RCE" or "shell" mean?

RCE means remote code execution: someone far away makes your server run instructions of their choosing. A shell is a command line, the kind of text window where you type commands to a computer. "PHP2Shell" is the nickname because the end goal of an attack is a shell on your server.

The PHP project's advisories describe the result as unauthenticated code execution as the web worker account, meaning the low-privilege user the web server runs as. That is not "full control of the machine" on its own. It is still enough to read the site's files, read its settings (which often include database passwords and API keys), change pages, and use the server as a stepping stone.

The two bugs, simply put

Both bugs come from the same kind of problem: PHP is interrupted in the middle of a job, and something later trusts the unfinished work as if it were complete.

Bug 1 (CVE-2026-109618): running out of memory

When PHP handles a request, it builds things in memory, like a chef building a dish. Every request is allowed a fixed amount of memory (the memory_limit setting). If PHP runs out partway through building something, it does not stop politely. It jumps straight out of what it was doing. If that happens at the wrong moment, the half-built thing is left behind, and a cleanup step that runs afterwards treats it as finished.

The key point: the attacker can choose when the kitchen runs out of space, by sending a request designed to use up memory at a precise moment. The advisory lists three ways to do that with an upload-style request. You will find them in part 2.

Bug 2 (CVE-2026-109619): leftovers from a previous visitor

A PHP worker is like a hotel receptionist who serves one guest after another. A good receptionist wipes the desk between guests. In this bug, a first request can leave a note on the desk pointing at a drawer that has since been emptied. If the next guest's request reads that note before the desk is wiped, it follows the pointer into a drawer that now holds something else. The attacker needs both requests to land on the same worker. More workers makes that harder, not impossible.

Who is affected?

• Fixed versions: PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. Anything older on those branches is affected.
• Older PHP: 7.4, 8.0 and 8.1 get no regular upstream fix, only limited source backports. Cloudflare says the problem affects PHP 5.4 and later. CISA says organizations on PHP 8.1 or earlier should take PHP systems offline until they are updated.
• How PHP is run: the PHP advisories say Apache with mod_php is confirmed exploitable and the most urgent. PHP-FPM, FrankenPHP and LSAPI are also in scope, with different details covered in part 2.
• Apps: because the flaw is in PHP, popular PHP apps can be exposed even with clean code. Sansec lists the ones Calif named as affected: Magento, WordPress, Drupal, Joomla, MediaWiki, Roundcube, phpMyAdmin, Nextcloud, Laravel, Symfony and WHMCS (Sansec).

A worrying detail from the Qualys data: of the installations with a known version, about 44 million run supported branches (8.2 to 8.5), and about 110 million run branches that are already past end of life. Those are one vendor's estimates, not a census of the web.

What could an attacker actually do?

Three things are documented:

1. Run code on the server as the web worker account (the PHP advisories).
2. Read memory from the PHP worker. Sansec says this can leak passwords, session tokens, API keys and TLS private keys. Sansec says this works through the session cookie (PHPSESSID), and Datadog describes the same technique.
3. Crash workers (denial of service), which is what a failed attempt often looks like.

To make that concrete, here is an illustrative example, not a real incident. A small company runs a WordPress marketing site on an old PHP version, with a chatbot plugin that holds an API key for an AI model. If an attacker reads the worker's memory, that key could be in it. They could then run up the company's AI bill or read what the chatbot sends. The site's login page and security plugins would not have stopped any of it, because the attack happens before they run.

How worried should you be?

Honestly: very serious, but not "everything is hacked tonight."

• PHP rates both bugs 9.2. Early rumors said 10.0, which PHP's own team says was wrong (Alexandre Daubois, PHP security team).
• The severity rating itself says exploitation is high complexity: it depends on the exact PHP build, settings and memory layout. One analyst argues a reliable internet-wide exploit does not exist yet and the public examples are tied to specific lab setups (Daniele Berardinelli's analysis). Sansec reports that public proof-of-concept code it was told about did not work against a default install.
• That is not a reason to wait. Attack traffic was reported anyway: Amazon's honeypots recorded an attempt on 17 October, four days before disclosure, and Cloudflare reported attackers adjusting payloads on 21 October. CISA had not seen exploitation when it published its alert on 21 October, and neither CVE was on its Known Exploited Vulnerabilities list as of 22 October. CISA added both to that list on 26 October, which for US federal agencies set a patch deadline of 29 October. Part 4 covers the details and the disagreements.

Attackers only need to get reliable on the most common setups. Time is on the defenders' side only if they patch quickly.

Where to go next

• Part 2: how the two bugs work, with diagrams, for technical readers.
• Part 3: how it was found, including what AI did and did not do, and the leak.
• Part 4: how to patch and protect your servers, whatever your setup.
• PHP2Shell explained in 3D: an interactive animation of both flaws, for anyone who prefers to watch.

Sources: PHP advisory for CVE-2026-109618, PHP advisory for CVE-2026-109619, CISA alert, Qualys write-up, Alexandre Daubois, PHP security team, Daniele Berardinelli's analysis, Sansec, Datadog Security Labs, The Next Web, Cloudflare. Read 23 October 2026. Examples marked illustrative are not real incidents