PHP — the language running the majority of the world's websites, quietly, underneath WordPress, Drupal, Magento, and most custom-built web backends — shipped emergency security patches on 21 October after details of two critical flaws leaked two days ahead of their planned disclosure. The pair, tracked as CVE-2026-109618 and CVE-2026-109619 and nicknamed "PHP2Shell", both carry a CVSS v4.0 score of 9.2. Fixes landed at 14:00 UTC on 21 October in PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35. Cloudflare's CTO has already confirmed the company is seeing early attacks targeting the flaws, and the UK's National Cyber Security Centre has urged organisations to patch immediately or take affected systems offline.
Both flaws let an attacker run code on a server with no login required. One is triggered when an out-of-memory condition interrupts PHP mid-request, leaving partially initialised data that gets treated as valid during cleanup; the other comes from stale state left over between requests. Either path can hand an attacker a working shell. What makes this one worth taking seriously even if you've never heard of PHP by name: it's usually invisible, bundled inside a CMS, a plugin, or a hosting stack a business owner has never directly touched — so the real question isn't "do we use PHP," it's "where, and in how many places."
What this means for your business
If your website, online store, or client portal runs on WordPress, Drupal, Magento, or a custom PHP application, treat this as a this-week task, not a someday one. Ask your host or developer two things: which PHP version the server is currently running, and whether it has been updated to 8.2.35, 8.3.36, 8.4.27, or 8.5.12 (or later). Reputable managed-WordPress and shared hosts generally apply PHP security updates automatically, but self-managed VPS or dedicated servers usually don't — those need someone to update them by hand.
If you're on PHP 8.1 or an older unsupported branch, there is no official fix for that version — the only real remediation is upgrading to a maintained PHP release, not just waiting for a patch. If updating this week genuinely isn't possible, PHP's own advisory lists a stopgap — disabling session.upload_progress in php.ini closes one of the two confirmed exploitation paths — but that's a delay tactic, not a fix. With attacks already starting, the safest assumption is that any internet-facing PHP server still unpatched after this week is a target, not a maybe.