Linux container-escape flaw CVE-2022-0492 exploited; CISA orders a fix

An old flaw in a core part of Linux is now being used in real attacks. CVE-2022-0492 is a flaw that can let a program escape from inside a container (the mechanism for running an app packed in a box) out to the server itself, and it was patched back in 2022. The U.S. CISA (Cybersecurity and Infrastructure Security Agency) has added it to its "Known Exploited Vulnerabilities (KEV) catalog" and ordered agencies to remediate within a deadline. It is a textbook case: even an old flaw gets targeted if unpatched servers remain.

The flaw is in Linux's "cgroups (control groups)," a feature that underpins containers. But not every container can escape in one shot. Exploitation requires several conditions to line up, and standard security settings prevent it. This article walks through what happens, which environments are at risk, and what to do now.

The flaw at a glance

First, the key facts. What stands out is not the severity number (CVSS 7.8) but the fact that it was confirmed exploited and landed in KEV. The score is not top-rank, but since attackers are actually using it, the priority to respond jumps.

The CVSS stops at 7.8 because the attack assumes local access to the server (AV:L). It is not the kind of thing hit one-sidedly over the internet. But in real attacks, a chain happens: first getting inside a container via some other web-app flaw, then using this vulnerability to break out to the host. The KEV listing means that exact chain is being used in the wild.

When the intruder in the box becomes admin of the whole server

What makes this flaw frightening is that where the attacker ends up is not inside one container, but admin rights on the server (the host) that runs it. The people who put a price on that are attackers who broke in through a web-app hole and lurk in a container, ransomware crews that encrypt cloud platforms for ransom, and cryptojackers who secretly mine cryptocurrency on others' servers. What they get is the contents of other companies' containers running on the same server, cloud connection details, and stored database credentials. The moment they break out of the container via this flaw, the walls that were supposed to separate the boxes collapse, and the whole server passes into the attacker's hands.

Breaking out does not stop at one step. With admin rights on the host, the attacker peers into every co-resident container and uses cloud credentials to spread into neighboring servers and production. Stolen credentials are resold on the dark web, and the buyer uses them as a foothold to encrypt the whole platform, halt operations, and extort twice by dangling the "publication" of exfiltrated data. On a shared platform, the damage does not end with one company but chains to each tenant riding along.

The cleanup falls on the infrastructure team running the platform, the contractor that built it, and management. If customer data leaks, a duty to report to the data-protection authority and notify individuals arises, on top of damages and lost trust. What never shows in the number 7.8 is the weight of "confirmed exploited." Because this is not a theoretical danger but a technique in active use, whether you can quickly check that no old, unpatched servers remain is what decides the operator's safety.

What are cgroups and container escape in the first place

A "container" is the technology of packing an app with its needed parts into a small box and running it, widely used in Docker, Kubernetes, and OpenShift. Its strength is running multiple boxes separated on one server, and it is the foundation of today's cloud. One of the features that makes those boxes work is Linux's cgroups (control groups), the mechanism that partitions and manages how much CPU and memory each container can use.

"Container escape" refers to a state where a program that should be confined inside a box crosses the wall and can operate the server itself. Since the premise of containers is keeping things safe by separating each box, an escape breaks that premise at the root. Other containers riding on the same server are put at risk together.

This flaw arose in the cgroups release_agent feature. It is a cleanup mechanism — "when this group's processes finish, run the specified program" — that should only be configurable by an administrator. But Linux failed to check whether the one setting it held admin privilege (CAP_SYS_ADMIN). According to the security firm Unit 42's analysis, the fix was just an 8-line addition of a permission check.

Inside CVE-2022-0492: the missing check and the conditions for escape

According to the NVD (the U.S. vulnerability database), the flaw is in the cgroups v1 cgroup_release_agent_write function, and it lets an unprivileged user misuse release_agent to escalate privileges and cross the isolation wall (CWE-862, missing authorization). The attacker escapes by creating a new namespace inside the container to gain admin privilege, mounting a writable cgroup filesystem, planting a malicious release_agent, and triggering its execution.

However, what must not be misunderstood is that escape requires several conditions to line up. Unit 42 lists the main conditions for a successful container escape as: (1) the container runs with root privilege, (2) there is no AppArmor or SELinux protection, (3) Seccomp is disabled, (4) the host has unprivileged namespaces enabled, and (5) the container runs in a v1 cgroup. Conversely, if any of AppArmor, SELinux, or Seccomp is in effect, escape is prevented. Many container environments ship with these protections by default, so if you run with the default settings, you are likely protected.

At risk are privileged containers run with protections removed, and old or permissive setups that skip safety settings. The target is the Linux kernel before 5.17, and the fix has been available since 2022 in 5.17 and the stable branches (4.9.301 / 4.14.266 / 4.19.229 / 5.4.177 / 5.10.97 / 5.15.20 / 5.16.6, etc.). In other words, environments that keep updating were fixed long ago; what is dangerous is servers left without updates.

Has it been exploited?

Let us separate what is known from what is not yet confirmed.

Quick check: is your environment at risk?

Even on the same Linux, the risk varies with kernel update status and container settings. Find your situation in the table below.

Most dangerous is an environment running privileged containers with protections removed on an old, un-updated server. If you use a cloud-managed container platform, the platform side is often already updated, but self-managed nodes and on-premises environments need you to check the kernel version yourself.

What infrastructure operators should check now

The top priority is confirming that the kernel of the servers running your containers is at 5.17 or your distribution's fixed version. Since the fix is from 2022, you should be patched if you keep updating — but check that no old nodes remain that have gone a long time without a reboot or update. Watch out for cases where old cloud images or base images are reused as-is.

Alongside that, enforce the basic hardening for running containers: do not grant unnecessary privileges (avoid privileged containers), enable AppArmor or SELinux, and use Seccomp. If any of these is in effect, escape via this flaw is prevented. To track confirmed-exploited vulnerabilities together, see the CISA KEV dashboard and our roundup of major 2026 H1 vulnerabilities.

In the same core part of Linux, privilege-escalation flaws have come one after another. Copy Fail (CVE-2026-31431), which can seize root in cloud environments, is one of them, and the weight of keeping the foundational kernel current keeps growing.

FAQ

Summary

CVE-2022-0492 is a missing-authorization flaw in Linux cgroups v1 that can let a program escape from inside a container out to the server itself. It was patched in 2022, but CISA added it to KEV as a "confirmed exploited vulnerability" and mandated remediation. The CVSS is 7.8, exploitation requires several conditions to line up, and standard protections like AppArmor, SELinux, and Seccomp prevent escape. What is dangerous is an environment running privileged containers with protections removed on an old, un-updated server. The fix: update the kernel to a patched version, and trim privileges while enabling protections. It is a quintessential KEV case — even an old flaw gets targeted if un-updated environments remain.

References

• ▸NVD - CVE-2022-0492 (Linux cgroups release_agent)
• ▸CISA - Known Exploited Vulnerabilities Catalog
• ▸Unit 42 - CVE-2022-0492 cgroups analysis (conditions for escape)
• ▸kkm-mako - CISA KEV dashboard