CVE-2026-56208: libaom: heap overflow in AV1 encoder LAP mode
HIGHA heap buffer overflow in libaom's AV1 encoder look-ahead processing (LAP) mode lets an attacker who can influence encoder settings in a transcoding service or WebRTC session trigger a 232-byte out-of-bounds heap write on every frame encoded after the second, progressively corrupting adjacent memory. This isn't an AI-specific attack technique, but libaom ships as a transitive dependency inside 129 downstream packages, including several Red Hat AI Inference Server (rhaii/rhaiis) and OpenShift AI (rhoai) container images that back vLLM-based model-serving stacks — so remediation means rebuilding and redeploying those base images, not patching model code. Exploitation likelihood is currently low: EPSS sits at 0.275% (81st percentile among scored CVEs), there's no public PoC, no Nuclei template, and it isn't in CISA's KEV — but the flaw needs no privileges, only network reach and one user interaction (e.g., accepting a video/WebRTC call), and repeated per-frame corruption gives an attacker room to escalate from a crash to code execution with sufficient heap grooming. Track Red Hat's RHSA-2026:30814 and the upstream libaom fix (commit 243f8ae84b), and prioritize rebuilding any AI-serving container image that bundles libaom directly or transitively via Firefox/Thunderbird packages, rather than treating this as a routine codec patch.
What is the risk?
Network-exploitable with low attack complexity and no privileges required (CVSS 7.6, AV:N/AC:L/PR:N), but gated by required user interaction and by the fact the attacker needs some ability to influence encoder configuration (g_lag_in_frames >= 1) in a transcoding pipeline or WebRTC endpoint. Confirmed impact is heap memory corruption (CWE-122) causing reliable process crashes (A:H); code execution is described as 'potential' by the advisory rather than demonstrated, so treat RCE as plausible-but-unproven pending a public PoC. No KEV listing, no Nuclei template, and a low EPSS score (0.275%) indicate no evidence of active or imminent mass exploitation today, but the guard-bypass triggers on every frame after the second, making the bug trivially reproducible once an attacker controls one config parameter — a low bar compared to most memory-safety bugs. Overall: moderate near-term risk, elevated by the breadth of downstream exposure (129 dependents, 74 other CVEs in this package's history) rather than by current exploitation evidence.
How does the attack unfold?
What systems are affected?
How severe is it?
What is the attack surface?
What should I do?
1 step-
1) Patch libaom to the fixed version referenced in upstream commit 243f8ae84b and Red Hat advisory RHSA-2026:30814; track bugzilla #2490799 for downstream status. 2) Rebuild and redeploy any rhaii/rhaiis/rhoai or vLLM container image that bundles libaom (directly or via firefox/thunderbird) rather than waiting for a routine base-image refresh cycle. 3) If encoder configuration is exposed to end users or untrusted callers in any transcoding/WebRTC service, disable or hardcode g_lag_in_frames to 0 as an interim workaround to prevent LAP mode from activating. 4) Add input validation / allowlisting on any user-influenceable encoder parameters in transcoding services. 5) For detection, monitor transcoding/media-processing workers for unexplained segfaults or crash-loops correlated with video sessions of more than 2 encoded frames, and alert on anomalous heap-corruption crash signatures (ASan/heap-corruption detectors in staging can help validate exposure pre-patch).
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-56208?
A heap buffer overflow in libaom's AV1 encoder look-ahead processing (LAP) mode lets an attacker who can influence encoder settings in a transcoding service or WebRTC session trigger a 232-byte out-of-bounds heap write on every frame encoded after the second, progressively corrupting adjacent memory. This isn't an AI-specific attack technique, but libaom ships as a transitive dependency inside 129 downstream packages, including several Red Hat AI Inference Server (rhaii/rhaiis) and OpenShift AI (rhoai) container images that back vLLM-based model-serving stacks — so remediation means rebuilding and redeploying those base images, not patching model code. Exploitation likelihood is currently low: EPSS sits at 0.275% (81st percentile among scored CVEs), there's no public PoC, no Nuclei template, and it isn't in CISA's KEV — but the flaw needs no privileges, only network reach and one user interaction (e.g., accepting a video/WebRTC call), and repeated per-frame corruption gives an attacker room to escalate from a crash to code execution with sufficient heap grooming. Track Red Hat's RHSA-2026:30814 and the upstream libaom fix (commit 243f8ae84b), and prioritize rebuilding any AI-serving container image that bundles libaom directly or transitively via Firefox/Thunderbird packages, rather than treating this as a routine codec patch.
Is CVE-2026-56208 actively exploited?
No confirmed active exploitation of CVE-2026-56208 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-56208?
1) Patch libaom to the fixed version referenced in upstream commit 243f8ae84b and Red Hat advisory RHSA-2026:30814; track bugzilla #2490799 for downstream status. 2) Rebuild and redeploy any rhaii/rhaiis/rhoai or vLLM container image that bundles libaom (directly or via firefox/thunderbird) rather than waiting for a routine base-image refresh cycle. 3) If encoder configuration is exposed to end users or untrusted callers in any transcoding/WebRTC service, disable or hardcode g_lag_in_frames to 0 as an interim workaround to prevent LAP mode from activating. 4) Add input validation / allowlisting on any user-influenceable encoder parameters in transcoding services. 5) For detection, monitor transcoding/media-processing workers for unexplained segfaults or crash-loops correlated with video sessions of more than 2 encoded frames, and alert on anomalous heap-corruption crash signatures (ASan/heap-corruption detectors in staging can help validate exposure pre-patch).
What systems are affected by CVE-2026-56208?
This vulnerability affects the following AI/ML architecture patterns: model serving, multimodal preprocessing pipelines, containerized AI inference infrastructure.
What is the CVSS score for CVE-2026-56208?
CVE-2026-56208 has a CVSS v3.1 base score of 7.6 (HIGH). The EPSS exploitation probability is 0.35%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001 AI Software AML.T0049 Exploit Public-Facing Application Compliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker interacts with an AI service that accepts and transcodes user- or peer-supplied video — for example, a multimodal AI assistant that ingests video over WebRTC, or a content pipeline that transcodes uploaded video before feeding frames to a vision-language model. The attacker either supplies (or the service defaults to) an encoder configuration with g_lag_in_frames set to 1 or higher, enabling look-ahead processing, then submits a video stream long enough to encode more than two frames. Each subsequent frame triggers the bypassed ring-buffer wrap-around guard, causing a 232-byte out-of-bounds heap write that progressively corrupts adjacent heap objects. In the simplest case this crashes the transcoding/media worker process, causing a denial of service for the AI pipeline or WebRTC session; a more capable attacker could use the encoder's deterministic per-frame write pattern to groom the heap and attempt to redirect control flow for code execution within the transcoding process.
Weaknesses (CWE)
CWE-122 — Heap-based Buffer Overflow: A heap overflow condition is a buffer overflow, where the buffer that can be overwritten is allocated in the heap portion of memory, generally meaning that the buffer was allocated using a routine such as malloc().
- Pre-design: Use a language or compiler that performs automatic bounds checking.
- [Architecture and Design] Use an abstraction library to abstract away risky APIs. Not a complete solution.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:H References
- access.redhat.com/errata/RHSA-2026:30814 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:42875 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:47104 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:47105 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:51100 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:51146 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:54180 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:54181 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:54182 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:54185 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:54248 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:54249 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:54259 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:54339 vendor-advisory x_refsource_REDHAT
- access.redhat.com/security/cve/CVE-2026-56208 vdb-entry x_refsource_REDHAT
- aomedia.googlesource.com/aom/+/243f8ae84b
- bugzilla.redhat.com/show_bug.cgi issue-tracking x_refsource_REDHAT
- issues.chromium.org/issues/504317456
Timeline
Related Vulnerabilities
CVE-2024-9053 9.8 vllm: RCE via unsafe pickle deserialization in RPC server
Same package: vllm CVE-2024-11041 9.8 vllm: RCE via unsafe pickle deserialization in MessageQueue
Same package: vllm CVE-2026-25960 9.8 vllm: SSRF allows internal network access
Same package: vllm CVE-2025-47277 9.8 vLLM: RCE via exposed TCPStore in distributed inference
Same package: vllm CVE-2025-32444 9.8 vLLM: RCE via pickle deserialization on ZeroMQ
Same package: vllm