CVE-2026-35563: Apache Directory LDAP API sårbarhed
Apache Directory LDAP API tjekker ikke serverens værtsnavn i TLS-forbindelsen, så angribere kan udgive sig for at være din LDAP-server.
Hvad er det?
Apache Directory LDAP API er et programbibliotek (et stykke kode som udviklere bruger til at lave forbindelser til LDAP-servere). LDAP bruges typisk til at håndtere brugerlogins og adgangsstyring i virksomheder.
Sårbarheden betyder, at biblioteket ikke tjekker, om det TLS-certifikat (den digitale legitimation der bruges til krypteret forbindelse), serveren præsenterer, faktisk tilhører den rigtige server. Biblioteket tjekker kun, om certifikatet er udstedt af en betroet myndighed — men ikke om det tilhører den korrekte adresse. Det er som at acceptere et pas, fordi det er ægte, uden at tjekke om billedet matcher personen foran dig.
Hvem rammer det?
Sårbarheden rammer virksomheder og udviklere, der bruger Apache Directory LDAP API version 2.0.0 op til og med 2.1.6 i deres systemer eller applikationer. Det kan fx være:
- Interne IT-systemer der bruger LDAP til brugeradministration og login
- Applikationer udviklet af jeres egne udviklere eller leverandører
- Systemer der integrerer med Active Directory eller andre katalogtjenester via dette bibliotek
Hvis du ikke selv ved, om I bruger dette bibliotek, bør du spørge din IT-leverandør eller systemudvikler.
Hvad kan ske?
En angriber der kan placere sig på netværket mellem din applikation og din LDAP-server (et såkaldt MITM-angreb, eller ‘manden i midten’) kan udgive sig for at være den rigtige LDAP-server. Det kan føre til:
- Aflytning af loginoplysninger — brugernavne og adgangskoder sendt til LDAP-serveren kan opfanges
- Manipulation af adgangsstyring — angriberen kan svare med falske oplysninger om, hvem der har adgang til hvad
- Fuld kompromittering af forbindelsen — al kommunikation til LDAP-serveren kan læses og ændres
Angrebet kræver, at angriberen er på jeres netværk og kan præsentere et gyldigt certifikat fra en betroet myndighed — fx ét der er udstedt til et andet domæne.
Hvor alvorligt er det?
Sårbarheden er vurderet til CVSS-score 8,5 ud af 10 og klassificeres som alvorlig. Konsekvenserne for fortrolighed, integritet og tilgængelighed er alle vurderet som høje.
Angrebskompleksiteten er dog høj, hvilket betyder, at angrebet ikke er trivielt at gennemføre. Angriberen skal:
- Have adgang til dit netværk (fx via en kompromitteret maskine eller adgang til din infrastruktur)
- Kunne præsentere et gyldigt certifikat fra en myndighed din applikation stoler på
Det sænker sandsynligheden for tilfældige angreb, men gør det ikke ufarligt — særligt i miljøer med mange brugere, leverandøradgange eller cloud-infrastruktur.
Hvad gør jeg nu?
Det vigtigste du kan gøre er at opdatere Apache Directory LDAP API til version 2.1.7 eller nyere, hvor fejlen er rettet. Følg disse trin:
- Find ud af om I bruger biblioteket — spørg din IT-leverandør eller systemudvikler, om jeres systemer anvender Apache Directory LDAP API.
- Identificér versionen — er versionen 2.0.0 til og med 2.1.6, er I sårbare.
- Opdatér til version 2.1.7 eller nyere — dette lukker sårbarheden ved at gennemtvinge korrekt verifikation af serverens værtsnavn.
- Test efter opdatering — sørg for at jeres LDAP-forbindelser stadig fungerer korrekt efter opdateringen.
- Overvej netværkssegmentering — begræns adgangen til jeres LDAP-infrastruktur, så det er sværere for uautoriserede at placere sig på netværket.
Opdatér hurtigst muligt
Vi anbefaler, at du tager kontakt til din IT-leverandør eller systemudvikler inden for de næste dage for at afklare, om I bruger Apache Directory LDAP API i jeres systemer. Hvis det er tilfældet, bør opdatering til version 2.1.7 prioriteres højt — særligt hvis jeres systemer er tilgængelige fra internettet eller fra netværk med mange brugere og leverandøradgange. Kombinér opdateringen med en gennemgang af, hvem der har netværksadgang til jeres LDAP-infrastruktur.
Tidslinje
Konkrete eksempler
Angriber på virksomhedens netværk opfanger loginoplysninger
En angriber har fået adgang til jeres interne netværk — fx via en kompromitteret medarbejdercomputer. Angriberen placerer sig imellem jeres applikation og LDAP-serveren og præsenterer et gyldigt certifikat udstedt til et andet domæne. Fordi Apache Directory LDAP API ikke tjekker værtsnavnet, accepterer applikationen forbindelsen, og angriberen kan nu læse alle brugernavne og adgangskoder der sendes til LDAP-serveren.
Leverandør med netværksadgang udfører serverimpersonering
En ekstern IT-leverandør har VPN-adgang til jeres netværk. En ondsindet aktør hos leverandøren — eller en angriber der har kompromitteret leverandørens adgang — sætter en falsk LDAP-server op og omdirigerer jeres applikations LDAP-forespørgsler. Applikationen stoler på den falske server, fordi den præsenterer et certifikat fra en betroet myndighed, og angriberen kan manipulere svar om brugerrettigheder og adgange.
MITM-angreb i cloud-infrastruktur
Jeres applikation kører i en cloud-tjeneste og forbinder til en LDAP-server over netværket. En angriber der har kompromitteret dele af cloud-infrastrukturen opsætter et MITM-angreb og præsenterer et certifikat udstedt til en anden cloud-tjeneste. Fordi biblioteket ikke verificerer, at certifikatet tilhører den korrekte LDAP-server, godtages forbindelsen, og angriberen får fuld indsigt i og kontrol over LDAP-kommunikationen.
Ofte stillede spørgsmål
Hvad er LDAP, og bruger vi det?
LDAP (Lightweight Directory Access Protocol) er en standard til at gemme og slå oplysninger op om brugere og rettigheder — fx til login-systemer. Mange virksomheder bruger det bag om kulisserne via Active Directory eller lignende systemer. Spørg din IT-leverandør, om jeres systemer anvender Apache Directory LDAP API specifikt.
Er vi i fare, hvis vi kun bruger LDAP internt på vores eget netværk?
Risikoen er lavere, men ikke elimineret. Et MITM-angreb kræver adgang til jeres netværk, men det kan ske via en kompromitteret computer, en usikker Wi-Fi-forbindelse eller en leverandør med netværksadgang. Opdatering anbefales uanset om systemet er internt eller eksternt vendt.
Kan vi gøre noget, mens vi venter på at opdatere?
Ja. Du kan midlertidigt reducere risikoen ved at sikre, at adgangen til jeres LDAP-server er begrænset til kendte og betroede netværkssegmenter, og ved at overvåge netværkstrafik til og fra LDAP-serveren for mistænkelig aktivitet. Men dette erstatter ikke en opdatering.
Hvordan ved jeg, hvilken version vi kører?
Det afhænger af, hvordan jeres system er bygget. Din IT-leverandør eller systemudvikler kan tjekke jeres afhængigheder (de biblioteker som jeres software bruger). I Java-projekter vil versionen typisk fremgå af en pom.xml- eller build.gradle-fil.
Hvad sker der, hvis vi ikke opdaterer?
Jeres system forbliver sårbart over for angribere, der kan placere sig på jeres netværk og udgive sig for at være jeres LDAP-server. Det kan i værste fald betyde, at loginoplysninger og adgangsstyring kompromitteres, hvilket kan give uautoriseret adgang til jeres systemer.
Ramte produkter
Apache — Directory Ldap Api
≥ 2.0.0, < 2.1.7
CVSS-detaljer
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
It was identified that the LDAP client implementation in version 2.1.7 does not verify if the server certificate matches the intended LDAP
hostname. While the underlying code validates the certificate chain
against a trusted authority, the absence of endpoint identification
allows a valid certificate issued for an entirely unrelated host to be
improperly accepted. This oversight leaves the connection highly
vulnerable to server impersonation and complete connection compromise.
The
root cause of this vulnerability lies in the incomplete TLS server
identity verification within the LDAP client implementation.
The attacker requires MITM capability on the network to exploit this vulnerability. This attacker must be able to present a certificate trusted by the client’s configured trust store.
The hostname verification has been enforced in the new version of the LDAP API
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.
