Red Hat published CVE-2026-84042 on Thursday, September 10, 2026, describing a flaw in crun — the OCI container runtime that Podman uses by default on Red Hat and Fedora systems — that lets a container image run code as root on the host. The record carries no fixed version. Red Hat’s remediation is a sentence of advice, and the affected-products list attached to the record names exactly one thing: Red Hat’s own hardened images.
What happened
The Red Hat Bugzilla entry, bug 2531222, was created at 1:50 a.m. UTC on September 10, 2026 under the title “CVE-2026-84042 crun: rootful krun with passt executes container payload as host root.” The CVE record reached NVD at 9:17 a.m. UTC the same morning — 4:17 a.m. Central — with published and lastModified identical, meaning nothing has been revised since it landed.
The description, from Red Hat as the assigning CNA, reads in full:
“A flaw was found in crun. When crun is built with libkrun and a container is started rootful with passt networking (krun.use_passt), crun can execute attacker-controlled payload from the container image with host root privileges. The issue is a regression in crun 1.29. It affects crun >= 1.29”
Red Hat rates it Important and scores it 7.8 on CVSS v3.1, vector AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H, classified CWE-269. The scope metric is Changed, which is the part of the vector doing the work: the impact lands outside the container that was compromised.
There is no patched release. Red Hat’s mitigation section says, verbatim: “Do not run untrusted images with krun and passt until a fixed crun is released.” The Bugzilla entry states that an upstream patch exists but that no official fixed release has been published, and that both 1.29 and 1.29.1 are affected. The bug’s status this morning is NEW.
That matches what the upstream tree shows. Tags 1.29 and 1.29.1 both resolve on GitHub’s raw content host; 1.30 returns 404. The NEWS file on the main branch is byte-for-byte identical to the copy at tag 1.29.1 — same MD5, 04bf7ab875f55345b8a487b46428f6d8 — so nothing has been added to the changelog since that release, and no unreleased entry mentions this flaw. crun’s NEWS names prior security fixes by CVE ID in five separate release entries, including CVE-2026-47766 in 1.28 and CVE-2026-30892 in 1.27. This one is not among them. The containers/crun repository has also published no GitHub Security Advisory for it; the most recent advisory there is GHSA-7vwr-4279-7gq5, dated May 27, 2026, for a different bug.
The krun.use_passt annotation named in the description is not old. crun’s release notes introduce it in 1.27.1: “krun: add support for passt-based networking in microVMs via the krun.use_passt annotation.” The feature is roughly five months old, and the regression arrived two releases later.
Why it matters
Start with who is exposed, because it is a smaller group than “everyone running containers” and a more interesting one. libkrun is the library that lets crun start a container inside a lightweight virtual machine rather than as a namespaced process on the host. Operators reach for it precisely when process isolation is not considered good enough — untrusted workloads, multi-tenant build farms, anything where the operator has already decided a shared kernel is too much trust. krun.use_passt is the opt-in that gives those microVMs user-mode networking.
So the population at risk is not the careless one. It is the set of operators who deliberately chose the strongest isolation the runtime offers, and who, by Red Hat’s own description, now get a container image executing with host root privileges through the path they added for safety. That inversion is the story: the hardening feature is the vulnerable surface, and the mitigation Red Hat offers — do not run untrusted images — is the exact thing libkrun exists to make survivable.
The second problem is the record itself. The description says the flaw affects crun >= 1.29, which is a statement about upstream software with no vendor qualifier. The record’s affected-products array says something much narrower. It has one entry: vendor Red Hat, product Red Hat Hardened Images, package crun, CPE cpe:/a:redhat:hummingbird:1. Nothing in it covers upstream crun, Fedora’s crun, a crun built into a third-party container host, or a crun vendored inside another product.
NVD makes that gap wider rather than narrower. As of this morning the record’s vulnStatus is "Received" and the JSON contains no configurations array at all — no CPE matches, no version ranges, nothing for a scanner to key on. A vulnerability-management tool asking NVD “is my crun affected” gets no answer, and a tool matching on the CNA’s affected block gets “only if you run Red Hat Hardened Images.” Both answers are wrong for a Fedora host, and the prose sitting a few fields away in the same record says so.
This is a recurring shape here, and it is worth naming plainly: the human-readable half of a CVE record and the machine-readable half disagree about who is affected, and automated remediation reads only the machine-readable half. It is the same failure mode that leaves a no-fix flaw invisible in a dashboard while the advisory text says a container can take the host. Severity Daily has covered two other no-fixed-version disclosures in the past week; what is different here is that the scoping error compounds it.
Third, the score. 7.8 with AV:L and AC:H is defensible metric by metric — the attacker needs a local foothold in the sense that they must get their image run, and the conditions are specific. But the outcome is host root from container content, and a reader triaging by number alone will sort this below several of this week’s remote-but-authenticated 8.8s. The vector is the honest part of the record; the number is the part that will get used.
What to do
Determine whether libkrun is compiled into the crun you actually run. This is a build-time option, not a runtime one, so the answer depends on your distribution’s packaging rather than your configuration. Then search your container configurations, Podman invocations, and any orchestration templates for the string krun.use_passt. If it appears nowhere, this flaw does not reach you.
Where it does appear, apply Red Hat’s mitigation as written and stop running untrusted or externally sourced images under krun with passt until a fixed crun ships. Watch the Red Hat CVE page and Bugzilla 2531222 rather than a scanner, because the scanner has nothing to match on.
If you build crun yourself and cannot suspend the workload, 1.28 predates the regression. That is an inference from Red Hat’s own statement that the issue is a regression in 1.29, not a Red Hat recommendation, and it costs you the mount-handling and cgroup fixes that shipped in 1.29 and 1.29.1. Weigh it accordingly.
Finally, do not close this one out on the basis of a clean scan. There is no version data in NVD to scan against.
Sourcing note
Checked directly: the NVD API record for CVE-2026-84042 (description, CVSS vector and score, CWE, reference list, and the vulnStatus value "Received"); the CVE Program record for the same CVE, which is where the single-entry affected array and the cpe:/a:redhat:hummingbird:1 identifier come from; Red Hat’s CVE page for the severity rating and the mitigation sentence; Red Hat Bugzilla 2531222 for the title, the 1:50 a.m. UTC creation time, the NEW status, and the statements that 1.29.1 is affected and no fixed release exists; the containers/crun GitHub Security Advisories listing; and the crun NEWS file retrieved from both tag 1.29.1 and main via raw.githubusercontent.com, which is how the identical-changelog and no-CVE-entry findings were confirmed. Tag existence for 1.29, 1.29.1, and 1.30 was tested the same way.
Could not reach: GitHub’s REST API and its /commits and /pulls views were unavailable to this container, so the upstream patch the Bugzilla entry refers to could not be located or read. GitHub’s release listing rendered inconsistently and its dates are not reported here for that reason; the release dates of 1.29 and 1.29.1 are therefore not stated in this story. Package registries that would have supplied those dates were also unreachable.
Unresolved: Red Hat has not identified which change introduced the regression. Comparing src/libcrun/handlers/krun.c between tags 1.28 and 1.29 shows only one functional change to the passt launcher — the addition of a --no-map-gw argument — and the file is byte-identical between 1.29 and 1.29.1. The launch call itself, an unqualified execvp ("passt", passt_argv), is unchanged in main as well. That is a static reading of published source, not a reproduction, and it does not establish the mechanism: 1.29 also rewrote parts of crun’s mount handling, and the fault may lie there. It does support Red Hat’s statement that no fixed release exists. Whether products that bundle crun are affected, and which ones, is not addressed anywhere in the record.