PHP2Shell Vulnerability Explained: How a PHP Bug Threatens Servers

WarBrief Live | October 24, 2026 | Cybersecurity

9.2 CVSS v4.0 score for each flaw

2 Critical PHP vulnerabilities

4 Fixed releases published

October 21, 2026 Date the fixes shipped

PHP2Shell vulnerability explained in plain terms: it is the name given to two critical flaws in the PHP programming language itself, not in a single website, plugin or content management system. Both flaws can allow an attacker who has no login to run code on a web server, and both were fixed on October 21, 2026, in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. What investigators have confirmed is the existence of the flaws and the fixed versions; what remains unverified is how widely attackers have successfully exploited them, as opposed to merely probing for them.

What is PHP2Shell?

PHP is a server-side scripting language that powers a large share of the web, including WordPress, Drupal, Joomla, WooCommerce and many online shops, news sites, government portals and customer systems. PHP2Shell is not a product, a hacking group or a single exploit file. It is a nickname for a pair of vulnerabilities in the way PHP itself sets up and cleans up each web request.

The first flaw, CVE-2026-109618, is described by PHP as remote code execution via out-of-memory corruption. In simple terms, if PHP runs out of memory while it is still building its internal data for a request, that data can be left half-finished. When PHP then cleans up at the end of the request, it may treat the broken data as valid, and that confusion can be steered toward running attacker code.

The second flaw, CVE-2026-109619, is described by PHP as remote code execution via stale global state. Internal state belonging to one request can survive after the memory behind it has been freed. A later request handled by the same worker may then use that stale state before it is reset, a type of bug known as use-after-free. The Dutch National Cyber Security Centre (NCSC-NL) tracks operational information on both flaws in a public repository, and its summary matches the PHP advisory on the fixed releases and the affected setups.

Both flaws are memory-safety bugs, not mistakes in a website’s own code. That distinction is the whole story. A site can have strong passwords, two-factor login and fully updated plugins, and still be exposed, because the vulnerable code runs while PHP is still reading the incoming request, before the site’s own security logic gets a chance to intervene.

What happened when the PHP2Shell details leaked?

PHP had planned a coordinated disclosure for October 22, 2026. Instead, details leaked on October 20, and the project brought the fixes forward to October 21. The leak matters because it shortened the window between attackers learning about the flaws and defenders receiving a patch.

Several security firms reported early probing before the patch landed. Cloudflare reported early attack attempts before the fixes shipped, and Amazon’s threat-intelligence team reported an exploitation attempt against its honeypots on October 17, 2026, while the flaws were still under embargo. Those reports describe attempts and probing. They do not, on their own, prove successful compromise of real websites.

The US Cybersecurity and Infrastructure Security Agency (CISA) took a careful line in its alert of October 21, 2026: it said it had not observed successful exploitation in the wild as of the time of publication, while still urging organisations to patch immediately, starting with internet-facing systems. CISA updated the alert on October 23, 2026, adding a detection rule and partner resources. Readers should therefore treat “attempts seen” and “successful exploitation confirmed” as two different claims. The first is widely reported; the second has not been confirmed by CISA.

Background and timeline

Researchers traced the vulnerable code back a long way. Secondary technical summaries report that the affected code paths go back to PHP 5.4.0, released in 2012, which is why the exposure is so broad: the same request-handling code has been carried forward through many PHP branches. That history also explains why the fix had to land in PHP itself, branch by branch, rather than in any one application.

• October 17, 2026: Amazon honeypots record a reported exploitation attempt, four days before the patch, according to Amazon threat-intelligence reporting summarised by security press.
• October 20, 2026: Details of the flaws leak online, ahead of the planned October 22 coordinated disclosure.
• October 21, 2026: PHP publishes emergency releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, and CISA issues its alert urging immediate patching.
• October 22, 2026: European authorities, including CERT-EU in a joint statement with the European Commission, ENISA, Europol and national response teams, urge immediate action and isolation of systems that cannot be patched.
• October 23, 2026: CISA updates its alert with a detection rule, and the Dutch NCSC-NL repository records its latest software-status update.
• October 24, 2026: Patching continues, with hosts, distributions and vendors still rolling out updated packages for their own PHP builds.

Which PHP versions are affected, and which versions fix PHP2Shell?

PHP says all PHP installations serving web requests are at risk, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. It considers the risk highest for Apache with mod_php, where it has a demonstrated exploit in which an unauthenticated request can trigger the attack before any application code runs. Using a different setup is not a reason to skip the update.

The fixed releases are tied to the branch a server already runs. A server on PHP 8.2 needs 8.2.35, a server on 8.3 needs 8.3.36, a server on 8.4 needs 8.4.27, and a server on 8.5 needs 8.5.12. There is no separate hotfix file. The fix arrives inside the new point release for each supported branch, or inside a vendor’s updated package for that branch.

PHP 8.1 and older are a different problem. The PHP project no longer provides regular updates for those branches. It did publish minimal source backports for PHP 7.4, 8.0 and 8.1, aimed mainly at people who build PHP from source, and some Linux distributions and long-term-support vendors ship their own patched packages for end-of-life streams. PHP 7.3 and older get nothing from the project. For those systems, the honest options are a supported upgrade, a confirmed vendor backport, or taking the system offline until one of those is possible, which is exactly what CISA advises for systems that cannot be updated.

By the numbers: PHP2Shell at a glance

Metric	Figure	Source
CVSS v4.0 score, CVE-2026-109618	9.2 (Critical) — CONFIRMED	PHP security advisory; CISA alert
CVSS v4.0 score, CVE-2026-109619	9.2 (Critical) — CONFIRMED	PHP security advisory; CISA alert
Fixed releases published October 21, 2026	8.2.35, 8.3.36, 8.4.27, 8.5.12 — CONFIRMED	PHP security advisory
Earliest reported exploitation attempt	October 17, 2026 — REPORTED (attempt, not confirmed success)	Amazon threat-intelligence reporting
Successful exploitation observed in the wild	Not observed by CISA as of its October 21 alert — CONFIRMED as CISA’s stated position	CISA alert

Caveat: figures marked CONFIRMED appear in two or more of the primary sources listed below. Figures marked REPORTED come from a single reporting chain and describe attempts or probing, not confirmed compromise.

How do I check my site’s PHP version?

For a WordPress site, the quickest check needs no code. In the WordPress dashboard, go to Tools, then Site Health, then Info, then Server, where the PHP version is listed. That tells you the version the web server is actually running, which is the version that matters, not the version on a developer’s laptop.

On a hosting account, look for the PHP version selector in the control panel. Hosts present this differently: cPanel and similar panels have a PHP version or PHP selector screen, and some hosts use their own panel. If the panel shows a version below the fixed release for its branch, or a branch at 8.1 or older with no vendor patch note, contact the host and ask for the patched release or a supported upgrade path.

On a server you manage yourself, run php -v from the command line and compare the branch and release against the fixed list above. Then confirm the web server, not just the command line, is using the fixed build, because the command-line PHP and the web PHP can differ. After updating, restart every PHP worker: PHP-FPM pools, Apache, or the relevant application server. A web-server reload alone can leave old workers running, which means the old, vulnerable code is still serving requests.

One trap deserves emphasis. Distribution and vendor packages may backport a fix without matching the upstream version number. In that case, the version string alone does not prove safety. Ask the vendor or host to confirm the package’s security status, and check the package changelog, rather than assuming a lower number means unpatched or a matching number means patched.

What to do if you cannot update today

PHP is blunt on this point: only the update is a complete solution. The measures it lists for systems that cannot update immediately reduce exposure to specific attack paths, but do not make an installation safe. Disabling the session upload-progress feature, for example, helps only one confirmed path, and a web application firewall can buy time, but attackers can vary their payloads and a firewall helps only if the origin server cannot be reached directly.

For a system that cannot be patched promptly, the authorities’ advice converges on the same steps: inventory every PHP installation, including PHP embedded in appliances, management interfaces and third-party products where the dependency is not obvious; prioritise internet-facing systems; isolate or take offline what cannot be fixed; and hunt for signs of compromise, including PHP worker processes launching shells or downloading tools, before bringing a system back. A patch applied without a restart, or a restart that misses a worker pool, is not a completed patch.

Site owners should also check for compromise back to the leak window. Security guidance published since October 21 recommends looking for unexpected files, new administrator accounts, unfamiliar scheduled tasks and outbound connections from PHP workers, and treating any system that was internet-facing and unpatched between October 17 and its patch date as suspect until checked. That is a precaution, not a claim that every such system was breached.

Why PHP2Shell matters beyond one patch cycle

PHP2Shell matters for three reasons that go beyond the two CVEs. First, the flaw sits in shared infrastructure. When a language runtime breaks, every application built on it breaks at once, and the usual advice to “update your plugins” gives a false sense of safety. Second, the leak-before-patch sequence compressed the defence window. Attackers had details before defenders had fixes, which is why authorities urged patching within hours rather than at the next maintenance window.

Third, PHP is often invisible. Many organisations know their website runs WordPress, but not that a network appliance, a booking system, an intranet tool or a vendor product also embeds PHP. The European joint statement made that point explicitly: products may be vulnerable even when PHP runs behind the scenes and is not obvious. Inventory, not just patching the main website, is therefore part of the fix. Readers who follow the WarBrief intelligence hub will find the same lesson in other recent cases: the Palo Alto GlobalProtect flaw showed how a single product vulnerability can be exploited at scale, and our guide to how cybercrime takedowns work explains why patching and law-enforcement action have to move together.

What PHP2Shell means for US/UK/EU readers

For readers in the United States, the United Kingdom and the European Union, the practical effects are likely to be indirect but visible. Some websites, online shops and public services may go offline briefly while they patch, or stay offline longer if they run an unsupported PHP branch. SecurityWeek, summarising Reuters reporting, noted that several government, school and hospital websites in Europe were taken down on October 21, 2026, as a precaution. A short outage is a sign that a provider is taking the warning seriously, not necessarily a sign of a breach.

Shoppers and users should be wary of follow-on scams. Emergency patches are a classic pretext for phishing messages claiming a site needs urgent verification or payment details. A genuine host will not ask for passwords or card details to apply a PHP update, and a patch is applied server-side, not by clicking a link in an email. For businesses, the cost of a rushed patch is usually far lower than the cost of a compromised server, which can mean stolen customer data, a defaced site, a server conscripted into further attacks, or a long rebuild from clean backups.

The wider question for policymakers is how to handle widely used open-source infrastructure when a critical flaw leaks before a fix. Germany’s Federal Office for Information Security rated the situation at its orange level, meaning act without delay, and the UK’s National Cyber Security Centre urged organisations to hunt for backdoors that attackers may have planted before patches arrived. Those are unusually strong signals, and they explain why this story stayed at the top of security news for days after the fix shipped.

Different perspectives on PHP2Shell

Security vendors, authorities and researchers agree on the core facts, the fixed versions and the need to patch, but they differ in emphasis. Vendors that sell detection and firewall products stress monitoring and blocking, which is useful but incomplete on its own. Authorities stress inventory, patching and, where patching is impossible, isolation or taking systems offline. Researchers stress the technical mechanism and the long history of the code, including the role of AI-assisted discovery reported by some teams, which raises a separate debate about whether AI tools are accelerating both discovery and exploitation.

There is also honest disagreement about exploitation. Some firms report active attempts and expect successful exploitation against poorly protected sites. CISA, as of its alert, had not observed successful exploitation. Both can be true at once: attempts can be widespread while confirmed compromises remain unreported or undetected, especially in the first days after disclosure. The responsible reading is to patch as if exploitation were already happening, without claiming a scale of compromise that the evidence does not yet support. Readers interested in how AI is changing attack speed can also read our explainer on AI cyber warfare and whether artificial intelligence makes attacks faster and more dangerous.

What to watch next for PHP2Shell

Watch for four developments. First, vendor and distribution package updates: hosts that lagged on October 21 should now have patched builds, and any host still unable to name a fixed release deserves a direct question. Second, confirmed compromise reports: if security firms or authorities publish verified cases, the advice for unpatched systems that were exposed during the leak window will harden further. Third, follow-on advisories: PHP published a separate session-related advisory on October 23, according to technical summaries, so the October 21 fix should not be treated as the last word on PHP security that week. Fourth, long-tail patching: embedded PHP in appliances and vendor products often updates slowest, and those systems are the most likely to remain exposed months from now.

For site owners, the checklist is short and unforgiving: confirm the web PHP version, update to the fixed release for the branch, restart every worker, verify the running version again, and check logs and files for signs of compromise. Then repeat the inventory for every other PHP system the organisation runs, not just the main website.

Frequently asked questions

What is PHP2Shell?
PHP2Shell is the nickname for two critical vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619, each rated 9.2 under CVSS v4.0. Both can allow unauthenticated remote code execution on a PHP server, because the flaws sit in PHP’s request handling, before a website’s own code runs.

Which PHP versions fix PHP2Shell?
PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35, all published on October 21, 2026. Match the fixed release to the branch you run, restart every PHP worker after updating, and confirm the running version afterwards. PHP 8.1 and older need a supported upgrade or a confirmed vendor backport.

Is my WordPress site affected by PHP2Shell?
If it runs on an unpatched PHP version, yes. The flaw is in PHP, not in WordPress, so updating WordPress, themes or plugins does not fix it. Check the PHP version under Tools, Site Health, Info, Server in WordPress, and ask your host to confirm the patched release if the version is below the fixed release for its branch.

Has PHP2Shell been exploited in the wild?
Exploitation attempts and probing have been reported, including a reported attempt against Amazon honeypots on October 17, 2026, and early attempts reported by Cloudflare before the patch. CISA said it had not observed successful exploitation as of its October 21 alert. Attempts and confirmed compromise are different claims, and readers should not confuse them.

What should I do if I cannot update PHP immediately?
Prioritise internet-facing systems, inventory all PHP installations including embedded copies, apply only the partial measures listed in the official PHP advisory, and consider isolating or taking unpatchable systems offline until they can be fixed. Partial measures do not replace the update, and every PHP worker must be restarted after any change.

Sources

• PHP: News Archive 2026 — Security advisory: Critical remote code execution vulnerabilities, update now
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• NCSC-NL: Operational information regarding the 2026 php2shell vulnerabilities
• SecurityWeek: Tech and Security Companies Respond to PHP2Shell Vulnerabilities
• Expel: Php2Shell: Two critical PHP flaws disclosed