CVE-2026-86345: Kritisk fejl i 389 Directory Server
Fejl i LDAP-serveren 389-ds-base kan få klienter til at tro en mislykket login er lykkedes. Opdatér når leverandøren udgiver rettelse.
Hvad er det?
389-ds-base er en open source LDAP-server, der bruges til central brugerstyring og autentificering, blandt andet i Red Hat Directory Server og Fedora Directory Server. Fejlen ligger i StartTLS, en metode til at opgradere en almindelig ukrypteret forbindelse til en krypteret forbindelse undervejs. Serveren glemmer at smide ukrypterede bytes væk, som allerede ligger i bufferen fra klientforbindelsen, når den skifter til kryptering. En angriber, der sidder på netværksvejen mellem klient og server, kan derfor indsætte en forfalsket LDAP-besked, som bliver behandlet efter krypteringsskiftet. Fordi beskeden deler samme meddelelses-id som klientens egen forespørgsel, kan svaret på klientens rigtige forespørgsel blive erstattet af angriberens svar.
Hvem rammer det?
Det rammer organisationer, der bruger 389 Directory Server eller afledte produkter som Red Hat Directory Server, Fedora Directory Server eller Red Hat Identity Management (FreeIPA) til central brugerstyring og login via LDAP. Det gælder både virksomheder og kommuner med Linux-baseret identitetsstyring, hvor klientapplikationer bruger StartTLS til at kryptere forbindelsen til LDAP-serveren.
Hvad kan ske?
En angriber, der kan aflytte eller manipulere netværkstrafikken mellem en klient og LDAP-serveren, for eksempel via en kompromitteret switch eller et usikret netværkssegment, kan udnytte fejlen til at få en klientapplikation til at tro, at et mislykket login (bind) i virkeligheden lykkedes. I praksis betyder det, at en bruger eller et system kan blive logget ind uden at have de rigtige legitimationsoplysninger, hvilket åbner for uautoriseret adgang til systemer, der stoler på LDAP-autentificering.
Hvor alvorligt er det?
CVSS-score er 9,0 ud af 10, kritisk. Angrebet kræver hverken login (PR:N) eller brugerhandling (UI:N), men angrebskompleksiteten er sat til høj (AC:H), fordi angriberen skal sidde mellem klient og server på netværket og ramme et præcist tidsvindue under StartTLS-forhandlingen. Der er ikke oplysninger om, at sårbarheden er udnyttet i praksis på offentliggørelsestidspunktet, men konsekvensen ved et vellykket angreb er alvorlig, fordi det kan omgå autentificering.
Hvad gør jeg nu?
Prioritér disse trin for at lukke hullet og reducere risikoen, mens I venter på en officiel rettelse:
- Opdatér 389-ds-base til den patchede version, så snart leverandøren (Red Hat, Fedora eller anden distributør) udgiver den.
- Brug direkte LDAPS (LDAP over TLS fra forbindelsens start) i stedet for StartTLS, hvor det er muligt, så der ikke opstår en ukrypteret fase at udnytte.
- Sørg for, at LDAP-trafik kun går over tillid netværk, VPN eller andre isolerede netsegmenter, så en angriber ikke kan placere sig på netværksvejen.
- Gennemgå logs for usædvanlige mønstre, hvor et login først fejler og derefter godkendes kort efter.
- Begræns hvilke systemer og brugere, der har netværksadgang til LDAP-serveren.
- Få hjælp udefra, hvis I ikke kan vurdere om jeres opsætning bruger StartTLS, eller hvis I mistænker, at netværket allerede er kompromitteret.
Opdatér, så snart patch er klar
Vi anbefaler, at I holder øje med sikkerhedsbulletiner fra jeres LDAP-leverandør og opdaterer, så snart der kommer en rettelse til 389-ds-base. Indtil da bør I sikre, at LDAP-trafik kun kører over tillid netværk, og at StartTLS om muligt erstattes med direkte LDAPS. Det er i orden at vente med akut handling, hvis jeres LDAP-forbindelser allerede er isoleret fra netværk, som eksterne eller uautoriserede parter kan få adgang til.
Tidslinje
Konkrete eksempler
Kommune med Linux-baseret brugerstyring
En kommune bruger Red Hat Identity Management (FreeIPA) med 389 Directory Server til at styre medarbejderlogin til interne fagsystemer. En angriber, der har fået adgang til et netværkssegment, for eksempel via en kompromitteret switch eller usikker gæstewifi, placerer sig mellem en medarbejders klient og LDAP-serveren. Under StartTLS-forhandlingen indsætter angriberen en forfalsket LDAP-besked, som får klienten til at tro, at et mislykket login lykkedes, og medarbejderens system opnår uautoriseret adgang til interne ressourcer.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
Kun hvis I kører 389 Directory Server eller afledte produkter som Red Hat Directory Server, Fedora Directory Server eller Red Hat Identity Management (FreeIPA), og klienter bruger StartTLS til at kryptere forbindelsen til LDAP-serveren.
Hvordan tjekker vi, om vores opsætning er sårbar?
Tjek hvilken version af 389-ds-base pakken I kører, og om jeres LDAP-klientkonfiguration bruger StartTLS frem for direkte LDAPS. Kontakt jeres systemleverandør, hvis I er i tvivl.
Kan vi vente med at opdatere til i næste vedligeholdelsesvindue?
Ja, hvis jeres LDAP-trafik udelukkende kører i et isoleret netsegment, som eksterne ikke kan tilgå. Kører LDAP-serveren derimod på et netværk med bredere adgang, bør I prioritere opdateringen højere, da en angriber kan omgå login.
Skal vi anmelde noget til myndighederne?
Kun hvis I konstaterer, at sårbarheden er udnyttet og har medført adgang til personoplysninger. Vurder det efter databeskyttelsesforordningen, og kontakt eventuelt Datatilsynet.
Hvad er StartTLS, og hvorfor er det et problem her?
StartTLS er en metode, hvor en forbindelse starter ukrypteret og derefter opgraderes til kryptering. Fejlen betyder, at ukrypterede data fra før opgraderingen kan blive misbrugt af en angriber til at indsætte falske svar, efter krypteringen er slået til.
Er sårbarheden udnyttet i praksis?
Der er ikke oplysninger om aktiv udnyttelse på offentliggørelsestidspunktet, men den høje CVSS-score afspejler, at konsekvensen ved et vellykket angreb er alvorlig.
CVSS-detaljer
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
A flaw was found in 389-ds-base. The server does not discard plaintext bytes already buffered from a client connection when negotiating StartTLS, allowing an on-path attacker to inject a crafted LDAP message that is processed after the TLS upgrade and whose response is delivered to the client in place of the client’s own pending operation’s response, due to messageID collision. This can cause a client application to treat a failed authentication (bind) attempt as successful.
Referencer & kilder
Eksterne kilder
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.