In October, attackers manipulated refrigeration systems across hundreds of French supermarkets, disrupting cooling and destroying food. Weeks later, similar incidents spread across Europe, affecting major retailers including ICA, Coop, Ahold Delhaize, and Colruyt. At one ICA store in Stockholm, freezer temperatures reportedly reached 50°C. The damage did not require stolen customer data or a conventional IT outage. Manipulating an operational system was enough to create physical and financial consequences.
At almost the same time, another risk was surfacing deeper in the technology stack. Two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, nicknamed PHP2Shell, were rated 9.2 and could enable unauthenticated remote code execution. Patches were released on October 21, and CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog on October 26 after exploitation activity had already been observed.
The incidents appear different. One involved refrigeration controllers; the other, software underpinning web applications. But they expose the same governance problem: critical dependencies can become invisible precisely because organizations take them for granted. A controller managed outside traditional IT and a runtime buried beneath applications can both escape meaningful executive attention until something fails.
That is not simply a technology gap. It is an ownership gap. And when critical technology lacks clear ownership, visibility, and accountability, the resulting exposure belongs on the board’s agenda.
The Controller Nobody Put on the Risk Register
The French incidents exposed a familiar weakness hiding in an unfamiliar place: internet-connected refrigeration controllers. Authorities warned that management interfaces had been exposed to the public internet and urged organizations to remove that exposure, update firmware, replace default passwords, and secure end-of-life equipment.
Read that sequence as a governance failure, not merely a technical one. The vulnerability was not buried deep inside a sophisticated cyberattack. The systems were reachable, security weaknesses were known, and remedial action was available. Yet somewhere between the technology, the vendor, and the business, accountability broke down. The attacker did not necessarily need a zero-day. Exposure itself created the opportunity.
That is what makes these incidents consequential for boards. Operational technology can sit outside the systems traditionally associated with cyber risk, while still controlling processes with real-world consequences. When ownership, visibility, and remediation responsibilities are fragmented, a seemingly obscure device can become an enterprise exposure.
The detection problem is equally important. Traditional cybersecurity monitoring is designed primarily around digital indicators. But when a cyberattack manipulates a physical process, the first meaningful sign may be an operational anomaly rather than a conventional security alert. The governance question, therefore, is not simply whether an organization can detect an intrusion. It is whether it can recognize quickly enough when digital compromise becomes a physical consequence.
Patch Velocity Is a Decision Right, Not a Task
PHP2Shell exposed how quickly the window for defensive action is collapsing. Amazon Threat Intelligence identified an exploitation attempt on October 17, four days before the vulnerabilities were publicly disclosed, and observed additional activity as patches became available on October 21. Its conclusion was blunt: for critical vulnerabilities in internet-facing systems, remediation timelines increasingly need to be measured in hours, not conventional seven- or 30-day cycles.
But speed is not simply a patching problem. CERT-EU advised organizations that could not patch immediately to consider isolating vulnerable internet-facing applications until fixes were applied and verified. That turns a technical vulnerability into a business decision. Taking a customer-facing or revenue-generating system offline carries consequences, but leaving it exposed carries consequences too.
Someone therefore needs the authority to make that tradeoff before the crisis begins. If decision rights are unclear at 2 a.m., the organization may lose valuable time deciding who can accept disruption, isolate a system, or tolerate continued exposure. The board-level question is not simply how fast the security team can patch. It is whether authority to act at speed has already been defined.
The urgency is likely to intensify. AI-assisted analysis is reducing the cost and time required to turn vulnerability disclosures into working exploits, while Radware notes that the underlying PHP2Shell flaws had existed in the codebase for more than a decade. When exploitation can move faster than traditional governance cycles, patch velocity becomes less about technical execution and more about whether the organization can make consequential decisions at machine speed.
Four Assumptions That Failed
Set side by side, the incidents challenge four assumptions that still shape enterprise cyber risk.
First, that the asset inventory captures what matters. Inventories are often strongest around technology procured and managed by IT, while operational controllers, building systems, embedded software, and vendor-managed technology can sit beyond the same governance discipline. An asset does not become less consequential because another function bought or operates it.
Second, that a vendor warning automatically produces action. It does not. An advisory has value only when it reaches someone who owns the exposure, has authority to remediate it, and can be held accountable for doing so. Third-party and distributed operating models make that chain of accountability even more important.
Third, end-of-life technology is primarily a budget problem. Once unsupported technology remains operational and exposed, deferred replacement becomes more than technical debt. It becomes an accepted risk, whether leadership has explicitly accepted it or not.
Fourth, that a cyber incident is defined solely by stolen data. It is not. For public companies subject to SEC requirements, Item 1.05 of Form 8-K is triggered by a cybersecurity incident determined to be material, with companies expected to consider qualitative as well as quantitative impacts. Once that determination is made, disclosure is generally required within four business days. A cyberattack that materially disrupts physical operations can therefore belong in the same governance conversation as one that compromises information.
Together, these failures point to a broader lesson: cyber risk is no longer bounded by what IT owns, what vendors patch, or what attackers steal. It is bounded by what the enterprise depends on and whether someone is accountable for protecting it.
Questions Directors Should Ask
Directors do not need to understand the mechanics of every connected system. They need evidence that the organization knows what it exposes, who owns the resulting risk, and how quickly it can act when that exposure becomes a threat.
The questions should be direct: What internet-facing systems do we operate, including operational technology and contractor-managed assets, and who owns each one? Where are we still relying on default credentials or unsupported technology? How do vendor warnings reach accountable owners, including third parties? Who has the authority to isolate or shut down a critical system during an attack, and has that authority been tested? And how quickly would we know if a cyberattack had crossed from manipulating data to manipulating a physical process?
For boards, identifying the attacker may matter, but it does not eliminate the underlying exposure. The more consequential governance question is whether the vulnerability existed before the attacker arrived, who was responsible for it, and whether it will still be there when the next attacker comes looking.
Resilience Is Knowing What You Expose
The deeper lesson is not simply that attacks are becoming more sophisticated. It is that significant disruption can begin with ordinary technology whose exposure, ownership, or lifecycle has escaped meaningful scrutiny. When that happens, the weakness is not only technical. It is organizational.
The enterprises best positioned for the next incident will be those that can answer three questions without hesitation: What do we expose? Who owns it? Who has the authority to take it offline? Those questions turn cybersecurity from a catalogue of technical controls into a discipline of accountability.
For boards, that is the dividing line between resilience and response. Ask those questions before the incident, and you are governing resilience. Ask them after the headline, and you are governing the consequences.
Know What You Expose Before an Attacker Does
Operational technology, third-party systems and software runtimes now carry the same business risk as the core network, often with far less oversight. Karysburg helps boards, risk committees and assurance leaders map internet-exposed assets to named owners, set decision rights for taking systems offline, and build the evidence that holds up under regulatory scrutiny.
Schedule an Exposure and Operational Resilience Assessment to find out what your enterprise exposes, and who is accountable for it.