CVE-2026-81702: Kritisk fejl i openssl_encrypt
Kritisk fejl i openssl_encrypt lader angribere bytte offentlige nøgler ud og aflytte krypteret kommunikation uden at blive opdaget.
Hvad er det?
openssl_encrypt er et softwarebibliotek, som mange systemer bruger til at kryptere data og verificere digitale signaturer. I versioner før 1.4.9 er der en alvorlig fejl: Når programmet indlæser identiteter fra en fil kaldet identity.json, kontrollerer det ikke fingeraftryk (en unik digital identifikator) korrekt. Det betyder, at en angriber kan udskifte en legitim offentlig nøgle (den nøgle, der bruges til at kryptere data til en bestemt modtager) med sin egen nøgle — uden at systemet opdager det. Resultatet er, at krypterede beskeder i virkeligheden sendes til angriberen, og falske signaturer kan fremstå som gyldige.
Hvem rammer det?
Sårbarheden rammer alle virksomheder og systemer, der bruger openssl_encrypt i en version ældre end 1.4.9, og som benytter bibliotekets identitetshåndtering via identity.json. Det kan være:
- Webapplikationer og API’er, der bruger openssl_encrypt til at kryptere kommunikation
- Interne systemer, der udveksler krypterede filer eller beskeder
- Udviklere og leverandører, der har bygget løsninger oven på biblioteket
Hvis du ikke ved, om din software bruger openssl_encrypt, bør du spørge din IT-leverandør.
Hvad kan ske?
Hvis en angriber udnytter fejlen, kan følgende ske:
- Aflytning af krypteret kommunikation: Data, du tror er krypteret sikkert til modtageren, sendes i stedet til angriberen.
- Forfalskning af digitale signaturer: Angriberen kan få systemet til at acceptere falske signaturer som gyldige, hvilket underminerer hele tilliden til din digitale kommunikation.
- Stille og rolig angreb: Angrebet efterlader ingen tydelige spor — hverken systemet eller brugerne opdager, at noget er galt.
- Datatyveri og brud på fortrolighed: Følsomme oplysninger som kontrakter, kundedata eller interne beskeder kan havne hos uvedkommende.
Hvor alvorligt er det?
Sårbarheden er vurderet til 9,8 ud af 10 (Kritisk) af det internationale CVSS-scoringssystem. Det er den næsthøjeste score, der kan gives. Karakteren afspejler, at:
- Angrebet kan udføres over internettet uden forudgående adgang eller særlige rettigheder
- Det kræver ingen handling fra dig eller dine medarbejdere (ingen klik på links osv.)
- Alle tre kerneværdier — fortrolighed, integritet og tilgængelighed — er fuldt kompromitteret ved et vellykket angreb
Denne type fejl (CWE-345: utilstrækkelig verifikation af datas oprindelse) er særlig farlig, fordi den undergraver selve grundlaget for kryptografi — tilliden til, at du kommunikerer med den rigtige modtager.
Hvad gør jeg nu?
Handl hurtigt. Følg disse trin for at beskytte din virksomhed:
- Find ud af, om du er berørt: Spørg din IT-ansvarlige eller leverandør, om jeres systemer bruger openssl_encrypt, og hvilken version der er installeret. Versioner før 1.4.9 er sårbare.
- Opdater straks til version 1.4.9 eller nyere: Dette er den eneste fulde løsning. Opdateringen lukker hullet ved at sikre korrekt validering af fingeraftryk.
- Gennemgå jeres identity.json-filer: Kontrollér, om uautoriserede nøgler er blevet tilføjet. Din IT-leverandør kan hjælpe med dette.
- Revurdér krypteret kommunikation fra den sårbare periode: Hvis I har brugt openssl_encrypt i en sårbar version, bør I overveje, om følsomme data kan være kompromitteret.
- Skift berørte krypteringsnøgler: For en sikkerheds skyld bør alle nøgler, der har været håndteret af det sårbare system, fornyes.
- Orientér relevante parter: Hvis I udveksler krypteret kommunikation med samarbejdspartnere eller kunder via dette bibliotek, bør I informere dem om situationen.
Opdatér inden for 24–48 timer
Vi anbefaler, at du behandler denne sårbarhed som en akut situation og opdaterer openssl_encrypt til version 1.4.9 eller nyere inden for de næste 24–48 timer. Fejlen er teknisk nem at udnytte for en angriber, og den giver adgang til det mest grundlæggende lag af jeres sikkerhed: kryptering og identitetsverifikation. Kontakt din IT-leverandør i dag, og bed dem bekræfte, at opdateringen er gennemført og at identity.json er kontrolleret for uautoriserede ændringer.
Tidslinje
Konkrete eksempler
Angriberen overtager krypteret e-mailkommunikation
En angriber identificerer, at en virksomheds interne system bruger openssl_encrypt i en sårbar version til at udveksle krypterede beskeder. Ved at få adgang til eller manipulere identity.json — fx via en anden sårbarhed eller en kompromitteret server — erstatter angriberen virksomhedens offentlige nøgle med sin egen. Fremover modtager angriberen alle krypterede beskeder beregnet til virksomheden og kan læse dem i klartekst, mens kommunikationen tilsyneladende fungerer normalt.
Falsk signatur godkendes i dokumenthåndtering
En virksomhed bruger openssl_encrypt til at verificere digitale signaturer på kontrakter og fakturaer. En angriber bytter den betroede parts nøgle ud i identity.json og sender derefter forfalskede dokumenter med sin egen signatur. Systemet verificerer signaturen som gyldig, og virksomheden godkender og betaler en falsk faktura uden at opdage, at underskriften ikke stammer fra den forventede afsender.
Forsyningskædeangreb via kompromitteret softwareleverandør
En softwareleverandør, der leverer et system til mange SMV’er, bruger openssl_encrypt til at håndtere licensnøgler og opdateringsmekanismer. En angriber kompromitterer leverandørens identity.json og indsætter sin egen nøgle. Efterfølgende kan angriberen distribuere falske softwareopdateringer, som klientvirksomhedernes systemer accepterer som legitime — og dermed installere skadelig software hos alle leverandørens kunder på én gang.
Ofte stillede spørgsmål
Hvad er en 'offentlig nøgle', og hvorfor er det et problem, at den kan byttes ud?
En offentlig nøgle er en digital kode, der bruges til at kryptere data, så kun den tiltænkte modtager kan læse dem. Forestil dig det som en særlig lås, som kun modtageren har nøglen til at åbne. Hvis en angriber kan bytte låsen ud med sin egen, vil al krypteret post i stedet blive sendt til angriberen — og I opdager det ikke, fordi systemet stadig tror, det bruger den rigtige lås.
Kan jeg se, om nogen allerede har udnyttet sårbarheden i vores system?
Det er desværre svært at opdage, fordi angrebet netop er designet til at se normalt ud. Der er ingen alarmerende fejlmeddelelser eller tydelige spor. Din IT-leverandør kan gennemgå logfiler og sammenligne de nuværende nøgler i identity.json med kendte, godkendte nøgler for at lede efter uregelmæssigheder. Jo hurtigere I opdaterer, jo kortere er det potentielle angrebsvindue.
Er vi automatisk sikre, hvis vi bruger HTTPS på vores hjemmeside?
Ikke nødvendigvis. HTTPS beskytter kommunikationen mellem din browser og en server, men denne sårbarhed handler om, hvad der sker inde i applikationen — når openssl_encrypt bruges til at håndtere nøgler og identiteter i jeres systemer eller software. De to lag er uafhængige af hinanden, og HTTPS løser ikke dette problem.
Hvad sker der, hvis vi ikke opdaterer med det samme?
Så risikerer I, at krypteret kommunikation kan aflyttes, at falske identiteter kan godkendes, og at I ikke opdager det. Jo længere tid der går, jo større er risikoen for, at en angriber udnytter hullet. Da sårbarheden scorer 9,8 ud af 10 i alvorlighed og ikke kræver nogen form for adgang i forvejen, er tidsvinduet for angribere bredt.
Hvem har ansvaret for at opdatere — os eller vores IT-leverandør?
Ansvaret afhænger af jeres aftale. Hvis I har en driftsaftale, bør IT-leverandøren opdatere for jer — men I bør aktivt rykke dem og bede om skriftlig bekræftelse på, at opdateringen er gennemført. Bruger I interne IT-ressourcer, er ansvaret jeres eget. Uanset hvad er det vigtigt, at nogen handler hurtigt.
Gælder dette alle versioner af openssl_encrypt?
Nej. Kun versioner ældre end 1.4.9 er sårbare. Har I allerede version 1.4.9 eller nyere installeret, er I beskyttet mod netop denne sårbarhed. Bed jeres IT-ansvarlige bekræfte den præcise versionsnummer på alle systemer, der bruger biblioteket.
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
openssl_encrypt before 1.4.9 fails to re-derive and validate fingerprints when loading identities from identity.json, allowing attackers to substitute public keys in identity stores. Attackers can replace legitimate public keys with their own while maintaining the claimed fingerprint, enabling silent key substitution where encryption uses attacker keys and signature verification appears valid.
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.