TL;DR: On June 2, 2026, CISA added Linux kernel CVE-2022-0492 to its Known Exploited Vulnerabilities catalog after observing live exploitation that lets a malicious container escape to the host with root privileges. The flaw lives in the cgroup v1 release_agent mechanism, was patched in Linux kernel 5.17-rc3, and has been weaponized in 2026 ransomware and cryptojacking campaigns targeting unpatched cloud workloads. Federal civilian agencies must remediate by June 23, 2026. For NC small businesses running Docker, Kubernetes, or any container workload on Linux, the right action is faster than that: inventory every Linux host running containers, verify kernel version this week, and confirm seccomp and AppArmor or SELinux are enforced on every container.
Key takeaway: A four-year-old kernel flaw on the KEV catalog is the federal government telling you that "we patched it once" is not the same as "it is patched everywhere now." Long-running SMB Linux workloads, especially those built once and forgotten, are the high-risk inventory this week.
Need a Linux KEV exposure check this week? Preferred Data Corporation runs kernel inventory sweeps and container hardening sprints for NC small businesses. Call (336) 886-3282 or request a Linux exposure review.
What is Linux CVE-2022-0492?
CVE-2022-0492 is a high-severity (CVSS 7.0) privilege escalation and container escape vulnerability in the Linux kernel's cgroup_release_agent_write function in kernel/cgroup/cgroup-v1.c. Per Palo Alto Unit 42's analysis and Sysdig's deep dive, the bug is a missing capability check: the kernel did not verify that the process writing to the release_agent file held the CAP_SYS_ADMIN capability.
When a process in a cgroup dies and notify_on_release is enabled, the kernel invokes whatever binary is configured as the release_agent with full root privileges in the initial namespace. A container with CAP_SYS_ADMIN (or one that can mount cgroup v1 itself) can rewrite that path to a malicious binary and force the kernel to execute it as root on the host, completely escaping container isolation.
The patch shipped in Linux kernel 5.17-rc3, with backports to long-term support branches. CISA added the CVE to KEV on June 2, 2026 after observed in-the-wild exploitation, setting a federal remediation deadline of June 23, 2026 under BOD 22-01.
Why does a 2022 kernel CVE matter to an NC small business in 2026?
Because containers are now embedded in routine SMB workloads, and Linux kernels live longer than people remember. Three patterns put NC small businesses in scope:
- Older Linux servers running production workloads. Many NC SMBs run RHEL 8, CentOS 7/8, Ubuntu 20.04, or Debian 11 hosts that were stood up years ago and have only received "security patch" updates, which is not always the same as kernel updates. Without a deliberate kernel upgrade or
kpatch/Ksplicelive patching, the host can still be carrying a vulnerable cgroup v1 implementation. - Container workloads built on outdated base images. Per Aqua Security's 2026 container security report, 64% of container images in production use base images older than two years, and 22% of those have not been rebuilt against current upstream kernels.
- Cloud-hosted Linux VMs and managed Kubernetes nodes. Even AWS, Azure, and GCP managed node pools can lag if auto-upgrade is disabled or pinned to an older minor version.
For an NC manufacturer running a containerized MES, a distributor running a containerized ERP add-on, or a professional services firm running self-hosted GitLab, Mattermost, or Bitwarden on Docker Compose, the vulnerable kernel may already be in the environment.
Is my business exposed to CVE-2022-0492?
Use this three-question screen. If you answer "yes" or "I do not know" to any, treat exposure as likely.
| Screen question | Why it matters |
|---|---|
| Do you run any Linux servers (on-prem or cloud) hosting Docker, Podman, Kubernetes, or LXC containers? | Container workloads are the primary attack path for this CVE |
| Are any production Linux hosts on a kernel earlier than 5.17 (or unpatched long-term support 4.x/5.x branches)? | Kernel version, not OS version, determines exposure |
Do you run any containers with --privileged, with added CAP_SYS_ADMIN, or without seccomp and AppArmor/SELinux enforced? | These configurations make exploitation trivial |
A fast self-check on any Linux host: uname -r returns the kernel version, and docker info | grep -i security or kubectl get pod -o yaml | grep -i security will show whether seccomp and LSM enforcement is in place. The open-source CVE-2022-0492-Checker script gives a quick yes/no per host.
What is the right response for an NC SMB this week?
Sequence the response in three phases. Most NC small businesses with a managed partner can close exposure within 14 days.
- Inventory (first 48 hours). Identify every Linux host running containers. Pull the list from Hyper-V, VMware, Proxmox, AWS, Azure, GCP, and any on-prem bare metal. Capture kernel version, container runtime, container count, and whether seccomp/AppArmor/SELinux are enforced.
- Patch or compensate (next 7 days). Upgrade kernels to a fixed release or apply distribution backports. For long-running production hosts where reboot is hard, use
kpatch(RHEL),Ksplice(Oracle Linux), or vendor-equivalent live patching. Where patching is delayed, confirm the Docker default seccomp filter and AppArmor profile are enforced, which blocks the exploit path entirely. - Hunt and harden (next 7 days). Run EDR/MDR queries on the host for unexpected
release_agentwrites, suspicious child processes from container runtimes, and new cron entries or systemd units. Remove--privilegedflags from container compose files where not strictly required, dropCAP_SYS_ADMIN, and migrate to cgroup v2 where the distribution supports it.
Quotable definition: A container escape is a vulnerability that lets code inside a container break out of the isolation boundary and execute on the host operating system with elevated privileges. From the host, the attacker can reach every other container, every host-mounted file system, and every connected network segment.
Why is "patch by federal deadline" too slow for an SMB?
Federal civilian agencies have a 22-day window under BOD 22-01. The attacker timeline is shorter than that for three reasons:
- Mass scanning starts within hours of a KEV addition, per Cyble's 2026 weekly vulnerability surge trend analysis.
- Container escape is a high-leverage initial access vector. One escape on one container gives the attacker the entire host, which often hosts other production containers and database mounts.
- 88% of ransomware attacks hit small businesses per Verizon DBIR 2026, and container escapes are now a documented initial access path in ransomware playbooks per Aqua Security's 2026 container threat report.
The defensible posture for an NC small business is "patched and verified within 14 days," with seccomp, AppArmor or SELinux, and 24/7 monitoring on every container host.
How does this connect to cyber insurance?
Underwriters in 2026 ask about Linux patch SLA and container security controls explicitly. Per Fairdinkum's 2026 SMB cyber insurance readiness guide, questionnaires now include kernel patch cadence, container runtime hardening, and EDR coverage on Linux servers. Unpatched KEV-listed kernel CVEs are a documented control failure and a likely path to a denied claim.
Want a managed partner to drive the Linux KEV remediation in 14 days? Call (336) 886-3282 or request a Linux KEV sprint.
How does Preferred Data Corporation help?
PDC supports NC small businesses with three things that close the Linux container gap quickly:
- Managed cybersecurity with EDR/MDR coverage on Linux servers, container runtime telemetry, and 24/7 monitoring for
release_agentabuse, suspicious process spawning, and lateral movement after a container compromise. - Managed IT services with kernel patch sprints, vendor coordination (Red Hat, Canonical, Oracle Linux, SUSE), live patching for production hosts that cannot reboot, and audit evidence for insurance and compliance.
- Cloud solutions for AWS, Azure, and GCP workload patch governance, managed Kubernetes node pool upgrades, and container image rebuild pipelines that keep base images current.
PDC has supported NC small businesses, manufacturers, and distributors for over 37 years with on-site coverage within 200 miles of High Point. The combination of local context and national-grade tooling is what gets a CISA KEV entry off your fleet in days, not months.
Frequently Asked Questions
Does CVE-2022-0492 affect cgroup v2 systems?
No. Per Palo Alto Unit 42's analysis, the vulnerability is specific to the cgroup v1 release_agent mechanism. Cgroup v2 reorganized the interface and removed the vulnerable path. Migrating to cgroup v2 is a strong long-term mitigation, though many production stacks still run cgroup v1 for compatibility.
Will Docker's default seccomp and AppArmor block this?
Yes, per Sysdig's mitigation analysis and Aqua Security's research. The Docker default seccomp profile blocks the unshare system call required for the exploit, and the default AppArmor profile restricts the mount operation needed to reach the vulnerable cgroup interface. Custom profiles that disable seccomp or run containers with --privileged reopen the path.
What about Kubernetes? Are managed node pools at risk?
Yes if the underlying node kernel is unpatched and pods can run with CAP_SYS_ADMIN or --privileged. Per Microsoft AKS's CVE-2022-0492 advisory, node pool images were updated to patched kernels in 2022, but clusters that pin to older node images, disable auto-upgrade, or run privileged DaemonSets are still in scope.
How do I check the kernel version on every Linux host without an agent?
For SMBs without centralized inventory, the fastest path is an Ansible ad-hoc command (ansible all -m command -a "uname -r") or an SSM Run Command on AWS, RunCommand on Azure, and gcloud compute ssh on GCP. A managed partner running EDR/MDR will already have kernel version in the asset inventory.
What is the realistic timeline for an SMB without dedicated DevOps to close exposure?
Two weeks is achievable with a managed partner driving the work, including inventory, kernel upgrades, container runtime hardening, and EDR verification. Without a managed partner, the realistic timeline stretches to 30-60 days because container restarts, kernel reboots, and vendor coordination across multiple Linux distributions consume bandwidth most SMBs do not have in-house.
Related Resources
- Managed Cybersecurity Services for NC Businesses - 24/7 monitoring on Linux, KEV-aligned response
- Managed IT Services for NC Businesses - Kernel patch sprints, vendor coordination, audit evidence
- Cloud Solutions for NC Businesses - AWS, Azure, GCP workload patch governance
- Android Zero-Day CVE-2025-48595 NC SMB Mobile Plan - Same-day KEV companion
- Oracle WebLogic CVE-2024-21182 KEV Action Plan - Prior week's KEV pattern
- Contact Preferred Data Corporation - Schedule a Linux KEV exposure review