An exploited flaw in a remote-access gateway creates three separate loss scenarios, and patch speed is evidence for only one of them.
The call before the patch
Before Citrix said a word in public about its latest NetScaler flaws, administrators were already being told to switch their appliances off. BleepingComputer reported that IT suppliers and security teams were privately calling customers, and one administrator wrote: “We got a call from our IT supplier’s security team, they couldn’t give any details but they advised to shut our Netscalers down immediately.” On 27 September Citrix confirmed two critical remote code execution vulnerabilities, CVE-2026-88771 and CVE-2026-88772, both exploited as zero-days and both rated 9.5. The first affects all NetScaler ADC and Gateway deployments, including the default configuration. The second needs DTLS, which Citrix notes is enabled by default on VPN virtual servers.
It was not an isolated fortnight. Cisco disclosed an actively exploited zero-day in Catalyst SD-WAN Manager that gives an unauthenticated remote attacker administrative access, Infosecurity Magazine reported on 1 October. Citrix followed with another exploited NetScaler flaw on 4 October. And the FBI warned that FortiBleed attacks on Fortinet VPN gateways were still running.
The instinct is to put all of this on one line of the risk register: attacker exploits the edge appliance, we are breached, and the evidence for Vulnerability is how fast we patch. That line merges at least three distinct loss events. They have different factor structures in FAIR, different evidence behind them, and different answers to the question a board will actually ask: is this closed?
Scenario one: the outage the client inflicts on itself
The first loss event does not need an attacker to reach the client at all. Once the advisory lands, the emergency upgrade or the shutdown follows almost by default for any organization running the product exposed. It sits awkwardly in the usual template, because the threat community is the one exploiting the flaw elsewhere, yet the loss lands whether or not they ever touch this client’s appliance. The practical way to model it: its frequency is roughly the frequency of exploited-flaw disclosures in that product, because the step from “advisory published” to “service taken down” is close to certain.
The loss forms are Productivity (remote access or application delivery unavailable for the window) and primary Response (the emergency change, out-of-hours staff, supplier support). The downtime is not hypothetical. According to BleepingComputer, the Dutch National Cyber Security Centre reportedly sent organizations a pre-notification precisely because NetScaler upgrades can cause downtime, so that they had time to prepare. The evidence for this scenario is unusually cheap and good: the client’s own change records from previous emergency upgrades on the same appliance, and the vendor’s public advisory history.
Two refinements matter. First, disclosures in one product tend to cluster. Dan Andrew, head of security at Intruder, told Infosecurity Magazine that it is not uncommon for a string of vulnerabilities in a product to surface in quick succession, “likely due to renewed scrutiny by researchers on the product, including those looking to reproduce the work of whoever found it first, and attackers doing the same.” The later NetScaler flaw, CVE-2026-88779, arrived a week after the first pair and went onto CISA’s Known Exploited Vulnerabilities catalog the day Citrix published its update. After one exploited flaw, the near-term frequency estimate should go up, not reset to the annual average. That later flaw also causes denial of service, so an attacker can now produce the outage directly, which merges this scenario with the hostile one.
Second, the controls that move this scenario are architectural: redundant pairs that allow a rolling upgrade, a second access path that keeps critical users working while the gateway is down. Patch speed does not reduce the outage. A faster patch cadence can mean more frequent, shorter outages. That makes the cost of the control part of the analysis. If “patch immediately or shut down” is treated as free, every comparison between mitigation options is quietly distorted in favour of the one that looks fastest.
Scenario two: compromise that predates the patch
According to a follow-up BleepingComputer report, Mandiant says the NetScaler attacks began in at least early September, and GreyNoise observed an exploitation attempt on 24 September, three days before public disclosure. Exploitation started before any patch existed. The client’s patch SLA therefore has no bearing on whether this loss event has already happened.
Patching afterwards does not evict an attacker who is already in. The researchers described web shells disguised as requests for image or CSS files, and a tunnelling tool Mandiant calls SLAPSHOT that bridges the compromised appliance to internal hosts, used in at least one intrusion for reconnaissance and credential theft. FortiBleed shows the same shape with credentials rather than code: in its warning, as reported by BleepingComputer, the FBI said remediation may require more than patching and resetting Fortinet passwords.
The Resistance Strength that counts here sits behind and around the appliance, not on it. What can the appliance reach? Can anything see activity on a device that, as BleepingComputer notes, sits at the edge without the benefit of EDR software? Did anyone hunt for the indicators the researchers published? “We patched within 24 hours” closes nothing in this scenario. The evidence that closes it is a compromise assessment, and until one is done the honest grade is “assumed clean”.
Scenario three: the window after disclosure
This is the scenario patch speed was always describing. The Dutch notice warned that exploitation attempts could increase once Citrix released patches and technical details. Here, time to patch and the interim mitigations are exactly the right Resistance Strength evidence: Mandiant’s advice to disable DTLS where operationally feasible and block inbound UDP/443 upstream where DTLS is not needed, Citrix’s deny-list signatures for the later flaw, and reducing internet exposure until the upgrade is in. FAIR defines Vulnerability as the probability that a threat event becomes a loss event, for a specific threat community against a specific asset. It is not a CVE count and not a patch metric. Patch speed is a valid input only where the threat event happens after the patch exists.
What the split changes in the report
Compare two ways of reporting the same fortnight to an investment committee or a board.
The usual version reads: “Critical NetScaler zero-days. Patched within one day. Closed.”
The split version reads:
- Forced outage: occurred. Remote access was down for the upgrade window; the cost comes from the change record. Demonstrated.
- Prior compromise: open. Exploitation predates disclosure and no indicator hunt has been done yet. Assumed, not closed.
- Exploitation after disclosure: reduced. Patched before the expected rise in attempts. Documented.
The first version is reassuring and partly wrong. The second tells the committee which loss was certain and already paid, which is unknown until someone looks, and which was genuinely reduced by speed. Each line carries an evidence grade, the same discipline that separates a demonstrated recovery from a documented one in ransomware recovery estimates. It also changes what money gets spent on next: a second access path and a compromise assessment, rather than a still-faster patch target.
None of this can be done from the advisory alone. The split depends on judgement about which loss events are in play for this client, and on the client’s own people: the network team that knows what the appliance can reach, the service owners who know what stops working when the gateway goes dark, the responders who know what a compromise assessment would have to find. Those conversations turn one headline into three lines a committee can act on.