NetScaler Zero-Days: Can Your Applications Stay Online During a Security Incident?

A critical security alert arrives, and your team needs to act. The affected system may need to be isolated, investigated and updated before it can safely return to service. The difficulty is that this same system sits between your users and the applications they depend on. Taking it offline could mean interrupting customer transactions, employee access or essential business services.

That was more than a theoretical concern in the recent NetScaler security guidance. On September 28, 2026, the UK’s National Cyber Security Centre recommended isolating affected systems where possible and replacing them with fully updated systems. Its advice explicitly acknowledged that doing so could cause a service outage. 

For an IT leader, that brings the issue out of the security team’s queue and into a broader business conversation. Can the organization take the necessary protective action without losing access to its critical applications? Has anyone tested what happens when the infrastructure responsible for keeping those applications available is the infrastructure that needs to be removed?

Those questions deserve attention well beyond the immediate NetScaler response.

What the NetScaler alerts actually tell us

On September 27, 2026, Citrix published a security bulletin covering eight vulnerabilities in customer-managed NetScaler ADC and NetScaler Gateway deployments. Two, CVE-2026-88771 and CVE-2026-88772, were confirmed as actively exploited. Both could allow attackers to execute code on affected systems, subject to the deployment conditions described in the advisory. 

On October 3, Citrix published a separate bulletin for CVE-2026-88779, affecting certain SAML authentication configurations. Citrix described targeted attacks that could disrupt service availability and issued additional updates. Organizations that had installed the September fixes could therefore still need another update for this newly disclosed issue. That is an important distinction: the later vulnerability was not evidence that the earlier patches had failed to fix the earlier flaws. 

A further critical advisory followed on October 8 for CVE-2026-107406. Unlike the earlier alerts, Citrix did not report observed exploitation of that vulnerability when it published the guidance. 

Each advisory needs to be assessed on its own facts. Different vulnerabilities have different prerequisites, consequences and remediation requirements. Treating them all as one “Citrix breach” would obscure the information administrators need to make good decisions.

For business leaders, however, the sequence raises a consistent operational question. How much disruption does each urgent change introduce, and how much flexibility does the application delivery architecture give the team responsible for making it?

Two appliances can still share the same weakness

It is reasonable to feel more confident about an application supported by redundant infrastructure. There is a second system ready to take over, and the team may have successfully tested that handover many times.

The limitation is what that test proves.

NetScaler’s high-availability documentation specifies that both nodes run the same software version and maintain matching configurations, with defined exceptions. The implication is straightforward: where both systems share vulnerable software and the relevant exposure, moving from one to the other does not remove that underlying vulnerability.

Consider a hypothetical organization with a customer portal behind two application delivery controllers. Its failover test shows that the secondary appliance takes over when the primary is stopped. That is useful evidence of hardware resilience. It does not demonstrate that the portal can remain available if the security team needs to isolate both appliances.

This is the gap worth examining. A recovery plan should distinguish between losing one component and losing confidence in an entire group of components.

The answer is not automatically to introduce another vendor. An alternative platform can still depend on the same identity service, management access, network connection or application environment. What matters is whether the alternative can operate without the systems being investigated, not simply whether it has a different name on the front.

Patching and recovery are different jobs

Installing the required updates is essential. Establishing whether an attacker reached the system before those updates were installed is a separate responsibility.

CISA’s September guidance encouraged organizations to check for indications of compromise before patching where possible. It also warned that, when compromise is suspected, forensic evidence should be preserved before applying updates because updating may reduce forensic visibility.

CERT-EU similarly recommended both updating affected software and conducting a compromise assessment on internet-facing appliances running an affected build. A completed update should therefore not be treated as the only evidence needed to close the incident.

That distinction changes how continuity should be planned. A maintenance procedure built around a short restart is not necessarily suitable for an investigation that requires an appliance to remain isolated. The team needs a plan for operating while the affected infrastructure is unavailable, rather than assuming it will be safe to restore as soon as the software installation finishes.

Leadership should make room for that work. Pressure to restore service can create a temptation to treat a responding system as a recovered system. The recovery decision should instead follow the evidence and the incident response process, even when the business is understandably anxious to return to normal.

An alternative location needs an independent delivery path

A useful architecture review begins with a practical exercise: follow a user’s request from the moment they try to access an application to the moment they can complete a meaningful task.

For a customer portal, that means more than checking whether a backup server is running. Review name resolution, traffic routing, authentication, certificates, application services and access to the necessary data. Then examine which of those dependencies would remain available if the primary delivery infrastructure were isolated.

A standby application in another cloud may look convincing on a diagram. It becomes much less useful if users still have to pass through the affected gateway to reach it.

DNS-based Global Server Load Balancing can form part of an alternative delivery path. Total Uptime’s GSLB service combines DNS routing with health monitoring to direct users toward configured application locations and change DNS responses when a location becomes unavailable.

For a security incident, the design needs to go further. The alternative environment should be assessed for shared exposure and approved for service. A passing availability check should not be the sole basis for deciding that an environment is safe to use.

Recovery expectations also need to reflect how the technology works. DNS-based failover affects subsequent DNS resolutions; it does not automatically transfer existing connections. Cached responses and client behavior influence how quickly users begin reaching the alternative location. Those factors belong in the recovery test, not in the list of surprises discovered during an incident.

Changing DNS is also a routing action, not a substitute for isolating vulnerable infrastructure. Incident response still needs the appropriate access restrictions and containment measures, such as those described in the NCSC guidance. 

Finally, plan the return journey. An appliance that starts responding again should not automatically rejoin production while its security status is unresolved. Build an explicit approval step into the recovery process so that restoring connectivity does not inadvertently reverse containment.

Give the team permission to act before the emergency

There is a useful leadership exercise behind all of this: ask the team to walk through a scenario in which the main application delivery systems must remain unavailable throughout an investigation.

Do not stop at whether a backup exists. Ask what customers and employees would actually experience, which services could continue, which would need to pause and who has the authority to make those decisions.

The exercise should also establish whether administrators can still reach the systems they need to manage. A recovery procedure is of limited value if the management access required to execute it depends on the gateway that has just been isolated.

Set realistic priorities with the people who own the business services. Some applications may need an independently available alternative. Others may be able to operate with reduced functionality, while less critical services can wait. Those choices should be deliberate, understood and tested.

For the next resilience review, consider measuring more than patch completion. Measure how long it takes to identify affected application dependencies, approve containment, activate an acceptable alternative and verify that users can complete essential tasks.

This is not an argument for keeping potentially compromised systems online to protect an uptime target. Where there is no safe alternative, a controlled outage may be the right decision. The purpose of better architecture is to give the organization more safe choices before it reaches that point.

Rethink the operating model, not just the appliance

Once the immediate response is under control, the incident can inform a more considered review of application delivery.

Start with the work the organization needs to perform. Who maintains the delivery platform? Who evaluates security advisories? Who tests changes, manages routing and supports the team when the behavior of an application does not match expectations?

Those questions are worth asking before comparing product specifications.

For organizations that want managed application delivery, Total Uptime’s ADC-as-a-Service provides load balancing, health monitoring and traffic management across application environments, including cloud and on-premises infrastructure. It offers a different operating model from deploying the delivery platform entirely within the customer’s own environment.

For teams that need to retain direct control of their infrastructure, self-hosted EdgeADC provides application delivery capabilities including load balancing, health monitoring and application-aware traffic management. 

Neither option should be evaluated as a promise that software vulnerabilities disappear. A managed service needs clear operational responsibilities and escalation procedures. A self-hosted platform needs a maintenance and recovery approach the customer can sustain. In both cases, the architecture still needs to be tested against the business’s requirements.

A NetScaler migration also deserves careful scoping. Evaluate application delivery and load balancing requirements alongside any remote access, VPN or authentication functions in use. Do not assume that replacing one function automatically replaces every role the existing environment performs.

At Total Uptime, our view is that the right conversation starts with the applications, their dependencies and the team responsible for keeping them available. The product decision should follow that understanding.

The question to ask before the next alert

The immediate NetScaler response should follow the current vendor advisories and the organization’s incident response procedures. The longer-term opportunity is to learn something about the business’s ability to respond safely.

A valuable outcome from the review would be a tested answer to this question:

Could we remove this infrastructure from service and still provide the applications the business needs?

Where the answer is no, the next step is to identify what would have to change. That might involve a more independent delivery path, clearer recovery responsibilities, a different operating model or a planned migration. It should result in something the team can demonstrate, rather than another assumption added to the disaster recovery document.

Total Uptime offers a free NetScaler migration assessment, with a structured approach covering discovery, planning, configuration testing and cutover. It provides a starting point for reviewing the current environment and understanding where an alternative application delivery model could fit. 

Talk to Total Uptime about your NetScaler environment and request a free migration assessment.

Security advisory details reflect information available on October 9, 2026. Consult the current Citrix advisories for affected configurations and required updates.