NetScaler-fejl udnyttes aktivt – SAML-login kan blive slået ud

En aktivt udnyttet hukommelsesfejl i kundeadministrerede NetScaler ADC- og NetScaler Gateway-installationer kan afbryde SAML-baseret godkendelse og dermed login eller fjernadgang. NHS Englands advarsel af 5. oktober 2026 beskriver risikoen for tjenestenægt, når en berørt installation fungerer som SAML-tjenesteudbyder eller SAML-identitetsudbyder, og anbefaler hurtig opdatering. For danske organisationer er det afgørende at sammenholde den faktiske SAML-rolle med den build, der kører på hver NetScaler-instans.

Aktiv udnyttelse er registreret, og Canadas cybermyndigheds varsel oplyser, at CISA føjede CVE-2026-88779 til kataloget over kendt udnyttede sårbarheder den 4. oktober 2026. Den dokumenterede virkning er tjenestenægt: Et udfald på en central godkendelsesvej kan mærkes som manglende adgang, selv om de tjenester, brugeren forsøger at nå, fortsat er i drift. Hvilke brugere der rammes, afhænger af den konkrete installation og dens rolle i organisationens loginforløb.

SAML-rollen afgør, om installationen er omfattet

En ældre NetScaler-build er ikke alene nok til at opfylde betingelsen for denne fejl. ADC eller Gateway skal også være konfigureret som SAML SP, altså tjenesteudbyder, eller som SAML IdP, altså identitetsudbyder. De to roller kan optræde forskellige steder i samme organisations adgangsløsning; derfor bør gennemgangen omfatte alle egne instanser, ikke kun den Gateway, som brugerne møder ved fjernlogin.

Administratorer kan lede efter konfigurationsposterne «add authentication samlAction» for SP og «add authentication samlIdPProfile» for IdP. Et fund viser, at den relevante SAML-forudsætning er til stede. Først når produktgren og build også er kontrolleret, kan instansen placeres på den rigtige side af versionsgrænsen. En manglende post bør tilsvarende vurderes på den konfiguration, der faktisk er i brug, især hvis organisationen har flere instanser eller adskilte adgangsveje.

Afgrænsningen følger driftsansvaret. Leverandøradministrerede cloudtjenester og Citrix-administreret Adaptive Authentication bliver opdateret af leverandøren. Egne NetScaler-instancer i en Secure Private Access Hybrid-installation er derimod omfattet af kontrollen og skal opdateres, hvis deres SAML-rolle og build opfylder betingelserne.

Find den rettede build i den rigtige produktgren

Citrix' sikkerhedsbulletin angiver både SAML-forudsætningerne, konfigurationsposterne og disse rettede builds for kundeadministrerede installationer. En lavere build i den samme produktgren er berørt, hvis en af de nævnte SAML-roller er i brug:

• NetScaler ADC og NetScaler Gateway 14.1: 14.1-73.41 eller senere.
• NetScaler ADC og NetScaler Gateway 13.1: 13.1-64.28 eller senere.
• NetScaler ADC 14.1-FIPS: 14.1-73.41 FIPS eller senere.
• NetScaler ADC 13.1-FIPS og 13.1-NDcPP: 13.1-37.282 eller senere i den relevante gren.

Det er den installerede og kørende build på den enkelte instans, der tæller. En tidligere NetScaler-opdatering kan have rettet andre fejl uden at nå grænsen for denne sårbarhed. FIPS- og NDcPP-varianterne skal sammenholdes med deres egne grænser; versionsnummeret for en almindelig ADC- eller Gateway-gren kan ikke bruges som svar for dem. Hvis en løsning består af flere NetScaler-instancer, skal hver af dem vurderes, fordi deres builds og SAML-roller kan være forskellige.

Prioritér de adgangsveje, et udfald vil ramme først

Den mest presserende gruppe er kundeadministrerede instanser, der både opfylder SAML-betingelsen, ligger under den rettede build og betjener internetvendt eller forretningskritisk adgang. Prioriteringen bygger på eksponering og driftsmæssig betydning: En afbrudt SAML-funktion på en sådan instans kan blokere netop den loginvej, som brugerne behøver for at nå interne tjenester. Interne instanser med samme tekniske betingelser skal også opdateres, men kan rangordnes efter deres faktiske rolle i adgangskæden.

1. Opgør de kundeadministrerede ADC- og Gateway-instancer, også dem der bruges i Secure Private Access Hybrid. Markér de internetvendte adgangspunkter og de instanser, som bærer kritisk login.
2. Undersøg hver instans for SAML SP- og IdP-posterne. Registrér hvilken rolle der er aktiv, så en instans med identitetsudbyderrollen ikke overses, når fjernadgang vurderes.
3. Notér produktgren og kørende build, og sammenhold dem med den tilsvarende rettede version. Planlæg opdateringen først for instanser, hvor både versions- og SAML-betingelsen er opfyldt, og hvor et udfald vil afskære vigtig adgang.
4. Installér den relevante opdatering, bekræft den kørende build efter genstart, og prøv den konkrete SAML-loginvej og fjernadgang, som instansen betjener.

Kontrollen efter opdateringen er en driftskontrol, ikke et bevis for, om systemet tidligere er blevet udnyttet. Den viser, om den rettede software faktisk kører, og om brugerne stadig kan gennemføre det login, som NetScaler-installationen håndterer. Hvis samme loginvej afhænger af flere instanser, giver det mening at gennemgå dem som en samlet kæde, så en endnu ikke opdateret del ikke skjules af en velfungerende del.

Konsekvensen ligger i adgangen til tjenesterne

En tjenestenægt i SAML-funktionen kan gøre en ellers fungerende tjeneste utilgængelig for brugere, der skal igennem den berørte godkendelsesvej. Hvor omfattende afbrydelsen bliver, afhænger af hvilke applikationer, brugergrupper og fjernadgangsforløb der er knyttet til instansen; den samme sårbarhed kan derfor have forskellig driftsmæssig vægt på to installationer. Det er grunden til, at eksponering og loginvej bør indgå i rækkefølgen sammen med produktgren og build.

For en berørt internetvendt instans er den konkrete næste handling at få den relevante rettede build i drift og verificere adgangen bagefter. En planlagt vedligeholdelsesrunde ændrer ikke risikoen, så længe den sårbare build fortsat håndterer SAML-login.

Læs også:

• TikTok-musik til reklame: Populære lyde kan mangle licens
• Planday eller Deputy? Dansk lønintegration kan slå billig automatik