Libmodulemd: libmodulemd: unbounded recursion when parsing nested xmd yaml
Get instant alerts when new vulnerabilities affect Red Hat Enterprise Linux 10 - before attackers find them.
A flaw was found in libmodulemd. When parsing module metadata, the xmd field is converted into nested GVariant values through recursive YAML mapping and sequence helpers without a recursion-depth or node-count limit. An attacker who can supply crafted modulemd YAML with deeply nested xmd content can cause stack exhaustion or excessive resource consumption, resulting in a denial of service.
Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.
AI-generated · claude-fable-5-1 · published by VulnTracker
No fixed libmodulemd package is recorded; monitor the Red Hat CVE page for an erratum and, until one ships, keep untrusted modulemd YAML out of tooling that parses module metadata on RHEL, OpenShift and Hardened Images hosts.
Inventory hosts and images with libmodulemd installed
All versions of Red Hat Enterprise Linux, OpenShift Container Platform and Red Hat Hardened Images are recorded as affected. List systems and container images carrying the libmodulemd package and note which tools on them parse module metadata (package managers, repository mirroring, build and compose pipelines).
Affected entries: redhat-enterprise-linux, redhat-openshift-container-platform, redhat-hardened-images, all_versions true.
Watch the Red Hat CVE page for a fixed package
Our records contain no fix row, so no fixed libmodulemd version or erratum can be named. Check the per-product fix state on the Red Hat CVE page and apply the libmodulemd update when an erratum is published for your RHEL release or OpenShift version, then rebuild or re-pull affected images.
https://access.redhat.com/security/cve/CVE-2026-92822Restrict module metadata to trusted, signed repositories
The flaw triggers when crafted modulemd YAML with deeply nested xmd content is parsed. Until a fix is available, do not point package tooling or mirroring jobs at untrusted repositories, and keep externally supplied module YAML out of build pipelines.
Description: deeply nested xmd content causes stack exhaustion or excessive resource consumption (CWE-674).
Treat the exposure as local denial of service when prioritising
The vector is local with no privileges required and availability-only impact, and a proof of concept is recorded. Prioritise shared build or repository-management hosts where untrusted users or feeds can introduce metadata; single-purpose hosts consuming only Red Hat repositories carry little practical exposure.
CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (6.2); SSVC exploitation: poc, automatable: no.
If you cannot apply the fix
Confine modulemd parsing to trusted, signed repository sources. This is inferred from the described attack condition, not a vendor-published mitigation.
No fix row is recorded, so whether a fixed libmodulemd build exists for any affected product is not established; the Red Hat CVE page is the only vendor source on file and its content is not summarised in our records. The affected entries name the products, not the libmodulemd package version, so the vulnerable package range is unknown. Neither reference is tagged Patch or Vendor Advisory. Exploitation in the wild is not recorded (EPSS 0.00117, percentile 0.016).
Guidance updated 2026-10-23
SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.
Get alerted
Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.