The U.S. National Security Agency doesn't often tell organizations to pull systems off the network. This week, it did.
In a brief advisory issued October 21, the NSA warned every organization running PHP to prepare for an update addressing two critical vulnerabilities, noting that the flaws often give attackers a direct path to a server's file system or database. The agency's fallback guidance was blunt: if an immediate update isn't feasible, take the system offline until it can be fully mitigated. NSA said more specific guidance would follow.
The flaws, collectively dubbed PHP2Shell, sit not in WordPress, Drupal, or any framework, but in the PHP engine itself. That distinction is what turns a routine patch cycle into what one researcher calls "a genuine drop-everything moment."
On an October 22nd call with members of the SecureWorld Twin Cities Advisory Council (security leaders who help plan the November 19 conference in Minneapolis), colleagues exchanged how their organizations were handling yesterday's incidents. Most had resolved all issues by the end of the day.
PHP has shipped fixes for both vulnerabilities, each rated 9.2 (critical) under CVSS v4.0.
CVE-2026-109618 – Out-of-memory (OOM) corruption. According to the Qualys Threat Research Unit (TRU), when an out-of-memory error interrupts certain operations, PHP leaves request data half-initialized, and the cleanup routines that process that broken state open a path to remote code execution.
CVE-2026-109619 – Stale global state. Here, PHP keeps references to request data after the underlying memory has been freed. A subsequent request handled by the same worker touches those stale references before they're reset, producing a use-after-free that researchers have turned into remote code execution (RCE).
For both, unauthenticated RCE was confirmed on Apache with mod_php, where Qualys notes the demonstrated exploit can fire before any application code runs. But mod_php isn't the only concern. PHP has also validated code execution against PHP-FPM under the right application conditions, and lists php-cgi, FrankenPHP, and LiteSpeed deployments serving web requests as at risk.
Patched releases are PHP 8.5.12, 8.4.27, 8.3.36, and 8.2.35, with minimal source backports for the end-of-life 7.4, 8.0, and 8.1 branches. PHP's own release notes are unambiguous: there are no complete mitigations, and updating is the only safe option.
This was never a quiet, embargoed patch. Proof-of-concept exploits began circulating before fixes arrived, and Qualys reports that active exploitation attempts are now being observed in the wild. Amazon Threat Intelligence and Cloudflare have both reported attack activity, Cloudflare has seen attempts to evade its protections, and Patchstack has received exploitation reports from hosting partners.
The bigger danger may not be code execution at all. Researchers have also demonstrated unauthenticated reads of PHP worker memory, which can expose passwords, authentication tokens, and API keys belonging to other users. No shell required, no malware to detect.
It also lands on an already crowded target. Late last year, Qualys TRU documented a sharp increase in attacks against PHP servers, IoT devices, and cloud gateways, driven largely by botnets such as Mirai, Gafgyt, and Mozi. That research pegged PHP as the language behind more than 73% of websites, an attack surface that automated exploit tooling is built to sweep.
Part of the confusion this week stems from how PHP2Shell went public. Ben Ronallo, Principal Cybersecurity Engineer at Black Duck, a provider of application security solutions, walked through the sequence.
"Word of the vulnerabilities leaked on Y Combinator's Hacker News forum two days before the planned disclosure, and PHP moved its security release up a day in response," Ronallo said. "The source of the leak hasn't been identified, but there's no evidence a threat group was involved, and no exploit code was released. A screenshot of the researchers' exploit tool did circulate, which added to the alarm."
Ronallo noted the early reports were "largely accurate," with one key difference: "PHP officially rates both flaws 9.2 rather than the 10.0 some reports cited. That's still critical, and it doesn't change the advice."
His colleague Tim Mackey, Head of Software Supply Chain Risk Strategy at Black Duck, warned that a broken embargo creates its own secondary attack surface.
"When a leak, or advance knowledge, of a vulnerability occurs the entire ecosystem surrounding the vulnerability is placed at risk," Mackey said. "As details of the leak are published, security defenders are faced with the real risk that malicious actors could use the absence of an official patch to supply their own malicious patches."
His advice: "Defenders should pay extra attention to the origin of their patches and validate functional changes against official release notes. After all, a malicious patch could implant a backdoor for future use, and a rush to patch might present the right opportunity for malicious actors."
The most common mistake security leaders are flagging is treating PHP2Shell like another CMS bug.
"This isn't a WordPress or Drupal bug," said Loris Degioanni, Founder and CTO at Sysdig, a real-time cloud security provider. "It's a flaw in the PHP engine itself, and therefore every PHP application is exposed, including the vendor portals, admin consoles, and forgotten marketing sites that most companies don't even have in their inventory."
Degioanni also pointed to how long the underlying weakness lingered: "This flaw is more than 20 years old and was flagged repeatedly but left alone because nobody could prove it was exploitable. AI has made that kind of 'theoretical' bug cheap to weaponize, which means exploits will be adapted to new versions and configurations faster than most organizations can patch.... Nobody should assume their patch cycle will outpace attackers."
Jason Soroko, Senior Fellow at Sectigo, a provider of certificate lifecycle management, laid out a concrete order of operations: update PHP on every web server, then restart Apache, PHP-FPM, and any other PHP processes "so the old version stops running." Start with internet-facing mod_php servers, then move to PHP-FPM, "because researchers reached code execution there too."
Soroko also cautioned against leaning on stopgaps. "Firewall rules and configuration changes reduce exposure but do not fix the flaws," he said, adding that a workaround setting shared before the patch "blocks some attacks on one flaw and none on the other." And he flagged a verification trap: "Look for CVE-2026-109618 and CVE-2026-109619 in the update notes, because Linux vendors can ship the fix under a version number that looks old." Qualys echoes that point, warning that distribution backports may keep an older upstream version number.
John Gallagher, Vice President at Viakoo, a provider of automated OT and IoT cyber hygiene, argued that headlines focused on websites are missing the larger exposure. "PHP is deeply embedded and used in a wide range of systems like operational technology and IoT (think building management systems or industrial gateways)," he said. "For websites, the patches are already flowing, but for where PHP is embedded, it will take system manufacturers time to develop and test patches. The 'window of vulnerability' for this could be several months."
Gallagher called it "an enterprise-wide threat that goes way beyond IT," warning that "the much bigger threat to organizations is cyber criminals taking control of OT/IoT systems and using that position to move laterally within an organization and extend the reach of control."
Ronallo shared the inventory concern. "The organizations I'm most concerned about are the ones that don't know where PHP is running in their environment," he said. "Older versions sitting in containers, appliances, or legacy sites won't receive an official fix. Nobody wants to be building a software inventory in the middle of an emergency."
Because the memory-disclosure path requires no code execution, several experts stressed that a clean patch and a clean malware scan prove nothing about credential exposure.
"Engine-level flaws allow unauthenticated memory reads," said Dana Simberkoff, Chief Risk, Privacy, and Information Security Officer at AvePoint, a provider of data security, governance, and resilience solutions. "Active API keys and credentials can be compromised before a patch is even deployed, meaning simply updating software binaries isn't enough to contain the risk."
Degioanni was more direct: "Any credentials held by exposed servers should be rotated now." Because the attack runs underneath the application, he noted, application logs and traditional vulnerability scanners won't catch it. Servers need runtime monitoring for "unexpected processes spawned by PHP, bursts of memory errors and crashes, or a web server suddenly reaching out to the internet."
Soroko recommended not waiting for proof of compromise: replace the passwords, keys, and certificates internet-facing PHP servers could reach, log out active sessions, and prioritize servers whose logs since October 20 show "repeated HTTP 500 errors, memory-limit errors, oversized session cookies or unexplained PHP restarts."
The NSA's offline recommendation is easy to write and hard to execute. Nick McKenzie, CISO at Bugcrowd, a crowdsourced cybersecurity firm, described the tension it created inside organizations running legacy, end-of-life PHP builds where official patches weren't available.
"If businesses didn't have certain compensating controls like WAF on hand," McKenzie said, "security leaders faced an agonizing race against the patching clock. They had to advocate for taking core applications offline, risking the disruption of business-critical workflows, directly pitting cyber risk mitigation against the CIO's uptime and platform resiliency mandates."
Soroko framed it the same way: the decision to take a server offline "belongs to business leaders as well as IT," citing BambooHR's precautionary shutdown and its warning that payroll would be interrupted.
For Simberkoff, that's the real test. "For CISOs, managing core infrastructure risks is ultimately a test of operational speed," she said, pointing to automated policy enforcement that lets organizations "immediately restrict access, rotate exposed credentials, and protect critical data" while IT remediates.
Drawing on recommendations from the NSA, PHP, Qualys TRU, and the experts above, here are the mitigations IT leaders should take now.
Find every PHP instance. Include containers, appliances, hosting panels, embedded OT/IoT systems, and parallel PHP branches. Qualys warns that the version php -v returns may not be the runtime actually serving web requests.
Patch the engine, not just the app. Move to 8.5.12, 8.4.27, 8.3.36, or 8.2.35, or apply vendor backports for 7.4–8.1. Confirm the CVE IDs appear in distribution release notes.
Restart and verify. Restart or redeploy every PHP worker, rebuild container images, and confirm nothing is still running the old build.
Validate patch provenance. Pull fixes only from official PHP or vendor channels and check changes against release notes.
Treat mitigations as temporary. Settings like disabling session.upload_progress narrow specific paths; they don't make an unpatched server safe.
Rotate credentials and kill sessions on any internet-facing PHP server, regardless of whether you've found evidence of compromise.
Watch at runtime for anomalous PHP child processes, memory-error bursts, crashes, and unexpected outbound connections.
Escalate the offline decision. If a system can't be patched, follow NSA's guidance and bring business owners into the call now, not after an incident.
PHP2Shell is a reminder that the most dangerous vulnerabilities are often the ones beneath the layer everyone is watching. The patch is out. The question for most organizations is whether they know everywhere it needs to go.