CVE-2026-56208: Kritisk fejl i libaom AV1-kodning
Fejl i AV1-videokodning kan få din server til at crashe eller overtages af angriber ved blot at sende en videofil.
Hvad er det?
CVE-2026-56208 er en sårbarhed i libaom — det officielle bibliotek til AV1-videokomprimering, som bruges i mange streaming-, videokonference- og mediebehandlingsløsninger. Fejlen ligger i en funktion kaldet Look-Ahead Processing (LAP), der hjælper kodningen med at planlægge fremad. Når en bestemt indstilling er aktiv (g_lag_in_frames ≥ 1), kan programmet komme til at skrive data 232 bytes uden for det tildelte hukommelsesområde (et såkaldt heap buffer overflow). Det sker på hvert enkelt videobillede efter det andet — ikke kun én gang. Resultatet kan være et programnedbrud eller i værste fald, at en angriber overtager serverprocessen.
Hvem rammer det?
Sårbarheden rammer dig, hvis din virksomhed benytter software der koder video til AV1-format — f.eks.:
- Videotranskoderings-tjenester (konvertering af uploadede videoer)
- WebRTC-baserede videokonferenceløsninger (fx hjemmeudviklede eller selvhostede)
- Medieservere og streamingplatforme
- Webbrowsere og apps der anvender libaom internt
Bruger du kun tredjeparts SaaS-løsninger som Teams, Zoom eller Google Meet, er det leverandørens ansvar at opdatere. Er du usikker, spørg din IT-leverandør om libaom er i brug i jeres infrastruktur.
Hvad kan ske?
En angriber der kan påvirke, hvordan jeres system koder video — f.eks. ved at uploade en særligt udformet videofil eller manipulere en WebRTC-session — kan:
- Nedbryde tjenesten (denial of service): Serveren crasher, og jeres videotjeneste går ned.
- Ødelægge data i hukommelsen: Fejlskrivningen overskrider nabodata på serveren, hvilket kan give uforudsigelig adfærd.
- Potentielt overtage serverprocessen: I avancerede angreb kan en hacker udnytte hukommelseskorrruptionen til at køre sin egen kode på jeres server — med de rettigheder som videotjenesten kører med.
Fortrolighed og integritet er let påvirkede (lav risiko), mens tilgængelighed er høj risiko ifølge CVSS-vurderingen.
Hvor alvorligt er det?
Sårbarheden er vurderet til CVSS 7.6 — Alvorlig. Det betyder:
- Angreb sker over netværket — angriberen behøver ikke fysisk adgang.
- Lav kompleksitet — det kræver ikke sofistikerede forberedelser.
- Ingen forhåndsrettigheder — hvem som helst kan forsøge angrebet.
- Brugerinteraktion kræves — systemet skal aktivt behandle den ondsindede video, f.eks. ved at en bruger uploader den eller starter en session.
Kravet om brugerinteraktion er det eneste der trækker scoren lidt ned. For virksomheder med offentligt tilgængelige videoupload- eller konferencefunktioner er risikoen reel og bør tages alvorligt.
Hvad gør jeg nu?
Gør følgende så hurtigt som muligt — prioriteret rækkefølge:
- Find ud af om I bruger libaom: Spørg din IT-leverandør eller udvikler om libaom-biblioteket indgår i jeres løsning — direkte eller som del af et tredjepartsprodukt.
- Opdatér libaom: Tjek om der er udgivet en ny version af libaom der lukker fejlen, og opdatér straks. Følg med på den officielle kildekode-repo (aomedia.googlesource.com).
- Opdatér afhængige softwarepakker: Programmer der bruger libaom internt (f.eks. FFmpeg, Chrome, Firefox) bør også opdateres til nyeste version.
- Begræns hvem der kan uploade og behandle video: Kræv login og valider filformater, så ikke alle og enhver kan trigge videokodning på jeres server.
- Overvåg for unormale nedbrud: Sæt alarmering op på uventede procesnedbrud i jeres videotjeneste — det kan være tegn på aktivt angrebsforsøg.
- Kontakt leverandøren: Bruger I en ekstern løsning der anvender libaom, kontakt leverandøren og spørg konkret om de er opdaterede mod CVE-2026-56208.
Opdatér inden for 7 dage
Vi anbefaler, at du inden for den næste uge får kortlagt om libaom er i brug i din IT-infrastruktur — og i så fald sørger for øjeblikkelig opdatering. Sårbarheden er teknisk set ikke svær at udnytte, og den rammer tilgængeligheden hårdt, hvilket kan betyde nedetid og tab af omdømme. Har du en ekstern IT-leverandør, så sæt det på dagsordenen i dag og bed om skriftlig bekræftelse på at de har håndteret det.
Tidslinje
Konkrete eksempler
Videoupload-tjeneste crasher
En angriber opretter en gratis konto på en platform der tilbyder videoupload og automatisk konverterer videoer til AV1-format. Angriberen uploader en normal videofil og starter konverteringsprocessen. Fordi libaom-fejlen udløses på hvert videobillede efter det andet, crasher serverprocessen gentagne gange. Tjenesten bliver utilgængelig for alle øvrige brugere — et klassisk denial-of-service-angreb uden behov for særlig teknisk viden.
WebRTC-videokonference misbruges til serverovertagelse
En virksomhed kører en selvhostet videokonferenceløsning baseret på WebRTC, hvor serveren koder videostreams i AV1. En angriber deltager i et møde og manipulerer sin videostream på en sådan måde, at serverens libaom-koder trigges til at skrive ud-af-grænse data i hukommelsen. Med den rette payload kan angriberen potentielt overskrive kritiske hukommelsesstrukturer og opnå fuld kontrol over serverprocessen — med de rettigheder som videoserveren kører med.
Automatiseret angreb mod offentlig medieserver
En angriber scanner internettet for kendte medieservere (fx FFmpeg-baserede løsninger) der accepterer indkommende videostreams. Ved at sende en strøm af videobilleder udnytter angriberen fejlen systematisk og automatiseret — først for at mappe hvilke servere der er sårbare via nedbrud, og dernæst for at forsøge egentlig kodekørsel på de identificerede mål.
Ofte stillede spørgsmål
Vi bruger ikke selv AV1-video — er vi alligevel i fare?
Muligvis. Mange populære programmer bruger libaom i baggrunden uden at det er synligt for brugeren — herunder webbrowsere som Chrome og Firefox, samt videobehandlingsværktøjer som FFmpeg. Spørg din IT-leverandør om I har software installeret der indeholder libaom.
Hvad er et heap buffer overflow, og hvorfor er det farligt?
Et heap buffer overflow opstår, når et program skriver mere data end der er plads til i et afsat hukommelsesområde — og derfor overskriver nabodata. Det er farligt fordi det kan få programmet til at crashe, opføre sig uforudsigeligt eller i værste fald give en angriber mulighed for at styre programmets opførsel og køre sin egen kode på serveren.
Kan vores firewall beskytte os mod dette angreb?
Kun delvist. En firewall kan begrænse hvem der har adgang til jeres videotjeneste, men hvis angriberen kan uploade en videofil eller starte en videosession via normale kanaler, vil trafikken typisk se legitim ud. Den egentlige beskyttelse kommer fra at opdatere selve softwaren.
Skal vi bekymre os om kodekørsel (remote code execution), eller er det kun nedbrud?
Begge dele er mulige. Det mest sandsynlige scenarie for de fleste angribere er at forårsage et serviceafbrud (nedbrud). Kodekørsel kræver mere teknisk raffinement, men kan ikke udelukkes — særligt hvis serveren kører videotjenesten med høje rettigheder. Opdatering er den eneste sikre løsning.
Hvad hvis vi ikke kan opdatere med det samme?
Som midlertidig foranstaltning kan I overveje at deaktivere eller begrænse adgangen til de funktioner der koder video til AV1-format, og kræve stærk autentifikation på videoupload-funktioner. Det eliminerer ikke risikoen, men reducerer angrebsfladen, mens I arbejder på en permanent løsning.
Hvem er ansvarlig for opdatering — os eller vores IT-leverandør?
Det afhænger af jeres aftale. Drifter I selv servere og software, er det jeres eget ansvar. Bruger I en managed service eller hostet løsning, er det leverandørens ansvar — men I bør proaktivt spørge og kræve skriftlig bekræftelse på at CVE-2026-56208 er lukket.
Ramte produkter
CVSS-detaljer
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H
CWE-svaghedstyper
Original NVD-beskrivelse (engelsk)
A heap buffer overflow vulnerability was found in libaom, the reference AV1 codec implementation. A flaw in the AV1 encoder’s Look-Ahead Processing (LAP) mode causes the first-pass stats ring buffer wrap-around guard to be bypassed when g_lag_in_frames is set to 1 or higher. This results in a 232-byte out-of-bounds write on every encoded frame after the second, corrupting adjacent heap objects. An attacker who can influence encoder configuration in a transcoding service or WebRTC session could exploit this to cause a denial of service (process crash) or potentially achieve code execution.
Brug for hjælp med jeres sikkerhed?
Vi hjælper SMV’er med at omsætte trusler som denne til konkrete handlingsplaner.
