PHP2Shell: AI helped find two critical PHP flaws. What to do now

Two critical security holes were found in PHP, the language that runs WordPress and many other websites. The holes are called PHP2Shell. An attacker can use them to run their own code on a web server, without logging in. PHP fixed them on 21 October 2026, and the only full fix is to update. The flaws were found with help from AI models, the researchers at Wiz say.

What is PHP2Shell?

PHP2Shell is the name for two flaws in the PHP engine itself, not in a plugin or theme. PHP published them in two security advisories on 21 October 2026. Both are rated 9.2 out of 10 on the CVSS scale, a common score for how serious a flaw is.

• CVE-2026-109618, "RCE via OOM corruption" (OOM means out of memory): when PHP runs out of memory at the wrong moment, it can leave half-built request data behind. The clean-up step then treats that data as real.
• CVE-2026-109619, "RCE via stale global state" (left-over data): a request is a message sent to a server, for example to load a web page. A worker is a server process that handles requests, one after another. Data from one request can stay behind in the worker after it is thrown away. The next request on the same worker can then use it by mistake.

RCE stands for remote code execution: someone on the internet can make your server run their code. PHP's advisories say the confirmed result is exactly that, "as the web worker account", so with the rights of the web server.

How AI helped find it

The security company Wiz says it used AI models throughout its research. "We used Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout this research," its research team says. Wiz Atlas is Wiz's own tool. Gemini 4 Argon is a model from Google, which we wrote about. Wiz says Argon "made an invaluable contribution to finding the vulnerability".

According to Wiz, it found the first flaw on 19 August 2026. PHP's advisories list people from Wiz, Calif and OpenAI as reporters, and PHP's own developers wrote the fixes. Wiz thanks Calif and OpenAI "for their work on discovery, coordination and patch verification".

So AI did not fix PHP by itself. People used it as a tool in their research.

Who is at risk?

Sites that run an affected PHP version may be at risk. How much depends on how PHP runs on the server. Apache with mod_php, PHP-FPM and FrankenPHP are three common ways to run PHP behind a website.

• Versions: Wiz writes that "every PHP version released in the last decade is affected by at least one of these vulnerabilities, going back to version 5.4."
• Apache with mod_php: confirmed. PHP's advisory says the reporters tested a full attack over the web against this setup.
• PHP-FPM: at risk too. For the second flaw (CVE-2026-109619), PHP's advisory says an attack was shown to work against PHP-FPM as well. For the first flaw, the code suggests PHP-FPM is at risk, but no full attack on it has been shown.
• FrankenPHP: likely at risk from the first flaw, PHP's advisory says, based on the code.
• WordPress, Drupal and Joomla: Wiz says it ran code without logging in on their container images, ready-made packages in which the software runs. These apps run on PHP, so they are at risk through PHP. Updating WordPress, plugins or themes does not fix it. Only a PHP update does.

Wiz also says PHP "powers 70% of all websites in the world". It does not say how it got that number, so read it as a rough estimate.

Is it being used in attacks?

There are attack attempts. In the sources we read up to 23 October, nobody reported a confirmed break-in.

• 17 October: Amazon saw "a PHP2Shell exploitation attempt" on its decoy servers, four days before the flaws were made public, its threat team writes. It is not clear how the attacker knew about the flaw.
• 20 October: PHP announced a critical release for 21 October. It said it might release earlier if details became public.
• 21 October: the first public attack code appeared around 02:00 UTC, Amazon says. PHP published the fixes that afternoon. Amazon writes that "it's unclear if any of these attempts would have succeeded in real-world systems."
• CISA: the US cyber agency keeps a list of flaws known to be used in attacks. In the version we read on 23 October, the two PHP2Shell flaws were not on it yet.

What should you do now?

Update PHP. php.net puts it simply: "There are no complete mitigations, updating is the only safe choice."

1. Find out which PHP your site runs. If a hosting company runs your site, ask them, or look in your hosting panel. Many hosts update for you; ask them to confirm it. 2. Update to a fixed version: 8.5.12, 8.4.27, 8.3.36 or 8.2.35. PHP 8.6.0 RC4, a test version, also has the fixes. 3. On PHP 8.1 or older: PHP itself no longer updates these versions. It did share small fixes for 7.4, 8.0 and 8.1 for people who build PHP themselves. The better step is to move to a supported version, or to get fixes from your Linux vendor. 4. If you cannot update today: PHP's advisories list some stopgap settings for server admins. They are not a full fix.

New advice, 23 October 2026, also for updated servers: PHP suggests turning off one setting, session.upload_progress.enabled, until its next regular bugfix release, the next normal release with bug fixes. It protects against one more, unlikely way in (CVE-2026-115560). PHP says to set it in the main PHP configuration and restart all PHP workers. Ask your host or admin to do this.

Note that PHP 8.2 gets no more security fixes after 31 December 2026, php.net says.

Linux: check the package, not only the number

If your server runs Ubuntu or Debian, the fix comes as a system update, and its version number can look old. On Ubuntu 24.04, for example, the fixed PHP is package version 8.3.6-0ubuntu0.24.04.13. The first part still says 8.3.6, which is lower than 8.3.36, but it does have the fix.

So do not judge only by the short version number. Check the full package version against Ubuntu's page or Debian's page. On 23 October, these versions were listed as fixed for both flaws (CVE-2026-109618 and CVE-2026-109619):

Our check: fixed Docker images on 21 October

We looked at the official PHP images on Docker Hub. Docker images are ready-made packages that many servers use. PHP published its advisories at 13:34 UTC on 21 October. A tag is the version label of such a package. Docker Hub shows when each tag was last updated; for the tags with the fixed version numbers, that was:

• php:8.5.12 5.4 hours later;
• php:8.2.35 8.4 hours later;
• php:8.3.36 8.5 hours later;
• php:8.4.27 8.6 hours later.

The last update is not always the first: an image can be online earlier and updated again later. So these times show that the fixed images were there by then at the latest, the same day. Restarting an old container is not enough: your admin has to pull the new image, create the containers again, and then check which PHP version runs.

What this means: AI on both sides

This case shows AI helping defenders: Wiz says AI models helped it find the flaws. According to Wiz, unfixed PHP versions from the last ten years are affected by at least one of the two. But Amazon warns that the same tools help attackers too: "AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit." A patch diff is the list of changes in a fix.

Amazon writes that "more actors can act within hours or even minutes once technical details of a vulnerability are disclosed." Its advice for critical flaws in systems on the internet: "measure patch and mitigation timelines in hours." For a small site owner, our advice is: turn on automatic updates where you can, and pick a host that patches fast.

How we checked

On 21 to 23 October 2026 we read php.net's news and release notes, PHP's two security advisories on GitHub, the research post by Wiz, Amazon's threat report, CISA's list of exploited flaws and the NVD entry. We quote these sources; we did not test the flaws ourselves.

On 23 October we checked when the official Docker image tags for the fixed versions were last updated, using the Docker Hub data, and which package versions Ubuntu and Debian list as fixed.

We left out how the attack works step by step. We only explain what you need to know to fix it. The charts were made by us. None of the images was made by AI. This is not legal or security advice for your own setup; ask your host or admin if you are not sure.