CISA KEV: Linux CVE-2022-0492 Container Risk

CISA’s June 2 KEV addition is a reminder that old kernel flaws can remain high-priority when container hosts, cloud workloads, and appliance-like Linux systems are still exposed.

CISA added CVE-2022-0492 to the Known Exploited Vulnerabilities catalog on June 2, 2026, with a June 5, 2026 remediation due date for covered federal agencies under BOD 22-01 (CISA KEV catalog). The catalog describes the issue as a Linux kernel improper authentication vulnerability that can allow privilege escalation through the cgroups v1 release_agent feature, and it lists known ransomware campaign use as unknown rather than confirmed (CISA KEV catalog). That combination matters: this is not a new CVE, but CISA’s KEV action changes the operational priority for cloud, container, and Linux platform teams.

For Cyberuptive’s audience, the key question is not whether every Linux host is equally exposed. The question is whether any container host, virtual appliance, lab environment, legacy cloud image, or unmanaged Linux system still carries the vulnerable kernel behavior and a reachable path to abuse. Treat this as a short-window validation exercise: find affected kernels, verify cgroups v1 exposure, reduce unnecessary privilege, and document remediation evidence.

What is CVE-2022-0492?

CVE.org describes CVE-2022-0492 as a flaw in the Linux kernel’s cgroup_release_agent_write function in kernel/cgroup/cgroup-v1.c that, under certain circumstances, allows use of the cgroups v1 release_agent feature to escalate privileges and unexpectedly bypass namespace isolation (CVE.org). Ubuntu’s security record says the cgroups implementation did not properly restrict access to the cgroups v1 release_agent feature and that a local attacker could use the issue to gain administrative privileges (Ubuntu CVE record).

This is a Linux host risk that becomes more important in containerized environments because containers rely on kernel isolation boundaries. MITRE ATT&CK technique T1611, Escape to Host, describes adversaries breaking out of a container or virtualized environment to access the underlying host or other resources from the host level (MITRE ATT&CK). CVE-2022-0492 should not be discussed publicly as a how-to exploit path, but it should be handled as a practical reminder that container security depends on host kernel hygiene, runtime configuration, and least-privilege enforcement.

Why this matters now

CISA’s KEV catalog is designed to focus remediation on vulnerabilities with evidence of exploitation in the wild, not merely theoretical issues (CISA KEV catalog). The June 5 due date gives federal teams and their suppliers a compressed timeline to show action, and many private-sector vulnerability programs use KEV additions as a prioritization signal even when they are not directly bound by BOD 22-01.

The age of the CVE is also part of the risk story. CVE-2022-0492 was published in 2022, and Ubuntu lists fixed kernel package versions across multiple Ubuntu releases and cloud kernel variants (Ubuntu CVE record). If an organization still finds exposure in 2026, the issue may point to a broader asset-management gap: unmanaged images, long-lived hosts, unsupported Linux distributions, frozen appliance builds, or container platforms outside normal patch governance.

Who should prioritize review?

Start with Linux systems that support containerized workloads, especially Kubernetes worker nodes, container build infrastructure, CI runners, cloud-hosted Linux images, managed service nodes with customer responsibility boundaries, and virtual appliances built on older Linux kernels. Review is also appropriate for OT-adjacent Linux systems and lab environments where patching is often delayed and privileged containers may have been used for troubleshooting.

Teams should not assume that a vendor-managed platform is either safe or exposed without evidence. Instead, collect the operating model: who owns the kernel, who owns the container runtime, who controls image refresh, and who can attest to the fixed package or kernel version. That evidence is what compliance, incident response, and executive stakeholders will need if questions arise after a KEV addition.

What to do today

Confirm inventory and ownership

Build a short list of Linux hosts and container platforms that could plausibly run affected kernels. Include cloud images, self-managed Kubernetes clusters, container hosts outside the primary cluster estate, CI/CD runners, security tools deployed as virtual appliances, and legacy Linux workloads that have not been rebuilt recently. Each asset should have an owner, a current kernel version, a distribution or vendor source, and a patch decision. Our vulnerability scanning services are built around this kind of exposure discovery.

Patch affected kernels

Apply vendor-provided updates or mitigations according to the distribution or product vendor. CISA’s KEV entry directs organizations to apply vendor mitigations, follow BOD 22-01 guidance for cloud services where applicable, or discontinue use if mitigations are unavailable (CISA KEV catalog). Ubuntu lists CVE-2022-0492 as High severity with CVSS 3.1 score 7.8 and shows fixed kernel packages across Ubuntu releases and cloud-specific kernels, including AWS, Azure, GCP, GKE, KVM, Oracle, and other variants (Ubuntu CVE record). Our patch management services can run this on a controlled change cadence with evidence capture.

Reduce container escape preconditions

Use the review to tighten container-host controls. Limit privileged containers, avoid broad host mounts, restrict dangerous Linux capabilities, keep container runtimes current, and prevent unnecessary write access to cgroup-related host paths. These steps are not substitutes for patching, but they reduce the chance that one configuration mistake becomes a host-level incident.

Validate telemetry and evidence

Security operations should confirm that Linux host logs, container runtime logs, Kubernetes audit logs, and cloud workload telemetry are retained long enough to support review. The goal is not to publish exploit details or create unsafe test steps. The goal is to verify whether suspicious privilege escalation, unusual container configuration changes, unexpected host-path mounts, or administrative access occurred around assets that were late to patch. If your team lacks the coverage to run this review, our managed detection and response and SOC-as-a-Service teams can help.

Document residual risk

For regulated environments, a KEV addition should create a durable evidence trail. Record affected assets, fixed versions, compensating controls, owner signoff, validation method, exception rationale, and the date remediation was completed. If a vendor-managed service is in scope, record the vendor attestation or advisory that supports the decision.

How executives should read this KEV addition

CVE-2022-0492 is not just a Linux patch ticket. It is a test of whether the organization can rapidly connect external exploitation signals to internal infrastructure ownership. The strongest programs will be able to answer four questions within hours: where the vulnerable technology could exist, who owns it, whether it is patched, and what evidence proves the answer.

Cyberuptive recommends treating this KEV update as a cloud security hygiene drill with a real deadline. Patch what is affected, verify container-host hardening, and close any inventory gaps that made the answer harder than it should have been.

Frequently asked questions about CVE-2022-0492

What did CISA add on June 2, 2026?

CISA added CVE-2022-0492, a Linux kernel improper authentication vulnerability, to the Known Exploited Vulnerabilities catalog on June 2, 2026, with a June 5, 2026 due date for covered federal agencies (CISA KEV catalog).

Is CVE-2022-0492 a container escape issue?

CVE.org says the flaw can allow use of the cgroups v1 release_agent feature to escalate privileges and unexpectedly bypass namespace isolation under certain circumstances (CVE.org). In container environments, that makes it relevant to host-escape risk, but defenders should avoid unsafe exploit testing and focus on patching, hardening, and telemetry review.

Is ransomware use confirmed?

CISA’s KEV entry lists known ransomware campaign use as unknown, so teams should not claim confirmed ransomware use from the KEV entry alone (CISA KEV catalog).

What should teams do first?

Start with internet-adjacent and business-critical Linux container hosts, then review CI runners, cloud images, appliances, and legacy Linux systems. Patch affected kernels, restrict unnecessary container privileges, and document evidence of remediation.

References

Cyberuptive runs a 24/7 follow-the-sun SOC staffed by U.S.-based analysts, headquartered in Honolulu and serving customers across Asia-Pacific and the U.S. mainland. We help mid-market organizations, MSPs, and Pacific defense subcontractors find affected Linux and container assets, prioritize KEV-driven remediation, harden container-host configuration, and package evidence for executives, auditors, and incident-response stakeholders.

Read our vulnerability scanning services, our patch management services, and our managed detection and response, or talk to us about a targeted CVE-2022-0492 response review.