On October 21, 2026, the PHP project patched two critical remote-code-execution vulnerabilities, together called php2shell, that affect nearly every system running PHP to serve web traffic, including sites built on WordPress, Drupal, and Magento, as well as many custom portals. Technical details of the vulnerability leaked before the fix was released, so the window between disclosure and active exploitation was short. Patching is available and inexpensive. The cost of waiting for exposed companies is not only a possible breach, but also the legal and contractual exposure that the delay itself creates—especially for heavily regulated entities, such as U.S. government contractors that handle Controlled Unclassified Information (CUI).
The vulnerabilities expose servers, data, and credentials.
According to the U.S. Cybersecurity and Infrastructure Security Agency (CISA), the flaws allow attackers to run code remotely on any PHP installation that serves web requests, without a password or account. These flaws can let an attacker run code on the server, crash it, or read data left in memory from other users’ requests, including passwords, tokens, and API keys. Updating PHP, and restarting affected systems, is the only complete remedy. Versions 8.1 and older will receive no official update and must be upgraded to a supported version.
The exploitation window is measured in hours, not weeks.
In the most common server configuration, malicious code runs before your application’s own defenses engage. Public exploit tooling appears for vulnerabilities like this typically within days; scanning and probing are already underway. Any unpatched, internet-facing system should be treated as a likely target right now.
Waiting turns a technical issue into a compliance problem and liability issue.
If your company handles CUI, federal rules require patching known flaws on covered systems. A publicly known, government-flagged, actively exploited vulnerability left unpatched can undercut your earlier compliance representations and put you in breach of your government contract—and potentially create False Claims Act exposure (e.g., under the Department of Justice’s Civil Cyber-Fraud Initiative) that attaches to the delay, with or without a breach.
If a system is compromised, regulatory reporting clocks start immediately.
A breach involving defense information can trigger a 72-hour reporting obligation to the U.S. Department of Defense. Systems with government authorizations face accelerated remediation deadlines. Public companies in the U.S. owe a disclosure to the U.S. Securities and Exchange Commission within four business days if they determine an incident to be material. Companies that provide affected hardware or software products in the European Union (EU) may face a 24-hour reporting deadline under the EU Cyber Resilience Act, with follow-up reports to the EU’s cybersecurity agency (ENISA) within 72 hours and after one month.
The costs reach well beyond IT.
A live or suspected incident during a financing or acquisition can delay or reprice the deal and break cybersecurity representations. Many cyber-insurance policies also exclude losses tied to a known critical vulnerability left unpatched despite an available fix. Delay can quietly void the expected coverage.
The bottom line.
The longer an exposed system stays unpatched, the harder it becomes to show diligence, demonstrate reasonable security, and comply with legal and contractual deadlines. A company that is on notice and does nothing risks liability beyond the breach itself.
Key actions to take
For questions about this alert, please contact Wilson Sonsini’s Defense Tech, Government Contracts, or Data, Privacy, and Cybersecurity attorneys.