Threat Intelligence • Citrix NetScaler • CISA KEV

Actively Exploited Citrix NetScaler Vulnerabilities: A Safe Response Guide

CVE-2026-88771 and CVE-2026-88772 can lead to remote code execution on vulnerable NetScaler ADC and NetScaler Gateway appliances. Both are being exploited. The response must combine urgent remediation with evidence preservation and a check for compromise.

Current status: Citrix published fixes on 27 September 2026 and says exploitation has been observed on unmitigated deployments. CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalogue with a 30 September deadline for organisations subject to the applicable US federal directive.

Trends4You Editorial

Who should review this?

Organisations that operate or depend on customer-managed NetScaler

This guidance is relevant if your organisation, hosting provider or managed-service supplier uses customer-managed NetScaler ADC, NetScaler Gateway or Secure Private Access Hybrid instances. These appliances may provide remote access, VPN, application delivery, authentication or load-balancing services at a sensitive boundary.

Do not rely on the product name alone

Confirm who manages the appliance, the installed build, its configuration and its exposure. Citrix says its managed cloud services and Citrix-managed Adaptive Authentication are updated by Cloud Software Group; customer-managed instances require customer action.

Why the feed elevated it

Exploitation evidence makes this an immediate review

Known exploitation

Citrix reports observed exploitation of both vulnerabilities on unmitigated deployments; CISA has placed both in its KEV catalogue.

Boundary technology

NetScaler often sits between the internet and important applications, identities or internal services, increasing the consequence of compromise.

Remote code execution

Both vulnerabilities can lead to code execution without a valid user account when their respective preconditions are met.

Short response window

The CISA federal deadline is 30 September. Other organisations should treat it as a strong risk signal, not as a universal legal deadline.

The feed has done its job

It has raised a decision-useful signal: known exploitation, a critical network appliance and vendor fixes. The next step is to match that signal to real assets, configurations, owners and service consequences.

Confirmed technical picture

Two exploited flaws with different preconditions

VulnerabilityConfirmed effectApplicability
CVE-2026-88771
CVSS 4.0: 9.5
Improper input validation can allow an unauthenticated attacker to execute arbitrary commands.Citrix states that all affected NetScaler ADC and Gateway deployments are vulnerable, including default configurations.
CVE-2026-88772
CVSS 4.0: 9.5
A memory-overflow vulnerability can lead to remote code execution or denial of service.DTLS must be enabled. Citrix notes that DTLS is enabled by default on a VPN virtual server unless it is explicitly disabled.

The same Citrix bulletin covers six additional vulnerabilities. They should be included in the change and exposure review even though CVE-2026-88771 and CVE-2026-88772 are the two for which exploitation has been reported.

Affected and fixed builds

Use the live vendor bulletin as the final authority

Product lineAffected beforeVendor-fixed build
NetScaler ADC and NetScaler Gateway 14.114.1-73.3714.1-73.37 or later
NetScaler ADC and NetScaler Gateway 13.113.1-64.2313.1-64.23 or later in the 13.1 line
NetScaler ADC 14.1-FIPS14.1-73.37 FIPS14.1-73.37 FIPS or later
NetScaler ADC 13.1-FIPS and 13.1-NDcPP13.1.37.27913.1.37.279 or later

Unsupported versions need an escalation decision

If an appliance cannot move to a supported fixed build, do not record it as remediated. Restrict exposure, document the service dependency and exception owner, seek vendor or supplier advice and set a dated replacement or retirement decision.

Safe response workflow

Seven actions for an evidence-preserving response

1

Confirm every deployment and owner

Identify physical, virtual, FIPS, NDcPP, development, disaster-recovery and supplier-managed instances. Record the build, management owner, service purpose and internet exposure.

2

Establish configuration and reachability

Confirm whether DTLS is enabled and identify the VPN, authentication, load-balancing and application-delivery services each appliance supports. Do not assume that an appliance behind another control is unreachable.

3

Preserve evidence before changing state

Where feasible, retain appliance, remote-syslog, console, firewall, DNS and authentication evidence before shutdown, reboot, patching or rebuild. Collect relevant diagnostic information and document the time of each action.

4

Reduce exposure and contain proportionately

Prioritise internet-facing appliances. Restrict management and service access where operationally possible, while agreeing continuity arrangements for remote access and critical applications.

5

Install the relevant fixed build

Follow the current Citrix bulletin and your approved emergency-change process. Include paired appliances, secondary sites and dormant systems that could later return to service.

6

Validate security and service operation

Confirm the running build, external exposure, authentication, VPN and published-application workflows. Retest from the user and administrator perspectives rather than relying only on a successful upgrade message.

7

Investigate and escalate suspicious findings

Patching closes the vulnerability; it does not remove an established attacker. Activate incident response if evidence, exposure or uncertainty warrants it, and assess credentials, sessions, certificates, connected applications and internal movement.

Compromise assessment

Look beyond the appliance update

Where an affected appliance was reachable before the fix—or where reliable historic evidence is unavailable—review the latest Citrix indicators and compromise guidance. Useful evidence includes:

Appliance evidenceUnexpected processes, network connections, startup changes, scheduled activity, modified web directories, crash data or suspicious files and configurations.
Central telemetryRemote syslog, NetScaler Console, firewall, DNS, authentication, endpoint and identity records that cannot be altered from the appliance itself.
Access activityUnusual administration, unexpected outbound connections, abnormal VPN or application sessions and activity on systems reached through the appliance.
Credential exposureAccounts, active sessions, keys and certificates that may need resetting, invalidating or replacing if compromise is suspected.

Preserve first; eradicate deliberately

Do not destroy the only useful evidence through an unrecorded reboot or rebuild. Where compromise is suspected, isolate proportionately, obtain specialist support and follow the current vendor incident-response guidance.

Close with assurance

Record evidence that the risk was actually reduced

CoverageEvery NetScaler instance and supplier-managed dependency has an owner, build and recorded response status.
ExposureInternet and management reachability have been independently rechecked after the change.
RemediationThe running build is at or above the applicable vendor-fixed version, or a time-bound exception is formally owned.
InvestigationAvailable historic and central telemetry has been reviewed, with gaps, findings and escalation decisions recorded.
Service continuityRemote access, authentication and published applications operate as expected, with fallback arrangements retained where needed.
Follow-upAn owner will monitor changes to the Citrix bulletin and reassess any unresolved uncertainty or unsupported deployment.

RACF-CC alignment

One feed alert crosses the control system

Vulnerability Management identifies and remediates affected builds; Network Segmentation limits unnecessary exposure; Monitoring and Detection preserves and correlates evidence; and Incident Response manages suspected compromise. Governance and Risk records service ownership, exceptions and residual uncertainty.

Urgency still needs coordination

Understand → preserve → contain → update → validate → investigate → evidence

A technically correct emergency change can still disrupt remote care or access to important systems. Use the shortest safe route to risk reduction, with an accountable service owner and a tested fallback.

Primary and authoritative sources

Recheck the live guidance before acting

Last checked: 28 September 2026. This is a rapidly developing issue. Confirm the current Citrix bulletin, CISA status and supplier advice immediately before making a technical change.

Voluntary support

Found this useful? Support Trends4You

Trends4You's practical guides, RACF-CC resources and downloadable tools are provided free of charge. If they've helped you or your organisation, you can support the time and hosting that keeps them freely available.

Support is optional, handled securely by Stripe and does not provide additional access.