CVE-2026-56208: Heap-fejl i libaom AV1-kodning
Fejl i libaoms AV1-encoder giver nedbrud eller mulig kodekørsel i transcoding- og WebRTC-tjenester. Deaktivér Look-Ahead Processing nu.
Hvad er det?
libaom er den officielle referenceimplementering af videokodeken AV1, som mange video- og streamingprodukter bruger til at komprimere video. CVE-2026-56208 er en fejl i encoderens Look-Ahead Processing, en funktion der analyserer kommende billeder for at forbedre kvaliteten. Når indstillingen g_lag_in_frames sættes til 1 eller derover, springes en sikkerhedstjek i en ringbuffer over. Resultatet er, at encoderen skriver 232 byte uden for den tildelte hukommelse for hvert billede efter det andet. Det korrupterer nærliggende data på heap-hukommelsen, det område i hukommelsen hvor programmet gemmer data dynamisk under kørsel.
Hvem rammer det?
Sårbarheden rammer alle systemer, der bruger libaom til at kode video i AV1-formatet med Look-Ahead Processing aktiveret. Det gælder transcoding-tjenester, der omdanner video fra ét format til et andet, videokonferenceløsninger baseret på WebRTC, streamingplatforme og medieservere. Danske virksomheder med egne videoportaler, webinarsystemer eller interne transcoding-pipelines, der bygger på libaom eller software der bruger biblioteket, for eksempel ffmpeg, GStreamer eller browserbaserede WebRTC-stakke, bør undersøge, om AV1-kodning med lag_in_frames sat til 1 eller derover er i brug.
Hvad kan ske?
En angriber, der kan påvirke encoderens konfiguration, for eksempel via en API der lader brugere styre kodningsindstillinger, kan udløse fejlen og få encoderprocessen til at gå ned. I praksis betyder det, at en videotjeneste eller transcoding-kø stopper med at virke, indtil processen genstartes. Fordi fejlen korrumperer heap-hukommelse, kan den i værste fald også bruges til at køre skadelig kode på serveren, selvom det kræver mere avanceret udnyttelse end blot at forårsage nedbrud.
Hvor alvorligt er det?
CVSS-scoren er 7,6 ud af 10, kategoriseret som alvorlig. Angrebet kræver ikke login eller særlige rettigheder, men kræver brugerinteraktion: nogen skal sætte eller påvirke encoderens g_lag_in_frames-indstilling til 1 eller derover, for eksempel gennem en konfigurerbar API eller uploadfunktion. Angrebet kan udføres over netværket og har lav kompleksitet. Konsekvensen for tilgængelighed er høj, mens konsekvensen for fortrolighed og integritet er lav. Der er ingen kendte tegn på aktiv udnyttelse af sårbarheden på offentliggørelsestidspunktet.
Hvad gør jeg nu?
Følgende skridt lukker hullet og begrænser risikoen, indtil en officiel rettelse er tilgængelig.
- Undgå at sætte g_lag_in_frames til 1 eller derover i jeres encoderkonfiguration, indtil libaom er opdateret. Sæt værdien til 0 for at deaktivere Look-Ahead Processing.
- Gennemgå alle systemer, der bruger libaom, ffmpeg eller GStreamer til AV1-kodning, og identificér hvor encoderindstillinger kan påvirkes af eksterne brugere.
- Begræns eller validér input til API’er og uploadfunktioner, der lader brugere styre kodningsparametre.
- Følg leverandørens sikkerhedsopdateringer til libaom og opdatér, så snart en rettet version er tilgængelig.
- Overvåg logfiler for gentagne nedbrud i encoder- eller transcoding-processer, som kan indikere forsøg på udnyttelse.
- Kontakt en sikkerhedsrådgiver, hvis I ikke selv kan vurdere, om jeres videoinfrastruktur er sårbar, eller hvis I opdager mistænkelig aktivitet.
Deaktivér LAP, indtil I har opdateret
Vi anbefaler, at I straks sætter g_lag_in_frames til 0 i alle systemer, der bruger libaom til AV1-kodning, indtil en rettet version er udgivet. Det er en midlertidig løsning, der lukker det konkrete angrebsscenarie uden at kræve en opdatering med det samme. I kan vente med selve softwareopdateringen til den er testet og udrullet gennem jeres normale opdateringscyklus, så længe workaround’en er aktiv. Har I eksterne brugere, der kan styre encoderindstillinger, bør I dog prioritere en gennemgang af adgangskontrol nu.
Tidslinje
Konkrete eksempler
Videokonferenceportal med brugerstyret kodning
Et dansk mediehus tilbyder en videokonferenceportal, hvor kunder via en API kan justere encoderindstillinger for deres livestreams. En ekstern bruger sætter g_lag_in_frames til 1 for at opnå bedre videokvalitet. Efter få minutters streaming går transcoding-processen ned gentagne gange, og portalen bliver utilgængelig for alle brugere, indtil driftsteamet deaktiverer Look-Ahead Processing.
Ofte stillede spørgsmål
Er vi ramt af denne sårbarhed?
I er potentielt ramt, hvis jeres systemer bruger libaom, ffmpeg eller GStreamer til at kode video i AV1-formatet, og hvis Look-Ahead Processing med lag_in_frames sat til 1 eller derover er aktiveret. Tjek jeres encoderkonfiguration og de biblioteker, jeres videoinfrastruktur bygger på.
Hvordan tjekker vi, om vi bruger libaom?
Undersøg jeres transcoding-pipeline, videokonferenceløsning og medieservere for afhængigheder af libaom, ffmpeg eller GStreamer. Mange systemer bruger disse biblioteker indirekte gennem tredjepartsprodukter, så det kan kræve en gennemgang af softwarelisten eller kontakt til jeres leverandør.
Kan vi vente til weekenden med at rette det?
Det er acceptabelt at vente med selve opdateringen, hvis I i mellemtiden deaktiverer Look-Ahead Processing ved at sætte g_lag_in_frames til 0. Uden den midlertidige løsning bør I ikke vente, hvis eksterne brugere kan påvirke encoderens konfiguration.
Kræver angrebet, at nogen klikker på noget?
Nej, men det kræver brugerinteraktion i teknisk forstand: en person eller et system skal sætte encoderens g_lag_in_frames-indstilling til 1 eller derover, for eksempel via en API eller uploadfunktion, før fejlen kan udløses.
Skal vi anmelde hændelsen, hvis vi bliver ramt?
Hvis udnyttelse fører til et sikkerhedsbrud med adgang til personoplysninger, skal I vurdere anmeldepligt efter databeskyttelsesforordningen over for Datatilsynet inden for 72 timer. Et rent nedbrud uden datalæk kræver som udgangspunkt ikke anmeldelse.
Hvad er en heap buffer overflow?
Det er en fejl, hvor et program skriver mere data til et hukommelsesområde end der er afsat plads til, så data flyder over i naboliggende hukommelse. Det kan få programmet til at gå ned eller i værste fald give en angriber mulighed for at afvikle skadelig kode.
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.
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.