📢 New post: When the KEV Item Is the Sandbox Itself: CVE-2022-0492 and the Floor Under Your Agents · 📝 Also fresh: Is It Even in Your Boundary? CVE-2026-0257 and the Question a KEV Clock Asks First · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
AI SecurityFedRAMPConMonCISA

When the KEV Item Is the Sandbox Itself: CVE-2022-0492 and the Floor Under Your Agents

The last few KEV clocks we walked through here had a clear villain. A Cisco SD-WAN control plane. A Langflow account-takeover chain. A PAN-OS GlobalProtect bypass. In each case the vulnerable thing was a product — something you could point at on a diagram and ask "do we run that?"

The one CISA added on June 2 is different, and it's why it's worth stopping on even though it scrolled past as the unglamorous entry next to a couple of flashier bugs. CVE-2022-0492 is a privilege-escalation flaw in the Linux kernel's cgroups code — and cgroups isn't a product you run. It's the floor underneath the thing you run. Specifically, it's part of the floor underneath every container, which means it's part of the floor underneath the sandbox a lot of teams are quietly trusting to hold their AI agents.

So this isn't a "patch the appliance" post. It's a "look at what your sandbox actually rests on" post.

The bug, briefly

cgroups — control groups — is the kernel feature that lets you partition CPU, memory, and process accounting. It's one of the two primitives (the other being namespaces) that containers are built from. One of its older features is the release agent: a cgroup can carry a notify_on_release flag and a release_agent file pointing at a binary, and when the last process in that cgroup exits, the kernel runs that binary — as root, with all capabilities, in the host's initial namespace.

That's a lot of power for the kernel to hand out, so writing to release_agent is supposed to require CAP_SYS_ADMIN in the initial user namespace. The bug, in cgroup_release_agent_write in kernel/cgroup/cgroup-v1.c, is a missing check: the code never confirmed the caller held that capability in init_user_ns. So a process with CAP_SYS_ADMIN in a non-initial user namespace — which is to say, a sufficiently privileged container, or any unprivileged process that can create its own user and cgroup namespaces — could mount cgroupfs, write a path of its choosing into release_agent, empty the cgroup, and have the kernel execute that path as root on the host.

It carries a CVSS of 7.0, and Oracle's not in the picture here — the fix landed in mainline Linux back at 5.17-rc3 (commit 24f6008564), which adds the capability check that should have been there. The CVE is from early 2022. What changed on June 2 is that CISA now has evidence it's being exploited in the wild, four years on, and BOD 22-01's standard three-week window puts the federal due date around June 23.

The important caveat, and it's a real one: this is not a universal break. The default hardening in most container runtimes stops it cold — a baseline AppArmor, SELinux, or seccomp profile blocks either the cgroupfs mount or the release_agent write. Containers escape through this bug only when they're running with permissive profiles, extra capabilities, or --privileged. Which is exactly why it belongs in a conversation about agents, because that's precisely the population of containers most likely to have been loosened.

Why this one is an agent-security post

Here's the pattern we keep seeing. A team stands up an agent that needs to do things — run generated code, execute a tool, shell out to a build. The reasonable instinct is to contain it: "we don't let the agent touch the host, we run it in a container." That sentence does a lot of load-bearing work in a lot of threat models. We've written it ourselves, in the air-gap and blast-radius posts — the sandbox is the thing standing between an agent's worst action and your actual infrastructure.

CVE-2022-0492 is a reminder that the sandbox is not a wall. It's a set of kernel features with their own CVE history, and the strength of the wall is exactly the strength of the profile you put around it. And agent workloads have a habit of eroding that profile, for ordinary reasons:

  • Generated code needs to run, so seccomp gets relaxed. A default seccomp profile blocks syscalls that agent-generated builds sometimes legitimately need, and the fastest way past a confusing failure is to loosen the profile. The mount family is a common casualty.
  • "Just make it work" reaches for --privileged. Docker-in-Docker for an agent that builds images, a tool that wants raw device access — the privileged flag makes the error go away and quietly hands the container CAP_SYS_ADMIN, which is the front door to this exact bug.
  • The host kernel is shared and often forgotten. Containers don't carry their own kernel. An agent fleet running on a node that hasn't been patched past 5.17 is exposed regardless of how clean the images are — and "the node's kernel version" is rarely in the same review as "the agent's permissions."

Put those together and the uncomfortable version of the question is: if your agent can be talked into running attacker-chosen code — and prompt injection means you should assume it can — what's the actual floor it lands on? If the sandbox is a permissively-profiled or privileged container on an unpatched kernel, the honest answer is "root on the host," and the agent's blast radius is the node, not the namespace.

If you're inside a FedRAMP boundary

The ConMon mechanics are the same as the last three clocks, so we won't re-run them — the Cisco walkthrough covers how a KEV item inherits its federal due date as your remediation deadline, ahead of the usual 30/90/180-day windows. Late June is the date that matters here.

What's specific to this one is where the work lives, because "is CVE-2022-0492 in our boundary?" doesn't resolve to a product inventory:

  • It's a kernel-version question, not an app question. The thing to scan for is the running kernel on every host carrying container workloads inside the boundary — managed-Kubernetes nodes, build runners, the box your agents execute on. The asset that answers this CVE is the node, and nodes are easy to leave out of a software bill that was built around applications.
  • The compensating control is the profile, and it should be evidence. Because a baseline AppArmor/SELinux/seccomp profile mitigates this, "not exploitable in our environment" can be a perfectly defensible finding — if you can show it. That means the profile applied to your agent containers, the absence of --privileged, and the capability set, captured as artifacts rather than asserted from memory. "Not applicable" is a finding too, and under a clock it's the one teams improvise.
  • Privileged agent containers are a finding in two directions. If the scoping exercise turns up an agent running privileged on a shared node, you've found both the exposure to this CVE and a least-privilege gap that was a problem before June 2 and will be one after it's patched.
  • The evidence trail is the usual one. Kernel versions before and after, the profile configs, the POA&M entry if you open one, the node-pool upgrade tickets. The thing that survives the next assessment is the trail, not the outcome.

What we keep coming back to

Every one of these posts ends in roughly the same place, because the lesson keeps being the same: the KEV item changes every few weeks, and the thing that makes any given week survivable is knowing what you run before you're asked under a clock. This time the wrinkle is that "what you run" has to reach down a layer — past the agent, past the image, to the kernel it sits on and the profile that contains it.

That layer is exactly the kind of thing that disappears from an inventory built around applications and services. It's also exactly what we've been pointing the Novaprospect audit engine at: infrastructure-native discovery that sees the node and its kernel, not just the workload; the container security profile captured as standing evidence; KEV feeds in the same triage queue whether the next item is an appliance, an orchestration tool, or the floor underneath both.

The question this one leaves on the list, to ask before the next KEV item lands: the sandbox you're trusting to contain your agents — do you know what it's actually made of, and can you prove the floor holds?

Reference