PHP2Shell: the financial value of cyber resilience

What happened

On 21 October 2026, the PHP project released fixes for two critical vulnerabilities in PHP, the programming language behind about 69% of websites whose server-side language is known. Either flaw could allow an attacker to run code on an affected web server without logging in, and news of the flaws leaked before the fixes were ready.

Rather than wait, many organisations switched their sites off. Government services went offline in several European countries, and in the Netherlands the Port of Rotterdam and a number of hospitals took their public sites down as a precaution.

Attackers moved quickly too. Amazon recorded an attempt to exploit the flaws on 17 October, four days before the fixes were published, and on 26 October the US Cybersecurity and Infrastructure Security Agency added both to its catalogue of vulnerabilities known to be exploited. As of 28 October 2026, no compromise of a named organisation has been publicly confirmed.

The cost of exposure, even without a breach

Taking a service offline is a decision that comes at a price. Revenue that would have run through a website or customer portal may be lost or delayed. Teams might drop other planned work to find every system running the vulnerable software, patch it, test it and bring it back. Customers might go elsewhere or call instead of relying on the digital channels. Service levels promised to clients may be missed.

None of this requires an attacker to succeed. It is the cost of being exposed, paid at the moment an organisation chooses to protect itself.

Given the prevalence of PHP across the internet, this vulnerability affected thousands of organisations in the same week. When so many businesses depend on the same underlying technology, a single flaw can create exposure across multiple industries and multiple countries, all at the same time.

For insurers and reinsurers, this is the often feared tale of accumulation risk: the potential for one event, or a series of connected events, to trigger claims across multiple insureds and lead to a large aggregate loss relative to capital, risk appetite and reinsurance protection. It also raises a practical question for cyber underwriters. Whether a policy responds to a business that switched itself off as a precaution depends on its wording, and PHP2Shell is a good test of how that wording reads.

Why resilience matters to the cost

Organisations with mature, well-funded security programmes were exposed to PHP2Shell on the same day as everyone else, because the flaw sat in a component they had every reason to trust. How much this vulnerability ultimately costs each organisation depends on how quickly they can find where PHP is running, how long their services stay down, how much revenue depends on those services, and how well they can keep operating in the meantime.

The cost therefore reflects both the business's dependence on the affected services and its ability to maintain or restore them. The second of these is essentially the organisation's cyber resilience: the ability to maintain critical services through disruption and restore them quickly where interruption cannot be avoided. An organisation that knows exactly where the affected software runs can patch sooner. One that can serve customers through another channel, or bring back a patched and tested system quickly, loses less while its site is down. Two organisations with the same exposure can face very different bills.

For exposures that arise through shared technology, security investment cannot stop the underlying vulnerability from existing. What it can do is reduce the likelihood of a successful attack, and the financial consequences when something does go wrong. Resilience works on the second of these, and applies to both cyber attacks and precautionary shutdowns. It is a financial decision, and it can be measured in financial terms.

Putting a value on resilience

The approach is the one already used for other risks that are managed in financial terms. Estimate the organisation's distribution of possible cyber losses as it stands today. Estimate it again with a proposed improvement in place. The difference shows how much the improvement reduces the expected annual loss, and how much it reduces the losses in a severe year.

The reduction in expected annual loss is the basis for judging the investment's financial return against its cost. The reduction in severe-year losses shows how much protection it offers against outcomes that could threaten liquidity, capital or the continuity of the business. The two measures complement each other, and they should not be added together.

Consider a hypothetical organisation with about R3 billion in annual revenue weighing two security investments, each costing about R1.7 million a year once implementation and running costs are spread over three years. Advanced threat detection helps stop an intrusion early and contain it. Backup, recovery and continuity help the business keep operating, and restore services, when disruption occurs. Before either investment, the organisation's estimated expected annual cyber loss is R8.9 million, and its 1-in-100-year loss is about R106 million. That is the annual loss it has an estimated 1% chance of exceeding in any given year, not a loss that happens once a century. More extreme outcomes remain possible, so this measure should be considered alongside stress scenarios.

On the average alone, the two investments are almost impossible to tell apart. Each reduces expected annual losses by approximately R1.20 per rand of annualised cost. In a severe year they are far apart. Better recovery and continuity cut the 1-in-100-year loss by about R35 million, more than twice as much as threat detection, because long outages drive this organisation's worst years, and a precautionary shutdown of the kind PHP2Shell prompted is one of them.

The example illustrates why resilience matters in an event like PHP2Shell. Detection and response can prevent an intrusion from escalating and limit its consequences. Continuity and recovery capabilities help sustain operations and restore services when disruption occurs. Their financial benefits overlap, but their relative value depends on the scenarios driving the organisation's losses.

These are estimates, with real uncertainty around them. A difference of R0.1 million in expected-loss reduction would rarely justify a confident ranking on its own, and a real decision should also weigh plausible ranges, how well each control is likely to be implemented and how each performs under different scenarios.

None of this makes detection a poor investment, or the right balance the same everywhere. The answer depends on the business, the systems involved, the controls already in place and the losses that would follow, and the reductions from separate investments cannot simply be added together.

Resilience is a financial decision

How much resilience to buy is a decision for the board, as it is for credit or market risk: how large a loss the organisation is prepared and able to carry in a bad year, and what it is worth paying to reduce it. That appetite should be revisited as threats, dependencies and the business itself change.

In the illustrative example, the recovery investment reduces the estimated 1-in-100-year loss from R106 million to R71 million. Whether that is sufficient depends on the organisation's financial capacity and risk appetite. A substantial reduction can still leave more risk than the business is prepared or able to carry.

None of this replaces urgent remediation. Patching a critical vulnerability like PHP2Shell is not optional. Resilience shapes what the episode costs while that work is done.

Resilience matters at portfolio level too. When the same flaw reaches many policyholders or borrowers at once, differences in how quickly each recovers shape the size of the accumulated loss. And this is why the financial value of resilience is relevant to insurers and reinsurers, as well as to the organisations they cover. Insurers and reinsurers can influence the resilience of their clients through underwriting, pricing and risk management, and they can measure the financial value of that influence.

PHP2Shell is a reminder that cyber risk extends beyond successful attacks, and that it can reach many organisations at the same moment. Exposure to shared technology is hard to avoid. What an organisation can influence is how much that exposure costs it, and resilience is a large part of that.