CVE-2026-47838: Sårbarhed i VMware Spring Security
Fejl i Spring Security kan lade en angriber udgive sig for en anden bruger via et manipuleret certifikat.
Hvad er det?
CVE-2026-47838 er en sårbarhed i VMware Spring Security, et udbredt sikkerhedsframework til Java-baserede webapplikationer og -tjenester. Fejlen ligger i den måde, frameworket læser brugernavne fra X.509-certifikater (digitale identitetsbeviser, der bruges til at bekræfte hvem du er på nettet). Hvis et certifikat er konstrueret på en bestemt, bevidst forkert måde, kan systemet forveksle brugeridentiteter og give adgang til den forkerte konto. En angriber med et gyldigt, men manipuleret certifikat kan på den måde udgive sig for at være en anden bruger i systemet.
Hvem rammer det?
Sårbarheden rammer virksomheder, der:
- Driver Java-baserede webapplikationer eller API-tjenester bygget med Spring Security
- Bruger X.509-certifikater til brugergodkendelse (login via digitale certifikater)
- Kører Spring Security i versionerne 5.7.0–5.7.24, 5.8.0–5.8.26, 6.3.0–6.3.17, 6.4.0–6.4.17 eller 6.5.0–6.5.10
Er du usikker på, om din applikation bruger Spring Security, bør din webudvikler eller IT-leverandør tjekke det hurtigst muligt.
Hvad kan ske?
Hvis en angriber udnytter denne sårbarhed, kan konsekvenserne være alvorlige:
- Identitetssvig: Angriberen kan logge ind som en anden bruger — f.eks. en administrator eller en kollega — uden at kende dennes adgangskode.
- Datalæk: Angriberen får adgang til den efterlignede brugers data, dokumenter og fortrolige oplysninger.
- Uautoriserede ændringer: Angriberen kan foretage handlinger i systemet i den anden brugers navn, f.eks. ændre indstillinger, godkende transaktioner eller slette data.
Tilgængeligheden af jeres systemer (om de er oppe og kørende) påvirkes ikke direkte af denne sårbarhed.
Hvor alvorligt er det?
Sårbarheden er vurderet til 6,8 ud af 10 (Moderat) af det internationale sikkerhedsorgan CVSS. Vurderingen afspejler, at angrebet kræver en vis teknisk snilde — angriberen skal have et gyldigt certifikat i forvejen og konstruere det præcist rigtigt. Det er altså ikke noget, hvem som helst kan gøre fra sofaen. Til gengæld er konsekvensen potentielt alvorlig, da angriberen kan overtage en anden brugers identitet fuldt ud. Virksomheder, der bruger certifikatbaseret login til følsomme systemer, bør prioritere opdatering højt.
Hvad gør jeg nu?
Kontakt din IT-leverandør eller webudvikler og bed dem gennemgå nedenstående punkter hurtigst muligt:
- Identificér om I bruger Spring Security: Bed din udvikler tjekke, om jeres applikationer bruger Spring Security og i hvilken version.
- Opdatér til en sikker version: Opgradér til en af de rettede versioner — 5.7.25, 5.8.27, 6.3.18, 6.4.18 eller 6.5.11 — afhængigt af hvilken version I bruger i dag.
- Tjek om I bruger certifikatbaseret login: Spørg din leverandør, om jeres system bruger X.509-certifikater til brugergodkendelse. Gør det ikke, er risikoen markant lavere.
- Gennemgå adgangslogfiler: Bed din IT-ansvarlig gennemse loginlogfiler for usædvanlig aktivitet, særligt uventede logins fra certifikater.
- Hold øje med opdateringer: Følg VMware/Broadcom og Spring-projektets sikkerhedsmeddelelser for eventuelle yderligere informationer.
Opdatér inden for 30 dage
Vi anbefaler, at du hurtigst muligt beder din IT-leverandør eller udvikler opdatere Spring Security til den nyeste rettede version. Opdateringen er tilgængelig nu og løser problemet direkte. Bruger I ikke certifikatbaseret login, er risikoen begrænset — men opdatering er stadig god praksis. Har du ikke en fast IT-leverandør, er du velkommen til at kontakte os for hjælp til at vurdere din eksponering.
Tidslinje
Konkrete eksempler
Angriber udgiver sig for administrator
En angriber, der har fået udstedt et gyldigt klientcertifikat til eget brug i en virksomhedsapplikation, manipulerer certifikatets CN-felt (det felt der indeholder brugernavnet) på en specielt konstrueret måde. Når applikationen, der kører en sårbar version af Spring Security, læser certifikatet, forveksler den brugernavnet og giver angriberen adgang som en anden bruger — f.eks. en systemadministrator. Angriberen kan nu tilgå følsomme data og funktioner, som han normalt ikke har adgang til.
Adgang til en kollegas kundedata
I en virksomhed, der bruger certifikatbaseret login til et CRM-system (system til styring af kunderelationer), konstruerer en medarbejder med ondsindede hensigter et manipuleret certifikat, der får systemet til at tro, at vedkommende er en salgschef med adgang til alle kundeoplysninger. Medarbejderen kan nu eksportere fortrolige kundedata, som de ikke burde have adgang til, uden at det umiddelbart udløser alarm.
Ekstern angriber via kompromitteret certifikat
En ekstern angriber, der har opsnappet eller på anden vis erhvervet et gyldigt — men tilhørende en lavprivilegeret bruger — klientcertifikat, modificerer det teknisk set og sender det til en sårbar applikation. Systemet læser det forkerte brugernavn fra certifikatet og giver angriberen adgang til en anden brugers konto, potentielt med langt højere rettigheder. Dette kan ske uden nogen form for brugerinteraktion fra offerets side.
Ofte stillede spørgsmål
Vi bruger ikke selv certifikater til login — er vi stadig i fare?
Sandsynligvis ikke direkte. Denne sårbarhed kræver specifikt, at jeres system bruger X.509-certifikater til at godkende brugere via Spring Security. Bruger I kun brugernavn/adgangskode eller anden login-metode, er I ikke umiddelbart sårbare over for dette angreb. Det er dog stadig en god idé at opdatere Spring Security, da fremtidige sårbarheder kan have bredere angrebsflader.
Hvad er et X.509-certifikat, og bruger vi det?
Et X.509-certifikat er et digitalt identitetsbevis — lidt ligesom et digitalt pas — der bruges til at bekræfte, hvem du er over for et it-system. Det bruges ofte i virksomhedsapplikationer, VPN-løsninger og API-kommunikation. Din IT-leverandør eller udvikler kan hurtigt fortælle dig, om jeres systemer anvender denne type godkendelse.
Kan vi afvente opdateringen, eller skal det ske med det samme?
Der er endnu ikke set aktiv udnyttelse af sårbarheden i praksis, og angrebet kræver teknisk kunnen samt et gyldigt certifikat. Vi anbefaler alligevel, at opdateringen planlægges inden for de næste 30 dage. Håndterer I særligt følsomme data eller har mange brugere med certifikatbaseret adgang, bør I handle hurtigere — gerne inden for en uge.
Kræver opdateringen nedetid på vores systemer?
Det afhænger af jeres infrastruktur og deploymentmiljø. En Spring Security-opdatering kræver typisk, at applikationen genstartes, hvilket kan betyde kortvarig nedetid på få minutter. Din udvikler eller IT-leverandør kan planlægge dette til en periode med lav aktivitet, f.eks. uden for arbejdstid, for at minimere forstyrrelser.
Hvordan ved vi, om nogen allerede har udnyttet sårbarheden mod os?
Bed din IT-ansvarlig gennemgå jeres loginlogfiler og kigge efter usædvanlige mønstre — f.eks. logins fra ukendte certifikater, logins på mærkelige tidspunkter eller adgang til ressourcer, som brugeren normalt ikke tilgår. Har I ikke et overblik over jeres logfiler, kan Auroa hjælpe med en gennemgang.
Gælder dette alle versioner af Spring Security?
Nej. Kun specifikke versioner er berørte: 5.7.0–5.7.24, 5.8.0–5.8.26, 6.3.0–6.3.17, 6.4.0–6.4.17 og 6.5.0–6.5.10. Tidligere versioner (f.eks. 5.6.x og ældre) er ikke nævnt som sårbare, men de modtager heller ikke sikkerhedsopdateringer og bør opgraderes af andre årsager. Kører I en af de nævnte versioner, skal I opdatere.
Ramte produkter
Vmware — Spring Security
< 5.7.25
Vmware — Spring Security
≥ 5.8.0, < 5.8.27
Vmware — Spring Security
≥ 6.3.0, < 6.3.18
Vmware — Spring Security
≥ 6.4.0, < 6.4.18
Vmware — Spring Security
≥ 6.5.0, < 6.5.11
CVSS-detaljer
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
SubjectDnX509PrincipalExtractor does not correctly handle certain malformed X.509 certificate CN values, which can lead to reading the wrong value for the username. In a carefully crafted certificate, this can lead to an attacker impersonating another user.
Affected versions:
Spring Security 5.7.0 through 5.7.24; 5.8.0 through 5.8.26; 6.3.0 through 6.3.17; 6.4.0 through 6.4.17; 6.5.0 through 6.5.10.
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.