On Wednesday, October 21, Dutch government services disappeared from the web. Citizens could not reach DigiD, which they use to access public services, or MijnOverheid, the portal for official government information. The Netherlands’ National Cyber Security Centre temporarily took its own website offline, too.

It was not a nationwide internet failure. Nor did those shutdowns establish that the sites had been hacked. Officials deliberately interrupted public services because they judged that remaining online presented an unacceptable risk.

The cause was PHP2Shell: two critical vulnerabilities in PHP, the software running beneath a substantial portion of the world's websites. An attacker could potentially make an affected server execute malicious commands without needing to log in. For organizations that could not update immediately, security agencies advised taking exposed services offline.

Picture that decision in a company. The CISO recommends shutting down a revenue-generating service. The sales team objects. The operations team worries about customers. Legal asks whether any data has been compromised. The CEO needs an answer before the facts are complete. Who decides, and on what evidence?

That is why PHP2Shell belongs in the boardroom. The failure began deep in a software engine, but the choices it created involved business continuity, risk appetite, public trust and management accountability.

What is PHP2Shell, and why is it so serious?

PHP2Shell refers to CVE-2026-109618 and CVE-2026-109619, two vulnerabilities rated 9.2 out of 10 on the current industry severity scale. Both involve parts of PHP that almost every web request touches: handling memory and recovering from errors. Under certain conditions, the weaknesses allow remote code execution. In plain English, an outsider may be able to make a web server run their code, then use whatever permissions that server already has.

That could expose application files, databases and credentials to other systems. The risk is especially serious for some Apache mod_php configurations, where researchers demonstrated a path to compromise before application code even runs. Other PHP deployments are also affected, although the conditions and evidence for exploitation vary.

The scale is easy to underestimate. On October 21, W3Techs reported that PHP was used by 69.3% of websites whose server-side programming language could be identified. That is not the percentage of sites proven vulnerable. It shows how much of the web relies on the same underlying technology.

Censys observed about 2.58 million internet-facing hosts running PHP and more than 54 million web properties associated with them. Of approximately 1.58 million hosts reporting a PHP version, about 1.576 million reported one older than the new security releases. Another 1.15 million reported a branch no longer officially supported by the PHP project. These numbers represent potential exposure, not confirmed compromise. Some vendors install backported fixes without changing the reported version, and server configuration affects exploitability.

Even allowing for those limits, consider the practical task. Millions of systems, run by different companies, governments, hosting providers and software vendors, suddenly needed to be checked. Some organizations did not even know whether PHP was buried inside a product they relied on.

The uncomfortable fact: the first warning signs appeared in 2024

In its October 21 account, the PHP Foundation disclosed that a developer had identified signs of the memory-management problem in 2024, while following up on an external security audit. At that point, the team had not found a practical route to taking over a server. The options for fixing it carried serious trade-offs, including performance problems, new vulnerabilities, backward-compatibility breaks or changes across PHP's large extension ecosystem.

A small group of specialized maintainers debated those choices, but the work repeatedly stalled. The Foundation has since described what happened as a “structural failure,” caused by its decision process and insufficient resources. It has begun changing those processes and investing in a larger security team.

In August 2026, security researchers helped demonstrate the danger much more concretely. Calif and OpenAI independently reported attack paths related to the earlier issue, followed by additional research from Wiz and others. AI-assisted analysis was part of that work. What had been a difficult technical concern became an urgent, demonstrated vulnerability.

There is no contradiction in celebrating better security research while questioning why an earlier concern could not be resolved. The people maintaining PHP faced genuinely difficult engineering problems. They also acknowledged organizational weaknesses. Both facts matter.

Advanced AI tools can help researchers find old flaws faster. They cannot decide which repair is safe for millions of users, employ the engineers who understand the code, or allocate enough money to carry the work through. Those remain human and institutional responsibilities.

What changed today?

As the coordinated disclosure approached, details circulated prematurely. PHP moved the patch release forward from October 22 to October 21. The early disclosures generated controversy among some of the researchers, maintainers and distributors involved, but the immediate priority for users was straightforward: update affected PHP installations.

The PHP project released four patched versions: PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The U.S. Cybersecurity and Infrastructure Security Agency, CISA, urged organizations to identify PHP throughout their environments and patch immediately, prioritizing internet-facing systems. It also advised taking systems offline when fixes could not be applied, particularly where organizations still relied on PHP 8.1 or earlier unsupported releases.

A web application firewall may provide some temporary protection, but it is not a substitute for updating. Organizations should also watch for suspicious PHP worker processes spawning shells or downloading tools, and check with vendors whose applications or appliances may bundle PHP.

As of its October 21 advisory, CISA said it had not observed exploitation of these vulnerabilities. That is not a guarantee that no attacker had tried, or that exploitation could not occur later. Security teams need to distinguish internet scanning, attempted exploitation and confirmed intrusion when reporting to executives and directors.

The urgency does not require panic. It requires an accurate inventory, a defensible patching decision, and proof that the vulnerable system has been fixed or safely isolated.

What the other incidents tell us, and what they do not

PHP2Shell was the central emergency. Separate October 21 disclosures illustrate why the same organizations may face multiple problems at once. Node.js, another widely used software platform, released fixes for ten security issues, four rated high severity. LiteLLM disclosed a compromised software release that could steal credentials. Railway reported unauthorized access involving systems storing customer environment variables, which may contain passwords, database credentials and API keys.

These incidents were separate; there is no established evidence they were carried out by the same attackers. Railway said it believed the broader campaign was aimed at compromising AI inference providers, but that assessment was preliminary. It would be inaccurate to say investigators had proven that Railway was breached specifically to steal AI keys.

The concern about those keys is nevertheless real. An AI API key may authorize access to models and incur usage charges, making a stolen credential a path to both data exposure and potentially significant compute expense. Management should know where such keys are stored, limit their privileges and spending where the provider allows it, use separate identities for important applications or agents, rotate keys when exposure is suspected, and monitor unusual usage. A weekly blanket rotation is no substitute for short-lived credentials, sound access controls and a reliable emergency revocation process.

The connection to PHP is direct: a compromised web server can expose the credentials stored in its configuration. Patching the server protects one layer. Understanding what that server can access protects the rest of the business.

What directors should ask management now

Boards should not turn this into an impromptu seminar on programming languages. The responsibility of directors is to ensure that management can identify critical exposure, decide quickly, preserve essential services where feasible and demonstrate that an effective remedy has been applied.

A standard report that 95% of vulnerabilities were fixed on time can be deeply misleading if the remaining 5% includes the system through which customers place orders or the credentials through which an AI agent can reach sensitive data. Boards need exposure and business impact, not an average that obscures the critical exception.

1. Require an immediate PHP exposure and remediation report. The CISO and CIO should identify where PHP runs, including within vendor products, hosted platforms and unsupported versions. For each material exposure, ask for the affected service, responsible owner, patch or isolation status, supporting evidence, and any indication of intrusion.

2. Confirm the patching and containment decision. Management should verify deployment of PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 as appropriate, or a vendor-supported fix with evidence of backported protection. If a system cannot be secured, directors should know the business consequences of isolating it and who is authorized to make that decision.

3. Check what a compromised PHP server could reach. Review access to databases, customer records, cloud accounts and AI model credentials. Confirm that sensitive keys have limited permissions, can be revoked quickly, and are monitored for unusual activity or spending. Prioritize rotation where compromise or exposure is suspected.

4. Test a shutdown-and-recovery scenario. Have management demonstrate what happens when an essential service must be taken offline, including customer communications, manual alternatives, restoration criteria and independent verification before the service returns.

5. Measure the time from warning to verified protection. Track when management first learned about the risk, identified affected systems, authorized action, installed the fix or isolated the service, and verified the result. Present material exceptions to the Audit or Risk Committee with a named owner and an agreed deadline.

The decision boards cannot defer

The headline on October 21 was PHP2Shell. Two vulnerabilities in a widely used programming language were serious enough that public institutions chose to interrupt services rather than remain exposed.

The lesson is not that boards should personally manage software updates. It is that directors need evidence that their organization knows which systems matter, understands what they depend on, and can make difficult decisions before an emergency becomes a larger crisis.

The next dangerous flaw may emerge from a software library nobody on the board has heard of. Management cannot promise to prevent every discovery. It can be expected to know where the company is exposed, who has authority to act, and what evidence is required before systems are declared safe.

If the board cannot get those answers today, it should not assume they will appear when the next warning arrives.