AI Threat Alert
CVE-2026-56209: libaom: arbitrary address write in AV1 SVC codec
HIGHA missing bounds check in libaom's SVC (Scalable Video Coding) layer-ID control path lets an attacker who can submit a crafted video frame inject an arbitrary pointer into the encoder's cyclic refresh map, causing the encoder to deterministically write roughly 1,200 attacker-influenced bytes to that address — no memory-leak needed, no luck required. It's not in CISA KEV, has no public exploit or Nuclei template, CISA's own SSVC decision is the lowest urgency tier (Track), and EPSS sits at 0.27% — so despite ranking in the 81st percentile among tracked CVEs, real-world exploitation likelihood today is low. The exposure is still worth tracking because of blast radius: libaom is bundled transitively into 129 downstream packages, including numerous Red Hat AI container base images (RHAI/RHAIIS/RHOAI) and several vLLM image variants, plus Firefox/Thunderbird. Patch by pulling the upstream fix (aomedia commit a93ba0ffaa) or the Red Hat errata (RHSA-2026:30814) and rebuild affected container/base images; in the meantime, audit whether any network-facing media-ingestion service in your AI stack actually has SVC mode enabled and disable it if unused, since this requires a fairly specific, non-default configuration to be reachable at all.
What is the risk?
Technically severe (CVSS 7.1, CWE-787 out-of-bounds write, fully deterministic write-what-where primitive) but low current real-world risk: not in CISA KEV, no public exploit code, no scanner/Nuclei coverage, CISA SSVC rated 'Track' (lowest urgency), and EPSS absolute probability is only 0.27%. Exploitation also requires a fairly narrow precondition — a network-facing libaom encoder with SVC explicitly enabled, plus user interaction — which is not a default or common configuration. The main risk driver is supply-chain breadth: libaom ships transitively inside 129 downstream packages, including multiple Red Hat AI container base images and vLLM variants, so exposure assessment requires inventory work rather than direct AI-specific attack-surface analysis.
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 version referenced in RHSA-2026:30814 / upstream commit aomedia.googlesource.com/aom/+/a93ba0ffaa. 2) Rebuild and redeploy any RHAI/RHAIIS/RHOAI base or workbench images and vLLM container variants once updated RPMs/packages are available; don't rely on old cached layers. 3) Inventory whether any network-facing AI media-ingestion or transcoding service actually enables SVC — if not required, disable it as an immediate workaround. 4) For services that can't be patched immediately, front them with strict input validation on submitted video/image frames and isolate the encoding process (sandbox/seccomp, non-privileged user, resource limits) to contain a potential write primitive. 5) Monitor for unexplained encoder crashes or segfaults in transcoding services as a DoS/exploitation-attempt indicator. 6) Verify remediation via
rpm -q libaomor container image manifest diff against the patched build.
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-56209?
A missing bounds check in libaom's SVC (Scalable Video Coding) layer-ID control path lets an attacker who can submit a crafted video frame inject an arbitrary pointer into the encoder's cyclic refresh map, causing the encoder to deterministically write roughly 1,200 attacker-influenced bytes to that address — no memory-leak needed, no luck required. It's not in CISA KEV, has no public exploit or Nuclei template, CISA's own SSVC decision is the lowest urgency tier (Track), and EPSS sits at 0.27% — so despite ranking in the 81st percentile among tracked CVEs, real-world exploitation likelihood today is low. The exposure is still worth tracking because of blast radius: libaom is bundled transitively into 129 downstream packages, including numerous Red Hat AI container base images (RHAI/RHAIIS/RHOAI) and several vLLM image variants, plus Firefox/Thunderbird. Patch by pulling the upstream fix (aomedia commit a93ba0ffaa) or the Red Hat errata (RHSA-2026:30814) and rebuild affected container/base images; in the meantime, audit whether any network-facing media-ingestion service in your AI stack actually has SVC mode enabled and disable it if unused, since this requires a fairly specific, non-default configuration to be reachable at all.
Is CVE-2026-56209 actively exploited?
No confirmed active exploitation of CVE-2026-56209 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-56209?
1) Patch libaom to the version referenced in RHSA-2026:30814 / upstream commit aomedia.googlesource.com/aom/+/a93ba0ffaa. 2) Rebuild and redeploy any RHAI/RHAIIS/RHOAI base or workbench images and vLLM container variants once updated RPMs/packages are available; don't rely on old cached layers. 3) Inventory whether any network-facing AI media-ingestion or transcoding service actually enables SVC — if not required, disable it as an immediate workaround. 4) For services that can't be patched immediately, front them with strict input validation on submitted video/image frames and isolate the encoding process (sandbox/seccomp, non-privileged user, resource limits) to contain a potential write primitive. 5) Monitor for unexplained encoder crashes or segfaults in transcoding services as a DoS/exploitation-attempt indicator. 6) Verify remediation via `rpm -q libaom` or container image manifest diff against the patched build.
What systems are affected by CVE-2026-56209?
This vulnerability affects the following AI/ML architecture patterns: multimodal data ingestion pipelines, model serving / inference infrastructure, training pipelines (video/image datasets), AI development workbenches (RHOAI/Jupyter).
What is the CVSS score for CVE-2026-56209?
CVE-2026-56209 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.33%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0010.001 AI Software AML.T0029 Denial of AI Service AML.T0049 Exploit Public-Facing Application Compliance Controls Affected
What are the technical details?
Original Advisory
An arbitrary address write vulnerability was found in libaom, the reference AV1 codec implementation. A missing bounds check in the SVC (Scalable Video Coding) layer ID control function allows an attacker to inject an arbitrary pointer into the cyclic refresh map field via crafted image pixel values. The encoder then writes approximately 1,200 bytes at the attacker-controlled address. This is fully deterministic and does not require a separate information leak. An attacker who can supply frames to a network-facing libaom encoder with SVC enabled could exploit this for denial of service or potential code execution.
Exploitation Scenario
An AI platform ingests user- or partner-submitted video/image content — for example, a multimodal training data pipeline or a video-analytics inference service — using a libaom-based encoder configured with SVC. An attacker submits a video frame with crafted pixel values that reach the SVC layer-ID control function; the missing bounds check lets those values be interpreted as a pointer and injected into the encoder's cyclic refresh map field. When the encoder subsequently writes its ~1,200-byte cyclic refresh map, it writes attacker-influenced data to the attacker-controlled address deterministically, with no separate info leak required. Depending on what gets overwritten, this crashes the transcoding process (denial of service to the ingestion pipeline) or, with more precise targeting of control data, could be leveraged toward code execution on the host running the AI 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:L/PR:N/UI:R/S:U/C:N/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: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-56209 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/503993984
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