Why Pulling a Perimeter Appliance Offline Is a Legitimate Zero-Day Response

On 26 September 2026, before Citrix had published a bulletin, before any CVE number existed, NetScaler administrators started getting phone calls. BleepingComputer recorded one of them: an IT supplier's security team rang a customer, could not share details, and advised shutting the NetScalers down immediately. Others heard from national CERTs and law enforcement. The administrators who acted on those calls disconnected their remote-access gateway on the strength of a rumor. The next day Citrix confirmed two remote code execution zero-days, CVE-2026-88771 and CVE-2026-88772, exploited in the wild, and CISA gave federal agencies three days to remediate. The people who pulled the plug were right. This piece is about why that decision is legitimate, why most organizations cannot make it fast enough, and how to change that.

The Asymmetry Nobody Budgets For

An internet-facing gateway is a single device that concentrates risk. Every remote user authenticates through it, every session cookie passes through it, and it holds service-account credentials for the directory and RADIUSRADIUS🌐Remote Authentication Dial-In User Service, the protocol network devices use to ask a central server whether a user or device should be granted access and with what attributes. Each device shares a secret with the server, so a compromised server exposes the secrets of every device that trusts it. servers behind it. When such a device has an unauthenticated remote code execution flaw that is confirmed exploited, the expected cost of leaving it online for one more day is the full compromise of everything it touches. The expected cost of taking it offline for one day is a day of degraded remote access.

Those two numbers are not close, yet organizations routinely choose the first because the second is visible and the first is hypothetical. The remote-access outage generates tickets within minutes. The breach generates nothing until weeks later, when an incident responder finds the web shellWeb Shell🛡️A malicious script placed in a web server's content directory that lets an attacker execute commands through HTTP requests. Web shells are a common persistence mechanism after remote code execution and are detected by looking for unexpected files in webapp directories.. Rational decision-making under that asymmetry requires deciding in advance, when nobody is on the phone, what threshold justifies a shutdown.

What "Offline" Actually Means

Taking a gateway offline is not one action, and the differences matter. The mildest form is blocking the vulnerable listener only: for CVE-2026-88772, disabling DTLS removes the exploitation path while leaving the TCP-based VPN running with worse latencyLatency🌐The delay between sending a request and receiving a response, measured in milliseconds (ping).. Our explainer on how DTLS works and why it widens a VPN gateway's attack surfaceAttack Surface🛡️The sum of all points where an unauthorized user could attempt to enter or extract data from a system: exposed services, interfaces, accounts, and integrations. Reducing attack surface means removing reachability, not just patching. covers that specific case. The next step is blocking all inbound internet traffic to the appliance at the upstream firewallFirewall🌐Security system that monitors and controls network traffic based on predetermined rules. while leaving it reachable from inside, which stops new exploitation, ends any active attacker session, and preserves the device for investigation. The most severe step is powering it off, which should almost never be the choice, because it destroys the memory evidence you will need.

For CVE-2026-88771 the mild option does not exist, since the flaw affects the default configuration and requires no optional feature. The available choices were upstream block or stay exposed. Note that the upstream block is also the correct isolation posture for evidence capture, described in how to preserve forensic evidence on a network appliance before you patch it. Shutdown and forensics are the same action viewed from two angles.

Why the Decision Stalls

In most organizations, disconnecting a production gateway requires an emergency change request, a manager's approval, and often a call to the business owners of whatever the gateway serves. Each step is reasonable in isolation. Together they add hours, and the person best placed to see the danger, the engineer reading the watchTowr warning at nine in the evening, has no authority to act on it.

Three objections come up every time. The first is that the vendor has not confirmed anything. That is true and irrelevant; confirmed exploitation reported by an incident-response firm is a stronger signal than a vendor bulletin, because vendors publish after they have a fix and responders publish when they see attacks. The second is that the business cannot tolerate the outage. Test that claim. Most organizations have a secondary access path, a cloud-hosted alternative, or simply a tolerance for one working day without VPN that they have never been forced to discover. The third is that shutting down might be an overreaction. It might. The cost of an overreaction is a day of complaints. The cost of the opposite error is on the front page.

Pre-Authorizing the Call

The fix is a standing decision, written down and signed off, that specifies the conditions under which the on-call engineer may disconnect an internet-facing appliance without further approval. A workable trigger is: a critical, unauthenticated, remotely exploitable vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. in the product, with credible reporting of exploitation in the wild, and no vendor fix or mitigation yet applied. All three conditions were met for NetScaler on 26 September, and the engineer who got the call from the supplier could have acted within minutes under such a policy.

The policy needs four supporting pieces. A runbook for the block itself, per appliance, naming the firewall rule or the switch port and the person who can verify it. A communication template that tells users remote access is down for security reasons and gives an estimated restoration time. A list of business processes that break without the gateway, with contacts, so the engineer knows who to notify rather than who to ask. And a rule that the disconnect is followed by evidence capture and patching, not by waiting; the goal of the shutdown is to buy time for those steps, not to replace them.

Planning for the Gateway You Will Lose

The deeper strategic point is that a perimeter appliance should be designed to be lost. If disconnecting the VPN gateway for a day would halt the business, that is an architecture problem, not an incident-response problem. Redundant access paths, whether a second vendor's product, a zero-trust access broker, or a cloud-hosted VPN that can be enabled on demand, turn a shutdown from a crisis into a routing change. The gateway's service accounts should have the minimum directory rights needed to authenticate users, so that its compromise does not automatically become a domain compromise. Its certificates should be short-lived so that rotation after an incident is a routine renewal rather than a project. And egress from the appliance should be filtered, so that a compromised gateway cannot reach an attacker's command-and-control address even if the exploitExploit🛡️Code or technique that takes advantage of a vulnerability to cause unintended behavior, such as gaining unauthorized access. succeeds; Truesec published three such addresses for this campaign, and an appliance that could not have reached them would have been a much less valuable target.

The Test

Here is the question to put to your own organization this week. If an incident-response firm reports tomorrow morning that your remote-access product has an unpatched, exploited remote code execution flaw, who can disconnect it, how long will it take them, and what happens to the business while it is down? If any of those answers is "we would have to figure that out," you have your next project. The NetScaler administrators who shut down on a rumor were not lucky. They had, whether formally or through good judgment, already answered those questions.