September 7, 2026 · Security-Advisory · Perimeter · Schwachstellenmanagement · IT-Sicherheit

NetScaler ADC and Gateway: BSI Reports Active Exploitation

Two flaws in NetScaler ADC and Gateway, including an authentication bypass; the BSI reports active exploitation. Who is affected and which builds help.

On 19 August 2026, Cloud Software Group, the maker of NetScaler, published a security bulletin on two vulnerabilities in NetScaler ADC and NetScaler Gateway. The BSI’s CERT-Bund updated its warning on 7 September – with the note “active exploitation reported”. An update that could wait until the next maintenance window has thus become one that must be applied now.

The vendor names no workaround. What remains is the update – and the question of what has already happened before it.

The two vulnerabilities

CVE-2026-19490 is an authentication bypass using an alternate path (CWE-288), rated CVSS 9.3 (version 4.0). CERT-Bund classifies the warning as a whole as “critical”. An attacker needs neither credentials nor any user interaction; according to the CVSS vector, the flaw can be exploited over the network without prior authentication. The BSI notes active exploitation for the warning as a whole, without attributing it to either of the two flaws.

CVE-2026-19489 is a memory overflow (CWE-119) rated CVSS 8.8 that can lead to unpredictable behaviour or a denial of service. It requires a rather specific configuration: SIP ALG must be enabled in a Large-Scale NAT group. For most installations that use NetScaler as a gateway for remote access, this is the less urgent of the two flaws – it should be closed all the same, especially as it is fixed by the same update.

Who is affected

Affected are customer-managed installations at these levels:

  • NetScaler ADC and NetScaler Gateway 14.1 before 14.1-73.32
  • NetScaler ADC and NetScaler Gateway 13.1 before 13.1-63.21
  • NetScaler ADC FIPS before 14.1-73.32 FIPS
  • NetScaler ADC FIPS and NDcPP before 13.1-37.277

Builds 14.1-73.32 and 13.1-63.21 themselves are therefore already fixed. This is not hair-splitting: the official CVE record lists the levels as “through”, the vendor bulletin as “before”. The bulletin is authoritative.

NetScaler instances in hybrid Secure Private Access environments are affected as well. The cloud services operated by Citrix itself, by contrast, are updated by the vendor.

What decides CVE-2026-19490 is the role of the appliance. The flaw only applies when it is configured as a gateway (SSL VPN, ICA Proxy, CVPN, RDP Proxy) or as an AAA virtual server. On newer builds the condition is narrower: from 14.1-43.56, from 14.1-66.68-FIPS and from 13.1-61.28, the flaw is only exploitable if a SAML action is also configured. On older builds and on 13.1 FIPS, the gateway or AAA configuration alone is enough.

The vendor names the configuration lines by which this can be recognised: add authentication samlAction for the SAML action, add authentication vserver or add vpn vserver for the gateway and AAA role. For CVE-2026-19489 it is add lsn group with sipalg. A look at the running configuration therefore answers the question more reliably than anyone’s memory of what the device was once bought for.

A note on prioritisation: a NetScaler configured neither as a gateway nor as an AAA virtual server does not meet the preconditions for CVE-2026-19490, according to the vendor. If, on the other hand, it serves as a gateway for remote access, it sits in exactly the role that matters.

What to do now

  • Apply the update without waiting for the next maintenance window. The vendor urges affected customers to install the fixed versions “as soon as possible” and explicitly names no workaround. Since the BSI warning was updated, we consider an immediate update necessary.
  • Determine the exact build, not the version branch. “We are on 14.1” does not answer the question. The difference lies in the build number after the hyphen.
  • Capture all instances, not just the known one. High-availability pairs, test systems with an external connection and instances in hybrid environments all count. One unpatched second node is enough.
  • Assume a possible compromise before the update. The flaw has been publicly known since 19 August. The update closes it, but does not undo what may have happened in the meantime. Check logs, configuration changes and created accounts for anomalies.
  • Terminate sessions and rotate credentials. The bulletin does not require this; we recommend it nonetheless. An authentication bypass yields sessions, and a session once established does not end because the device is updated. After the update, terminate existing sessions and renew credentials that may have passed through the gateway – including those of service accounts the appliance uses to talk to directory services or identity providers.
  • Clarify the reporting position. If your company falls under NIS-2 and a suspicion hardens, a deadline starts running from the moment you become aware of it.

If the update is not immediately possible for operational reasons, all that remains is to shrink the window: switch off gateway and AAA functions that are not needed, restrict access to management interfaces to known source networks, and watch logins at the gateway closely. This is explicitly not a workaround in the vendor’s sense – a gateway that offers remote access cannot sensibly be cut off from the internet without giving up its purpose. So plan the update alongside such measures, not afterwards, and document from when which instance ran on which build. You will need those points in time later, when you go through the logs for anomalies.

Why it keeps hitting perimeter devices

The BSI describes the pattern in its 2025 situation report in the section “Vulnerabilities in perimeter systems”: firewalls and VPN gateways from various vendors were once again targets of attacks, and the time between the availability of a patch and the exploitation of the vulnerability has become “shorter and shorter in recent years”. In the present case, just under three weeks lay between the bulletin and the BSI’s note on active exploitation.

The reason is where these devices sit. A gateway is by definition on the internet, accepts logins and, on the other side, has access to the internal network. Whoever bypasses authentication is not standing at the door but already in the hallway. At the same time, a closed appliance as a rule runs no endpoint detection that reports suspicious behaviour – visibility is lowest exactly where exposure is greatest.

From this follows the sentence the BSI formulates in the same report: “When vulnerabilities are exploited, patching alone is usually not enough to ensure that devices can be operated securely again.” Access established by attackers could still be used months or years later if installed malware is not removed and credentials are not changed. The BSI recommends keeping the attack surface minimal, deactivating product functions that are not needed, and restricting management access to trusted sources.

For operations this means three things. Perimeter devices belong in the inventory with their build level and a responsible person. Their logs belong on a central system before they are overwritten on the device. And after a flaw like this one, the question is not “is it patched?” but “what was possible between disclosure and patch – and how do we rule it out?”.

How sector7 supports you

We check the externally reachable attack surface in recurring vulnerability scans and feed the flaws we find through patch management into prioritised remediation. For environments we look after, we operate firewalls and VPN access as part of our managed services and support you in an incident with the analysis of security events. More under cyber security.

Sources

Let's talk about your situation.

Arrange a call+49 212 240915 0