AI Threat Alert
CVE-2026-56211: libaom: AV1 SVC OOB write enables RCE
HIGH PoC AVAILABLEA memory-corruption bug in libaom, the AV1 video codec, lets an attacker who can submit crafted video frames to an SVC-enabled encoding service corrupt an internal pointer and eventually execute arbitrary commands on the host. This matters less because it's an AI-specific bug and more because it's a supply-chain bug sitting inside AI infrastructure: the vulnerable package ships transitively in Red Hat AI Inference Server and OpenShift AI container images across every accelerator variant (CUDA, ROCm, Gaudi, Neuron, TPU, Spyre, CPU) plus Firefox and Thunderbird, giving it a footprint of 129 tracked downstream dependents in a package with 74 other historical CVEs. The actual exploitation bar is high — CVSS AC:H and UI:R, EPSS sits at just 0.4% (68th percentile), it's not in CISA KEV, and there is no public exploit or Nuclei template — because the attacker must first brute-force ASLR via a crash oracle against a fork-based service before hijacking control flow. Treat this as a patch-and-verify item rather than a fire drill: pull the RHSA-2026:30814 fix or the upstream aomedia commit (a93ba0ffaa) into any RHAIIS/RHOAI images you run, and confirm none of your video-ingestion or transcoding services expose AV1 SVC encoding to untrusted input in the meantime.
What is the risk?
Severity is high on paper (CVSS 7.1, CWE-787 out-of-bounds write leading to full command execution) but real-world exploitability is currently low. Attack complexity is rated high and user interaction is required, EPSS is only 0.4% (68th percentile — not a top-tier target), there is no CISA KEV listing, no public exploit code, and no Nuclei scanning template. Exploitation additionally depends on a fairly specific architecture: a fork-based service that accepts attacker-supplied video, has AV1 SVC encoding enabled, and permits enough repeated requests for an attacker to brute-force ASLR via a crash oracle. The residual risk driver is exposure breadth, not exploit maturity — libaom is bundled into 129 downstream packages/images, and the aom codebase has a long history of memory-safety CVEs (74 others), suggesting this class of bug will recur.
How does the attack unfold?
What systems are affected?
How severe is it?
What is the attack surface?
What should I do?
1 step-
Patch libaom to the version containing upstream commit a93ba0ffaa, or apply the vendor fix in RHSA-2026:30814 for RHAIIS/RHOAI images, then rebuild and redeploy affected containers rather than patching in place. Inventory which of your RHAIIS/RHOAI image variants and any Firefox/Thunderbird installs are in use and prioritize the ones exposed to untrusted video input. If immediate patching isn't possible, disable or restrict AV1 SVC encoding for any service accepting attacker-supplied video, and avoid fork-based worker models for untrusted encoding jobs where a crash oracle can be used to brute-force ASLR. For detection, monitor for repeated crash/restart cycles on video-encoding worker processes (a signature of ASLR brute-forcing) and alert on anomalous process respawn rates.
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-56211?
A memory-corruption bug in libaom, the AV1 video codec, lets an attacker who can submit crafted video frames to an SVC-enabled encoding service corrupt an internal pointer and eventually execute arbitrary commands on the host. This matters less because it's an AI-specific bug and more because it's a supply-chain bug sitting inside AI infrastructure: the vulnerable package ships transitively in Red Hat AI Inference Server and OpenShift AI container images across every accelerator variant (CUDA, ROCm, Gaudi, Neuron, TPU, Spyre, CPU) plus Firefox and Thunderbird, giving it a footprint of 129 tracked downstream dependents in a package with 74 other historical CVEs. The actual exploitation bar is high — CVSS AC:H and UI:R, EPSS sits at just 0.4% (68th percentile), it's not in CISA KEV, and there is no public exploit or Nuclei template — because the attacker must first brute-force ASLR via a crash oracle against a fork-based service before hijacking control flow. Treat this as a patch-and-verify item rather than a fire drill: pull the RHSA-2026:30814 fix or the upstream aomedia commit (a93ba0ffaa) into any RHAIIS/RHOAI images you run, and confirm none of your video-ingestion or transcoding services expose AV1 SVC encoding to untrusted input in the meantime.
Is CVE-2026-56211 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-56211, increasing the risk of exploitation.
How to fix CVE-2026-56211?
Patch libaom to the version containing upstream commit a93ba0ffaa, or apply the vendor fix in RHSA-2026:30814 for RHAIIS/RHOAI images, then rebuild and redeploy affected containers rather than patching in place. Inventory which of your RHAIIS/RHOAI image variants and any Firefox/Thunderbird installs are in use and prioritize the ones exposed to untrusted video input. If immediate patching isn't possible, disable or restrict AV1 SVC encoding for any service accepting attacker-supplied video, and avoid fork-based worker models for untrusted encoding jobs where a crash oracle can be used to brute-force ASLR. For detection, monitor for repeated crash/restart cycles on video-encoding worker processes (a signature of ASLR brute-forcing) and alert on anomalous process respawn rates.
What systems are affected by CVE-2026-56211?
This vulnerability affects the following AI/ML architecture patterns: multimodal input pipelines, video/media preprocessing, container base images, model serving infrastructure.
What is the CVSS score for CVE-2026-56211?
CVE-2026-56211 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.45%.
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 remote code execution vulnerability was found in libaom, the reference AV1 codec implementation. Insufficient bounds validation in the AV1 encoder's SVC (Scalable Video Coding) layer ID control allows an attacker to supply crafted video frame pixels that overlap with internal encoder layer context structures. In fork-based video processing services, an attacker can use this to hijack the cyclic refresh map pointer, brute-force the process base address via a crash oracle, and redirect control flow to achieve arbitrary command execution. Exploitation requires the target service to use libaom with SVC encoding enabled and accept attacker-supplied video frames.
Exploitation Scenario
An attacker identifies a network-facing service — for example a video ingestion or transcoding step feeding a multimodal AI pipeline — that uses libaom with AV1 SVC encoding enabled and accepts user-supplied video. The attacker crafts video frame pixels that intentionally overlap with the encoder's internal SVC layer context structures, triggering an out-of-bounds write that lets them hijack the cyclic refresh map pointer. Because the service processes each request in a freshly forked worker with a predictable base layout, the attacker repeatedly submits requests to crash workers and observe crash behavior, using this crash oracle to brute-force the process's ASLR base address. Once the base address is known, the attacker redirects control flow through the hijacked pointer to execute arbitrary OS commands on the host running the encoding/inference service.
Weaknesses (CWE)
CWE-787 — Out-of-bounds Write: The product writes data past the end, or before the beginning, of the intended buffer.
- [Requirements] Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, many languages that perform their own memory management, such as Java and Perl, are not subject to buffer overflows. Other languages, such as Ada and C#, typically provide overflow protection, but the protection can be disabled by the programmer. Be wary that a language's interface to native code may still be subject to overflows, even if the language itself is theoretically safe.
- [Architecture and Design] Use a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. Examples include the Safe C String Library (SafeStr) by Messier and Viega [REF-57], and the Strsafe.h library from Microsoft [REF-56]. These libraries provide safer versions of overflow-prone string-handling functions.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/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:51100 vendor-advisory x_refsource_REDHAT
- access.redhat.com/errata/RHSA-2026:51146 vendor-advisory x_refsource_REDHAT
- access.redhat.com/security/cve/CVE-2026-56211 vdb-entry x_refsource_REDHAT
- aomedia.googlesource.com/aom/+/a93ba0ffaa
- bugzilla.redhat.com/show_bug.cgi issue-tracking x_refsource_REDHAT
- issues.chromium.org/issues/503993985
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