AI Found a Years-Old PHP Flaw That Can Take Over Websites

If you have shopped online, read a blog or logged into a website today, there is a good chance a programming language called PHP was running behind the page. Most people have never heard of it. About 69 percent of websites whose server-side language is known run on PHP, and WordPress, which powers roughly 40 percent of all websites, is built on it. On Oct. 21, researchers disclosed two critical flaws in PHP itself.

The flaws, nicknamed PHP2Shell and tracked as CVE-2026-109618 and CVE-2026-109619, each score 9.2 out of 10 on the standard severity scale. In researchers’ tests, an attacker could send a crafted web request and run code on a server with no password or login. In plain terms, whoever sends the request can take control of the process running the website.

Researchers confirmed such a takeover on WordPress and Drupal within two days of finding the first bug, and a separate security firm reproduced it on Magento and ten other popular PHP applications. The PHP project released emergency patches the same day.

Does Your Website Use PHP?

Palo Alto Networks counts more than 22 million instances as potentially vulnerable, a figure that includes servers that may not be exploitable. Attacks began before the patches did. Cloudflare reported attempts on the morning of Oct. 21, ahead of PHP’s 14:00 UTC release, and a public exploit tool now chains both bugs. Researchers differ on scale: watchTowr saw attempts but no successful ones, while Hadrian reported exploitation at scale. Whether it touches you depends on which of two groups you are in.

•      If you only visit websites: You usually cannot tell what a site runs on, and you cannot patch it yourself, because the fix has to happen on the site’s servers. The risk is that a site you use stays unpatched. One security firm says a bug can leak memory from other requests on the same server, including passwords, session tokens and API keys, even when the site never starts a login session. What an attacker could reach depends on what that site holds.

•      If you own or manage a site: WordPress, Drupal, Joomla, Magento, WooCommerce and Laravel all run on PHP, so a site built on any of them is exposed until the server’s PHP is patched. Hosted builders are a separate question. Owners on Wix, Squarespace, Shopify and similar services should ask the vendor directly whether PHP is involved.

What You Can Do

There is nothing to install on your own computer or phone. The steps depend on which group you are in.

If you only visit websites

•      Use a different password on every site and turn on two-factor authentication where it is offered, so one breached site cannot unlock others.

•      Watch for breach notices from sites where you have accounts, and change that site’s password if you get one.

•      For the next few weeks, pay small, lesser-known stores with a credit card or a payment service rather than a debit card.

If you own or manage a site

•      Check your PHP version. On WordPress, go to Tools, then Site Health, then Info, and open the Server section. Your hosting control panel shows it too. Write down the full number, such as 8.3.36, not just 8.3.

•      Compare it with the fixed versions: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. On PHP 8.1 and older, the version number may not show whether a backport was applied, so ask your host.

•      Ask your host, in writing, which version your site runs and when the patched version will be live for your account. On shared and managed hosting, the host controls PHP, so you cannot patch it yourself.

•      Do not rely on plugin or theme updates. As Sansec puts it, “You cannot fix PHP2Shell from within your store code,” because the attack runs inside PHP before the application loads. PHP’s advisory says partial measures, such as lowering upload limits and switching off the session upload-progress feature, reduce exposure but do not make a server safe.

•      Look for signs of compromise, including unknown administrator accounts, modified files and unusual traffic. If you find any, rotate passwords and API keys. No vendor has published confirmed indicators of compromise yet, so a clean scan does not rule out an attack.

•      If you run your own server, update PHP itself and restart the PHP service. The PHP project’s security team also published source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves.

How the AI Discovery Worked

Both bugs trace to what PHP does when a request runs out of memory. PHP’s own advisory says an out-of-memory error can interrupt PHP while request data is only partly set up, and the cleanup step then treats that broken data as valid. A second flaw lets internal state from one request outlive the memory behind it, so a later request on the same server worker can use it before it is reset.

The weakness is old. The vulnerable code reaches back to PHP 5.4, and the security firm Calif has said it spotted an early out-of-memory flaw in 2020 and again in a 2024 audit. It went unpatched because no one had shown it could be exploited.

Wiz, which Google bought earlier this year, says its team used its own Atlas platform along with Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol. It credits Gemini 4 Argon with work from discovery through patch validation. Wiz’s timeline shows the first bug found Aug. 19, a working takeover of Drupal confirmed Aug. 20 and of WordPress on Aug. 21. OpenAI and Calif worked on the problem too, and OpenAI says it led a coalition that spent about two months preparing fixes.

Calif and OpenAI independently reported the out-of-memory problem on Aug. 11, and Wiz reported its findings to the PHP security team on Aug. 24. PHP acknowledged the reports Sept. 21 and began a coordinated fix with maintainers and security providers. Information leaked Oct. 20, and the project moved its release up a day, from Oct. 22 to Oct. 21.

Why This Story Matters Beyond the Technical Details

The timeline is the story. Calif says an early version of the out-of-memory flaw sat unpatched because no one had shown it could be exploited. Wiz’s team, working with AI models, went from its first finding to confirmed takeovers of Drupal and WordPress in two days. Taken together, those accounts suggest AI’s edge lies in turning suspected weaknesses into working attacks.

The same capability that let defenders find and fix the problem lowers the barrier for attackers once details circulate. The defender’s window, the time between discovery and public disclosure, was used here, but it narrowed. A video demonstrating a working proof of concept was published by mistake, and the security vendor Chainguard published images containing the fix about six hours before the coordinated release.

For most people, the practical impact will be temporary outages or slower sites while operators patch, and a good reason to ask whether the services they rely on have updated. For the people who keep those sites running, it is an emergency update cycle on software many treat as background infrastructure.

The patches are out, and the race to apply them is underway. One more deadline is close: PHP 8.2, one of the fixed branches, reaches end of life on Dec. 31, 2026.

Sources:

•      PHP, security advisory (Oct. 21, 2026)

•      Wiz Research, “PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet”

•      SecurityWeek, “PHP2Shell Patches Land as First Exploitation Attempts Hit Sensors”

•      Sansec, “PHP2Shell: Critical PHP RCE (CVE-2026-109618, CVE-2026-109619)”

•      TechTarget, “PHP2Shell: 22M exposed servers at risk as emergency patches released”

•      W3Techs, usage statistics for PHP

•      W3Techs, usage statistics for WordPress

•      Wordify, “PHP critical security release, October 2026: what it means for your WordPress site”

•      xCloud, “PHP2Shell WordPress Guide: What to Do on Any Host”

•      Digidop, “PHP2Shell critical PHP flaw: what to do about WordPress”

•      ITdaily, “Google completes $32 billion acquisition of Wiz”