What Is PHP2Shell? A Plain-English Guide for Website Owners

As of 23 October 2026, PHP2Shell has been patched by the PHP project, attackers are widely reported to be trying it against websites, and no public source has documented a confirmed successful break-in. PHP2Shell is the nickname for two critical security flaws in PHP itself, the programming language that runs on the web server behind WordPress, Drupal, Joomla and many custom sites. They are tracked as CVE-2026-109618 and CVE-2026-109619, and the PHP project fixed both on 21 October 2026.

In plain terms: on an unpatched server, an attacker who never logs in can send specially built web requests that may let them run their own code on that server. The fix is to update PHP to 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or to a patched package from your Linux distribution or host, and then restart PHP. Updating WordPress, Drupal, Joomla or a plugin does not fix it, because the flaw is in the PHP engine, not in those applications.

This guide explains what happened, who is affected, who is not, what to do today, what artificial intelligence had to do with it, and why some sites went offline this week.

What PHP2Shell Is, in Plain English

PHP is the software on your web server that turns your site's code into the pages visitors see. W3Techs reports that PHP is used by 69.3% of websites whose server-side language it can identify. That is a share of sites using PHP, not a count of vulnerable sites.

The PHP project's 21 October 2026 advisory describes the two flaws this way:

• CVE-2026-109618, "RCE via OOM corruption": "out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid." Our CVE-2026-109618 explainer covers it for IT staff.
• CVE-2026-109619, "RCE via stale global state": "request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it." See the CVE-2026-109619 explainer.

RCE means remote code execution: someone on the internet gets your server to run commands of their choosing. PHP says both flaws "can allow unauthenticated remote code execution," which means no password or account is needed. If it works, the attacker's code runs with the permissions of the web server account. From there an attacker could change your site, plant a hidden back door (often called a web shell) or read files the site can read.

The name PHP2Shell comes from the researchers. It is not an official PHP term, but it is how most news coverage and vendor advisories refer to the pair.

How Serious Is It?

The PHP project scores both CVEs 9.2 out of 10 on the CVSS 4.0 scale, which counts as critical. Other scorers differ. The US National Vulnerability Database (NVD) gives CVE-2026-109618 a 9.8 and CVE-2026-109619 an 8.1 on the older CVSS 3.1 scale, and Red Hat rates both "Important" at 8.1. A score of 10.0 circulated before the release; the PHP Foundation says that number was wrong.

PHP's own advisory says the risk is highest on servers that run PHP as an Apache module (called mod_php), where "an unauthenticated request can trigger the attack before any application code runs." Servers using PHP-FPM, the setup many modern hosts use, are also listed as at risk.

Researchers disagree on how easy real-world attacks are. Calif, one of the research teams, calls the flaws "always exploitable under default configurations." Fastly says existing proof-of-concept exploits need knowledge of the exact PHP build running, so "most deployments may be 'safe' from RCE. Do not assume this holds true for you." Both views agree on one thing: patch.

Who Is Affected and Who Is Not

PHP's advisory says the risk covers "all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed." The CMS on top does not change that.

Two points need care. First, PHP often hides inside other software: CISA notes that "PHP is often a component of other software and prevalence may not be directly observable." Intranet tools, webmail, admin panels and billing systems can all run on PHP. Second, Automattic says all sites it hosts, including WordPress.com, WordPress VIP and Pressable, "are safe," and adds: "If you run your own servers, update now." For a fuller picture of who is responsible for what on each platform, see website security by platform.

How far back the flaws go is also disputed. PHP's advisories list only the supported branches. Wiz and Calif say affected code paths go back to PHP 5.4, and watchTowr says older unsupported branches, including PHP 5, are affected. If you are on any old version, assume you are exposed.

What to Do Today: Five Steps

1. Find out who runs your PHP. If you are on shared or managed hosting, your host runs it. If you have a VPS or your own server, you or your developer do. Write down every site and tool you own that might use PHP.
2. Get onto a fixed build. Upstream fixes are PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions such as Ubuntu, Debian, Red Hat and AlmaLinux shipped their own patched packages, which often keep the old version number. Ask your host in writing whether your server has the PHP2Shell fix. Our fixed versions table lists every branch.
3. Restart PHP. A fix on disk does nothing until the running PHP processes are replaced. PHP's own guidance says to "restart every worker." Hosts usually do this for you; on your own server, restart PHP-FPM or Apache.
4. If you cannot patch yet, reduce exposure or go offline. PHP lists temporary php.ini settings that "reduce exposure to specific attack paths but do not make an installation safe." CISA says organizations that cannot update, or that run PHP 8.1 or earlier, "should take PHP-based systems offline until they can be patched or updated." If you do take a site down, Beazley advises a maintenance page or network restriction "rather than disabling the PHP handler, which can expose application source code and credentials."
5. Check for signs of trouble, starting from 17 October. Amazon reported an exploitation attempt dated 17 October 2026, four days before disclosure, so investigators recommend looking back at least that far. Our guide was my site hacked through PHP2Shell lists what to look for.

Not sure which version you have? How to check your website's PHP version walks through WordPress Site Health, your control panel and asking your host, with no developer needed.

Why the Version Number Can Mislead You

This is the most common source of confusion this week. When Ubuntu, Debian, AlmaLinux or Red Hat fix PHP, they usually patch the version they already ship instead of moving to the new upstream release. AlmaLinux puts it bluntly: "Don't rely on php -v: our fixes are backported, so the upstream PHP version number doesn't change."

For example, Ubuntu 24.04 LTS lists its fixed package as php8.3 version 8.3.6-0ubuntu0.24.04.13. On that server, PHP will still report 8.3.6, which looks far older than 8.3.36, yet it carries the fix. The reverse is also true: a site reporting a fixed-looking number could be running an unpatched custom build. The only reliable check is the package version from your distribution or a written answer from your host.

What AI Had to Do With It

Artificial intelligence played a real but specific role. Wiz says it used "Wiz Atlas, Gemini 4 Argon and GPT-5.6 Sol throughout this research," and that "a single researcher completed in a week what previously would have taken a world-class team months of work." Calif says no special harness or unreleased models were used in its initial discovery. OpenAI's Codex Security team is also credited in PHP's advisories.

Defenders use AI too. The PHP Foundation says it scanned PHP with Anthropic's Claude Mythos earlier this year and uses other tools to validate reports, while "a person makes every call and works on every patch."

The practical lesson comes from Amazon's threat intelligence team: "AI-assisted analysis makes it cheaper to turn a patch diff or advisory into a working exploit." In other words, the gap between a fix being published and attackers trying it is getting shorter. That is a reason to patch faster, not a reason to panic.

Credit for finding the flaws is also disputed. The PHP Foundation and Calif say Calif reported first, on 11 August 2026. Wiz says it discovered its first finding on 19 August and reported on 24 August. PHP's advisories credit researchers from Calif, Wiz and OpenAI, among others.

Why Some Sites Went Offline

If you saw error pages or "down for maintenance" notices on 21 October, there are three ordinary explanations, and none of them means those sites were hacked:

• Precautionary takedowns. CISA, the UK's NCSC and an EU joint statement led by ENISA all advised taking systems offline or isolating them if they could not be patched quickly. Reuters reported government websites across Europe "went dark" as operators raced to patch.
• Patching and restarting. Updating PHP and restarting every worker briefly interrupts service, especially on servers that host many sites.
• Side effects of temporary settings. Some interim mitigations change how PHP handles memory and uploads. Removing PHP's memory cap can let a worker exhaust server memory, and low upload limits can break forms that accept files.

No source we reviewed attributes the outages to attacks.

Is Anyone Being Attacked?

As of 23 October 2026, Amazon, watchTowr, Cloudflare and Fastly report exploitation attempts in the wild, some before the public release. Bitdefender says its telemetry showed no attempts as of 22 October, CISA said at publication that it had not observed exploitation, and watchTowr says many of the exploits being sprayed "either don't work at all, test for timing-based differences, or crash the target." The fair summary is that widespread attempts are reported, and confirmed successful compromises are not publicly documented. We track every report with dates on our PHP2Shell exploitation status page.

One more item: on 23 October, PHP published an informational note about a related, less likely issue, CVE-2026-115560, which affects even patched releases under an unusual configuration. PHP suggests setting session.upload_progress.enabled=0 until its next regular release.

What PHP2Shell Means for Old PHP Versions

PHP 8.1 reached end of life on 31 December 2025, and 8.0 and 7.4 earlier. The PHP project published minimal source-code backports for 7.4, 8.0 and 8.1, but no official releases or downloads. Some Linux distributions and paid long-term support vendors ship their own fixes. PHP 8.2 itself reaches end of life on 31 December 2026.

If your site runs on PHP 8.1 or older and your host cannot confirm a backported fix, this is the moment to plan an upgrade to a supported version. For WordPress sites, our guide to WordPress PHP versions explains how to upgrade without breaking plugins.

Conclusion

As of 23 October 2026, PHP2Shell is a pair of critical flaws in the PHP engine with a fix already available. The steps are simple: confirm who runs your PHP, get a fixed build, restart PHP, use temporary settings or a maintenance page only if you cannot patch yet, and check your logs back to 17 October. Don't rely on the version number or a CMS update to tell you you're safe. If you need help, our emergency PHP patching team can work with your host or server. Every PHP2Shell guide is in our PHP2Shell Resource Center.

Frequently Asked Questions