Two critical PHP flaws sent governments scrambling to take websites offline. What PHP2Shell is, who is exposed, and what to do if you run a site

What happened?

On Tuesday, October 20, the PHP project posted an unusual notice on php.net: a critical security release would ship the next day at 14:00 UTC. On Wednesday, October 21, it published the fixes alongside a security advisory headed with an instruction to update now. The advisory covers two vulnerabilities, each scored 9.2 out of 10 on the CVSS v4.0 scale, and each allowing remote code execution by an attacker who does not need to log in.

The security firm Wiz, which found both issues and has published a technical write-up, named the pair PHP2Shell. The name stuck in government advisories and news coverage within hours.

What are the two flaws?

Both live in PHP's core engine rather than in any particular website's code, which is what makes them unusual. A bug in a plugin affects sites that use that plugin. A bug in the engine affects, potentially, everything built on it.

• CVE-2026-109618 is a memory corruption problem triggered when PHP runs out of memory partway through setting up a request. The advisory explains that cleanup code can then treat half-initialized data as valid.
• CVE-2026-109619 involves stale state: data that belongs to one request can survive after its memory is released and then be used by a later request on the same worker process.

Wiz says it demonstrated unauthenticated code execution against the current official container images of WordPress, Drupal and Joomla, and also showed that worker memory could be read remotely. That second point matters for small businesses because server memory can hold passwords, API keys and session tokens. Wiz says even a minimal application can be vulnerable, because the attack happens before application code runs. The PHP advisory says Apache's mod_php is the highest-risk setup, and lists PHP-FPM, php-cgi, FrankenPHP and LiteSpeed among exposed configurations. Qualys notes that PHP-FPM blocks one of the out-of-memory paths at startup, but PHP still validated an attack against FPM through the session lifecycle.

Sources: PHP security advisory and php.net supported versions. The 8.6.0 release candidate RC4 also contains the fixes.

How did AI come into it?

This is one of the first critical, internet-wide vulnerabilities where AI tools are credited with a central role in the discovery. Wiz says it found both flaws using its own platform together with Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol models, and that the models helped with discovery, exploit development and checking the patches. Wiz also says the flaws had existed for more than a decade. Those are the company's own descriptions of its work.

According to Al Jazeera, the security firm Calif, working with OpenAI, reported the first flaw to PHP's maintainers on August 11, and Wiz reported the second on August 24. Wiz's own timeline says it found the first bug on August 19 and confirmed working attacks on Drupal and WordPress the following two days. OpenAI says the disclosure was coordinated through its Patch the Planet program, with the PHP maintainers leading the fix and companies including Cloudflare and Wiz contributing, according to coverage of its announcement by PPC Land. OpenAI also said it expects findings like this to rise sharply in the coming months.

The same tools cut the other way. The security firm watchTowr told The Record it had seen in-the-wild exploitation attempts using proof-of-concept code, some of it apparently written with AI help, though it had not seen a successful attack at that point. Amazon's threat intelligence team recorded an attempt against its honeypot sensors on October 17, four days before the public disclosure, and does not know how the attacker obtained the details, Help Net Security reported.

Why were websites taken offline?

Security agencies on several continents gave unusually blunt advice. The U.S. Cybersecurity and Infrastructure Security Agency's alert tells organizations to inventory every PHP system, including PHP embedded inside other products, to patch internet-facing systems first, and to take systems offline if they cannot be updated or are running PHP 8.1 or older. CISA said it had not observed exploitation as of its publication. The European Union's cybersecurity team, CERT-EU, said proof-of-concept code was circulating, which raises the chance of exploitation.

Many public bodies took the cautious route. A Reuters factbox listed preventive takedowns of sites run by Germany's federal IT provider, French prefectures, Belgium's foreign ministry, Finnish government services, a Czech government site, and in the Netherlands the Port of Rotterdam, the national government portal and many hospital sites, along with some Wikimedia Foundation systems. Several of those organizations said they had seen no attacks. The University of Washington published a status page explaining that it deliberately took many sites offline while it patched.

How many sites could be affected?

PHP is the most widely used server-side language on the web. W3Techs reported on October 22 that PHP is used by 69.3% of the websites whose server-side language it can identify, far ahead of the next most common at 8.1%. That figure covers WordPress, the most common way small businesses run a website, along with Drupal, Joomla, most online stores built on PHP platforms, and countless custom sites.

The version data is where the risk concentrates. Every PHP 7 and PHP 5 site is on a line the PHP project stopped supporting years ago, and within PHP 8, branches 8.0 and 8.1 are also past end of life.

Combining those two W3Techs breakdowns, our own arithmetic puts roughly 48% of PHP websites on branches that receive no official fix: all of PHP 7 and older, plus PHP 8.0 and 8.1. That is an estimate from survey data, not a count of vulnerable servers; many hosts backport security patches to older versions. GoDaddy, for example, says cPanel has backported the fixes to PHP 7.4, 8.0 and 8.1. Palo Alto Networks put the number of potentially vulnerable exposed instances at more than 22.6 million, according to TechTarget.

What should a small business with a website do?

Most small businesses do not run their own servers. The question is who does, and whether they have finished patching. Work through this list in order.

1. Find out who runs your PHP. If you use a hosted platform such as managed WordPress, the host patches the server. If you have a VPS, a dedicated server or a cPanel account you administer yourself, you or your developer are responsible.
2. Check the version. In WordPress, Tools, then Site Health, then Info, then Server shows the PHP version. In cPanel, the MultiPHP Manager shows it. You want 8.5.12, 8.4.27, 8.3.36 or 8.2.35 or later, or a vendor build your host confirms includes the backported fix.
3. If a host manages it, get confirmation in writing. Many large hosts posted status pages on October 21 and 22. GoDaddy, for instance, said its managed WordPress and Windows hosting were patched and that VPS customers must update their own servers through EasyApache 4.
4. If you manage it, update and restart. Install the patched packages from your Linux distribution or control panel, then restart every PHP worker, PHP-FPM pool and web server. The fix does not protect a process that is still running old code.
5. If you cannot update today, the PHP advisory lists interim settings, such as disabling session upload progress and tightening request size limits, and says they are not a substitute for updating. CISA's advice for systems that cannot be patched is to take them offline. A web application firewall from your host or a CDN can block known attack patterns in the meantime.
6. Plan the upgrade off old PHP. If your site runs PHP 7 or 8.1, this is the moment to schedule the move to a supported version. Test themes and plugins on a staging copy first.
7. Rotate secrets if you were exposed. Because one flaw can leak memory, sites that were reachable and unpatched should change database passwords, API keys and admin passwords after patching, and check for unfamiliar admin accounts or files.

What happens next?

The immediate risk window is now, while automated scanning is at its peak. Over the next weeks, expect more products that embed PHP, from appliances to hosting panels, to ship their own updates; CERT-EU points administrators to a repository maintained by the Dutch national cyber security center that tracks third-party products. PHP 8.2 reaches its end of security support on December 31, 2026, so sites on that branch have a second deadline coming. And if OpenAI and Wiz are right that AI-assisted research will surface more bugs of this kind, the practical lesson for small businesses is simple: know who patches your server, and how fast.

For the policy backdrop on AI-driven security research, see our earlier coverage of the FTC's probe into rogue AI agents and what small businesses should know about Windows 10 security updates.