The PHP2Shell Flaws: What You Need to Know and How to Protect Yourself Now

Headlines this week have called it a "PHP breach." The accurate description is different, and it matters for what you do next. Two critical vulnerabilities in the PHP engine itself, nicknamed PHP2Shell, were disclosed and patched on Oct. 21, 2026. They are not a break-in at one company. They are flaws in software that runs a large share of the web, and they can let an attacker run code on a server that has not been updated. Attacks have been reported. Governments and companies took some sites offline as a precaution. No one has published a count of sites that were actually compromised.

This article covers what happened, who is exposed, and a checklist for site owners, WordPress users and ordinary people with accounts on affected sites. It is general information, not a substitute for your host's or your security team's guidance.

What Happened

• Aug. 19 to 24: Wiz Research found the first bug and reported to the PHP security team, working with OpenAI and the firm Calif, according to Wiz. PHP acknowledged the reports on Sept. 21 and began a coordinated fix.
• Oct. 17: Amazon's MadPot honeypot recorded an exploit attempt before public disclosure, which Amazon described as largely a one-off probe, The Hacker News reports.
• Oct. 20: PHP pre-announced an out-of-band security release. The CVE numbers leaked in a since-deleted post on the Hacker News forum, and PHP moved its release from Oct. 22 to Oct. 21.
• Oct. 21: Patched versions shipped. Sources give release times from about 13:35 to 13:52 UTC, ahead of a 14:00 UTC schedule. Earlier that day, Cloudflare reported early attacks and added emergency firewall rules, and hosting partners told Patchstack about active exploitation. Some government and company sites, including Dutch government sites and major Japanese platforms per Patchstack, went offline as a precaution.
• Oct. 22: Axios reported that real-world harm has been limited so far and that many organizations have mitigated the risk.

What the Flaws Are

Both flaws, CVE-2026-109618 and CVE-2026-109619, are rated critical (CVSS v4.0 score 9.2) by the PHP security team, and PHP says both can allow unauthenticated remote code execution, meaning an attacker needs no login to run code on the server.

In PHP's description, the first involves out-of-memory handling that can interrupt PHP while request data is only partly set up, and the second involves per-request state that survives after its memory is freed and is reused by a later request. Wiz's write-up describes the mechanisms differently, as use-after-free and type confusion bugs, so we are not going deeper than PHP's own wording.

The key point is where the flaws sit: in the PHP interpreter, not in any application. A site can have perfectly secure code and still be vulnerable if its server runs an unpatched PHP. Updating WordPress, a plugin or a theme does not fix it. Wiz says it demonstrated unauthenticated code execution against the latest WordPress, Drupal and Joomla container images and also showed that process memory can be read, which could expose passwords, tokens and API keys.

PHP says all installations serving web requests are at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP and LiteSpeed, with mod_php rated highest.

Which versions? Sources differ. Wiz says nearly every release back to PHP 5.4 has at least one of the issues. CERT-EU says PHP 5 onward. VirusTotal notes that one affected feature, upload progress, dates to 5.4. PHP's advisory lists no version range. The safe reading: if you run any PHP that has not received the fix, assume you are exposed.

The AI angle. Wiz says it found the bugs using its own tooling plus Google's Gemini 4 Argon and OpenAI's GPT-5.6 Sol, and argues AI lowered the effort needed to turn long-standing flaws into working exploits. OpenAI told Axios: "To our knowledge, frontier AI found these vulnerabilities before attackers did."

Who Is Affected

PHP runs about 70% of websites whose server-side language is known, according to W3Techs figures cited by Infosecurity Magazine (69.7%) and the Wiz claim. That includes WordPress, Drupal, Joomla, Magento and MediaWiki, which runs Wikipedia.

Exposure estimates from scanners vary widely, and none count vulnerable sites directly:

• Mallory (Shodan banners, Oct. 20): about 2.24 million internet-facing PHP hosts, with 59% of the 1.5 million that report a version on a branch with no official release.
• Modat (via The Hacker News): 4.38 million internet-facing PHP services, about 79% on unsupported branches.
• VirusTotal: about 5.1 million IPs fingerprinted as PHP, with roughly four in five hiding their version.

The shared pattern is that a large share of servers run old PHP that no longer gets fixes from the PHP project. Some of those may have vendor backports.

Is It Being Exploited?

Reports say yes, with caveats. Cloudflare reported early attacks, Aikido reported exploitation in the wild citing Cloudflare, and Patchstack says hosting partners reported active exploitation, though its own telemetry showed only probing at the time. Wiz's post reported no in-the-wild exploitation when it was published. Axios says an attack emerged Oct. 21 but did not confirm its scale or the attackers.

The UK's National Cyber Security Centre said organizations that cannot remediate immediately should consider taking the system offline until it can be fully mitigated. CERT-EU advised isolating internet-facing applications from public networks until a fix is applied. TechCrunch reports the U.S. National Security Agency advised PHP users to update immediately or take affected systems offline.

What to Do If You Run a Server or Website

1. Find every PHP install. Include containers, staging and test sites, and appliances that bundle PHP. Patchstack lists these as places to check.
2. Update to a fixed version: PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or your Linux distribution's patched package, which may carry a different version number. PHP's advisory says: "Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35." Then restart PHP-FPM or the web server so the new interpreter loads.
3. On PHP 8.1 or older, the PHP project no longer issues fixes. Get a backport from your vendor or upgrade. PHP published minimal source backports for 7.4, 8.0 and 8.1 for people who build PHP themselves. PHP 8.2 reaches end of life on Dec. 31, 2026, so plan the next upgrade.
4. If you use the volunteer-run rpms.remirepo.net repository, PHP's advisory says to switch to distribution packages or build from source, because that repository had no updates at publication.
5. If you cannot patch yet, take high-risk sites offline or into maintenance mode, or restrict access by VPN or IP allowlist. A web application firewall can buy time, but Cloudflare calls its rules a stopgap that only helps if your server accepts traffic exclusively from Cloudflare. PHP also lists partial workarounds, such as setting `session.upload_progress.enabled = 0` in server configuration and capping request sizes, and states plainly: "There are no complete mitigations, updating is the only safe choice."
6. Look for signs of targeting. Patchstack and Wiz list unusual multipart requests followed by memory-limit errors, repeated HTTP 500 responses, unusually large or malformed `PHPSESSID` cookies, and unexplained PHP worker restarts. The FBI advised watching for PHP processes that launch command shells or download files. Also check for new admin users and modified PHP files.
7. If you find signs, treat the server as compromised. Rebuild or restore from a clean backup, and rotate every credential the server held: database passwords, API keys, tokens and application secrets. Because the flaws can also expose process memory, Patchstack suggests considering credential rotation on servers that were exposed.
8. Skip "fix" plugins and pasted snippets. Patchstack warns that unofficial fixes are unverified. OpenAI has released a Codex skill called `php2shell-checker` to test whether a site or PHP binary is vulnerable, according to The Hacker News; we have not tested it, so review any tool before running it on production.

What to Do on Shared Hosting or WordPress

• Ask your host which PHP version your account runs and whether it is patched. Many hosts patch centrally, so you may need to do nothing, but get confirmation from your host's status page or support, not a forum comment.
• Check your own version. Your hosting control panel or WordPress's Site Health screen shows the PHP version. Compare it with the fixed releases above, remembering that some hosts apply the fix under their own version numbers.
• If your host runs PHP 8.1 or older, ask about a backport or move to a supported version.
• Expect brief outages as hosts restart services.
• Keep WordPress, themes and plugins updated anyway. They do not fix this flaw, but attackers often chain several weaknesses.

Sites that are purely static, with no PHP running on the server, are not exposed through these flaws.

What to Do If You're Just an Account Holder

You cannot patch other people's servers, but you can limit the damage if one is compromised:

• Use a password manager and unique passwords, so one exposed password does not unlock other accounts, as Axios also advises.
• Turn on multi-factor authentication or passkeys for email, banking and any site that holds payment details.
• Change passwords promptly if a service you use tells you it was affected, and read the notice rather than skipping it.
• Be cautious of emails and texts about "the PHP breach." Scammers follow big headlines, so go to the company's site directly instead of clicking links.
• Don't panic. Experts quoted by Axios advise against it; real-world harm has been limited so far.

What We Can and Can't Conclude

This section is analysis, not reporting.

• "Breach" is the wrong word, for now. This is a vulnerability with reported attacks. Whether any specific company suffered a data breach from it is a separate question, and Axios mentions school data leaks and other incidents without tying them to PHP2Shell.
• The week's other incidents are not the same story. TechCrunch lists a compromised LiteLLM package, a certificate authority key compromise and other patched flaws, and says they are unrelated but arrived close together. Axios's "Black October" label covers the whole cluster.
• The embargo mattered. A leaked CVE list and a pre-disclosure probe on Oct. 17 show that the gap between disclosure and attack can be shorter than the gap between disclosure and patching for slow-moving servers.
• Old software is the long tail. The scanner data suggests a large share of PHP servers cannot get an official fix at all. For them the real choices are a vendor backport, an upgrade or retirement.
• We don't know the number of compromised sites, whether attackers are using AI to build exploits faster, or how many servers remain exposed.

Why It Matters

• The flaw is below your application. A secure website can still be exposed, and only a server-side PHP update fixes it.
• Patching is the only complete answer. PHP says there are no complete mitigations.
• Unsupported PHP is the biggest risk pool. Many internet-facing servers run versions that get no official fixes.
• AI is changing the pace of security work, for finding flaws and likely for exploiting them, so patch windows are shrinking.