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

NetScaler ADC und Gateway: BSI meldet aktive Ausnutzung

Zwei Lücken in NetScaler ADC und Gateway, darunter ein Authentifizierungs-Bypass; das BSI meldet aktive Ausnutzung. Wer betroffen ist und welche Builds helfen.

Am 19. August 2026 hat Cloud Software Group, der Hersteller von NetScaler, ein Security Bulletin zu zwei Schwachstellen in NetScaler ADC und NetScaler Gateway veröffentlicht. Das CERT-Bund des BSI hat seine Warnung dazu am 7. September aktualisiert – mit dem Vermerk „Aktive Ausnutzung gemeldet“. Aus einem Update, das bis zum nächsten Wartungsfenster warten konnte, ist damit eines geworden, das jetzt eingespielt werden muss.

Einen Workaround nennt der Hersteller nicht. Es bleibt das Update – und die Frage, was vorher schon passiert ist.

Die beiden Schwachstellen

CVE-2026-19490 ist ein Authentifizierungs-Bypass über einen alternativen Pfad (CWE-288), bewertet mit CVSS 9.3 (Version 4.0). Das CERT-Bund stuft die Warnung insgesamt als „kritisch“ ein. Ein Angreifer braucht dafür weder Zugangsdaten noch eine Mitwirkung eines Benutzers; laut CVSS-Vektor ist die Lücke aus dem Netz ohne vorherige Anmeldung ausnutzbar. Das BSI vermerkt die aktive Ausnutzung für die Warnung insgesamt, ohne sie einer der beiden Lücken zuzuordnen.

CVE-2026-19489 ist ein Speicherüberlauf (CWE-119) mit CVSS 8.8, der zu unvorhersehbarem Verhalten oder einem Denial of Service führen kann. Er setzt eine eher spezielle Konfiguration voraus: SIP ALG muss in einer Large-Scale-NAT-Gruppe aktiviert sein. Für die meisten Installationen, die NetScaler als Gateway für den Fernzugriff nutzen, ist das die weniger dringliche der beiden Lücken – schließen sollte man sie trotzdem, zumal sie mit demselben Update behoben wird.

Wer betroffen ist

Betroffen sind kundenseitig betriebene Installationen in diesen Ständen:

  • NetScaler ADC und NetScaler Gateway 14.1 vor 14.1-73.32
  • NetScaler ADC und NetScaler Gateway 13.1 vor 13.1-63.21
  • NetScaler ADC FIPS vor 14.1-73.32 FIPS
  • NetScaler ADC FIPS und NDcPP vor 13.1-37.277

Die Builds 14.1-73.32 und 13.1-63.21 selbst sind also bereits korrigiert. Das ist keine Spitzfindigkeit: Der offizielle CVE-Eintrag nennt die Stände „through“, das Herstellerbulletin „before“. Maßgeblich ist das Bulletin.

Ebenfalls betroffen sind NetScaler-Instanzen in hybriden Secure-Private-Access-Umgebungen. Die von Citrix selbst betriebenen Cloud-Dienste aktualisiert der Hersteller dagegen selbst.

Entscheidend für CVE-2026-19490 ist die Rolle der Appliance. Die Lücke greift nur, wenn sie als Gateway (SSL-VPN, ICA Proxy, CVPN, RDP Proxy) oder als AAA Virtual Server konfiguriert ist. Auf neueren Builds ist die Bedingung enger: Ab 14.1-43.56, ab 14.1-66.68-FIPS und ab 13.1-61.28 ist die Lücke nur dann ausnutzbar, wenn zusätzlich eine SAML-Action konfiguriert ist. Auf älteren Builds und auf 13.1 FIPS genügt die Gateway- oder AAA-Konfiguration allein.

Der Hersteller nennt die Konfigurationszeilen, an denen man das erkennt: add authentication samlAction für die SAML-Action, add authentication vserver oder add vpn vserver für die Gateway- und AAA-Rolle. Für CVE-2026-19489 ist es add lsn group mit sipalg. Ein Blick in die laufende Konfiguration beantwortet die Frage also verlässlicher als die Erinnerung daran, wofür das Gerät einmal angeschafft wurde.

Ein Hinweis zur Priorisierung: Eine NetScaler, die weder als Gateway noch als AAA Virtual Server konfiguriert ist, erfüllt die Voraussetzungen für CVE-2026-19490 nach Herstellerangaben nicht. Dient sie dagegen als Gateway für den Fernzugriff, steht sie genau in der Rolle, auf die es ankommt.

Was jetzt zu tun ist

  • Das Update einspielen, ohne auf das nächste Wartungsfenster zu warten. Der Hersteller fordert betroffene Kunden auf, die korrigierten Versionen „so bald wie möglich“ zu installieren, und nennt ausdrücklich keinen Workaround. Seit der Aktualisierung der BSI-Warnung halten wir ein sofortiges Update für geboten.
  • Den exakten Build feststellen, nicht den Versionszweig. „Wir sind auf 14.1“ beantwortet die Frage nicht. Der Unterschied liegt in der Build-Nummer hinter dem Bindestrich.
  • Alle Instanzen erfassen, nicht nur die bekannte. Hochverfügbarkeitspaare, Testsysteme mit Außenanbindung und Instanzen in hybriden Umgebungen gehören dazu. Ein ungepatchter zweiter Knoten reicht.
  • Von einer möglichen Kompromittierung vor dem Update ausgehen. Die Lücke war seit dem 19. August öffentlich bekannt. Das Update schließt sie, macht aber nicht rückgängig, was in der Zwischenzeit geschehen sein kann. Prüfen Sie Protokolle, Konfigurationsänderungen und angelegte Konten auf Auffälligkeiten.
  • Sitzungen beenden und Zugangsdaten erneuern. Das verlangt das Bulletin nicht; wir empfehlen es trotzdem. Ein Authentifizierungs-Bypass verschafft Sitzungen, und eine einmal aufgebaute Sitzung endet nicht dadurch, dass das Gerät aktualisiert wird. Beenden Sie nach dem Update bestehende Sitzungen und erneuern Sie Zugangsdaten, die über das Gateway geflossen sein können – auch solche von Dienstkonten, mit denen die Appliance gegen Verzeichnisdienste oder Identitätsanbieter spricht.
  • Die Meldelage klären. Wenn Ihr Unternehmen unter NIS-2 fällt und sich ein Verdacht erhärtet, beginnt mit der Kenntnis eine Frist.

Wenn das Update aus betrieblichen Gründen nicht sofort möglich ist, bleibt nur, das Zeitfenster zu verkleinern: nicht benötigte Gateway- und AAA-Funktionen abschalten, den Zugang zu Verwaltungsoberflächen auf bekannte Quellnetze begrenzen und Anmeldungen am Gateway engmaschig beobachten. Das ist ausdrücklich kein Workaround im Sinne des Herstellers – ein Gateway, das Fernzugriff anbietet, lässt sich nicht sinnvoll vom Internet trennen, ohne seinen Zweck aufzugeben. Planen Sie das Update deshalb parallel zu solchen Maßnahmen, nicht danach, und dokumentieren Sie, ab wann welche Instanz auf welchem Build lief. Diese Zeitpunkte brauchen Sie später, wenn Sie die Protokolle auf Auffälligkeiten durchsehen.

Warum es immer wieder die Perimetergeräte trifft

Das BSI beschreibt das Muster im Lagebericht 2025 im Abschnitt „Schwachstellen in Perimetersystemen“: Firewalls und VPN-Gateways verschiedener Hersteller waren erneut Ziel von Angriffen, und der Zeitraum zwischen der Verfügbarkeit eines Patches und der Ausnutzung werde „in den letzten Jahren immer kürzer“. Im vorliegenden Fall lagen zwischen Bulletin und BSI-Vermerk zur aktiven Ausnutzung knapp drei Wochen.

Der Grund ist die Lage dieser Geräte. Ein Gateway steht per Definition im Internet, nimmt Anmeldungen entgegen und hat auf der anderen Seite Zugang zum internen Netz. Wer die Authentifizierung umgeht, steht nicht vor der Tür, sondern im Flur. Gleichzeitig läuft auf einer geschlossenen Appliance in aller Regel keine Endpoint-Erkennung, die verdächtiges Verhalten meldet – die Sichtbarkeit ist dort am geringsten, wo die Exposition am größten ist.

Daraus folgt der Satz, den das BSI im selben Lagebericht formuliert: „Bei Schwachstellenausnutzungen reicht daher alleiniges Patchen üblicherweise nicht aus, um Geräte wieder sicher betreiben zu können.“ Durch Angreifer etablierte Zugänge könnten noch Monate bis Jahre später genutzt werden, wenn installierte Schadsoftware nicht entfernt und Zugangsdaten nicht geändert würden. Das BSI empfiehlt, die Angriffsfläche minimal zu halten, nicht benötigte Produktfunktionen zu deaktivieren und Managementzugänge auf vertrauenswürdige Quellen zu beschränken.

Für den Betrieb heißt das dreierlei. Perimetergeräte gehören mit Build-Stand und verantwortlicher Person ins Inventar. Ihre Protokolle gehören auf ein zentrales System, bevor sie auf dem Gerät überschrieben werden. Und nach einer Lücke wie dieser lautet die Frage nicht „ist gepatcht?“, sondern „was war zwischen Bekanntwerden und Patch möglich – und wie schließen wir es aus?“.

Wie sector7 unterstützt

Wir prüfen die von außen erreichbare Angriffsfläche in wiederkehrenden Schwachstellen-Scans und führen gefundene Lücken über das Patch-Management in eine priorisierte Behebung. Für betreute Umgebungen betreiben wir Firewalls und VPN-Zugänge im Rahmen unserer Managed Services und unterstützen Sie im Incident-Fall bei der Analyse von Security-Events. Mehr dazu unter Cyber Security.

Quellen

Sprechen wir über Ihre Situation.

Gespräch vereinbaren+49 212 240915 0