CVE-2022–0185: What is it, how to identify, and it’s impact on Kubernetes Workloads

2026 update — read this first: CVE-2022-0185 has long been fixed, so this article is now most useful as a case study, not an active alert.

This post was written in January 2022, in the same week the vulnerability was disclosed, so it is full of “as of right now” phrasing that is no longer true. To set expectations before you read on:

• It is patched everywhere. A fix landed in Linux kernel 5.16.2 in January 2022 and was quickly backported to every maintained distribution (Ubuntu, RHEL, Debian, Amazon Linux, and others). If you are on a supported, updated kernel in 2026, you are already protected. The “not available for all distributions yet” line further down was true for a few days in early 2022 and is not true now.
• Its severity is CVSS 7.8 (High). That has not changed.
• Why keep reading? The mechanics of this vulnerability — a container escape driven by user namespaces and CAP_SYS_ADMIN — are an excellent, still-relevant lesson in how kernel bugs become Kubernetes cluster compromises. The defensive practices at the end (seccomp, dropping capabilities, disabling unprivileged user namespaces, and continuous scanning) are exactly what protects you against the next kernel CVE, which is the real takeaway in 2026.

Treat the timeline language below as historical, and the mitigation guidance as a durable pattern.

Discovery of CVE-2022-0185 Vulnerability

Last week, researchers Jamie Hill-Daniel and William Liu discovered & disclosed a vulnerability in Linux Kernel.

It’s assigned a CVE ID of CVE-2022-0185. And is rated as High Severity. This got introduced to Linux Kernel as part of version 5.1-rc1 in March 2019, almost 3 years ago.

2026 update — timeline clarification. “Last week” refers to mid-January 2022; the vulnerability was publicly disclosed on January 18, 2022. The flaw was introduced in kernel 5.1-rc1 in March 2019, so by 2026 the vulnerable code shipped roughly seven years ago — but, again, it has been fixed in all maintained kernels for years. The precise root cause, for accuracy: an integer underflow in the legacy_parse_param function of the kernel’s File System Context feature, which leads to a heap-based out-of-bounds write.

Impact of Linux Vulnerability

This vulnerability is related to a heap-based buffer overflow in the “File System Context” Linux kernel component. This can lead to multiple attacks.

An attacker can use this flaw to attack via Privilege Escalation to root, Escape to Host from the containers environment, Denial-of-Service to crash the system, an out-of-bounds write, and arbitrary code execution.

An attacker can change the values in Kernel memory and access any process running on the same host. It can be used by a local user to escalate privileges.

In order to exploit, the attacker needs to use an unprivileged namespace or use unshare to enter a namespace with the CAP_SYS_ADMIN permission. It’s neither a default setting nor a common practice on Docker. This vulnerability is applicable for containers initiated with a --privileged flag.

Also, the unshare command is blocked by Docker’s seccomp filter by default, so running the command isn’t permitted by default.

However, seccomp the filter is disabled by default when Docker or other container platforms are used in Kubernetes Clusters. So, unshare the command is not blocked.

2026 update — Kubernetes can now apply a seccomp profile to every pod by default, which materially changes this point. When this article was written, Kubernetes did not apply any seccomp profile unless you set one per workload, which is why unshare was not blocked. Since Kubernetes 1.27 (2023) the SeccompDefault feature graduated to stable: when the cluster operator enables it, the kubelet applies the container runtime’s RuntimeDefault seccomp profile to all pods automatically, so dangerous syscalls are filtered without you writing custom profiles. One precise caveat so you do not assume too much: this is stable but not on unless someone turns it on — a cluster still defaults to Unconfined unless the operator enables SeccompDefault (or you set seccompProfile: RuntimeDefault in each pod’s securityContext). Managed platforms differ, so verify your cluster. The 2026 best practice is to make RuntimeDefault your baseline for every workload and only loosen it where a specific app genuinely needs a blocked syscall.

In order to exploit the vulnerability, the attacker needs to be able to run code in a container with CAP_SYS_ADMIN privileges.

It can be seen in the demo below.

2026 update — here is the escape chain spelled out, because it is the durable lesson. It is worth understanding why this bug is so dangerous in Kubernetes, since the same pattern recurs with every new kernel flaw:

1. Shared kernel. Every container on a node shares the host’s single Linux kernel. Unlike a virtual machine, there is no separate kernel boundary — so a kernel-memory bug is a bug in the thing that isolates all your containers.
2. A foothold in one pod. The attacker first needs code execution in a container. That can come from a vulnerable application, a poisoned dependency, or a compromised image — none of which are exotic.
3. The privilege they need. The exploit requires CAP_SYS_ADMIN, which a pod gets if it runs --privileged or is granted that capability, or via an unprivileged user namespace where seccomp is not filtering unshare. This is exactly why the defenses below focus on capabilities, user namespaces, and seccomp.
4. Kernel memory corruption → host. Triggering the heap overflow lets the attacker modify kernel memory, escalate to root, and reach any process on the host — every other pod on that node included.
5. Lateral movement. From a compromised node, the attacker can steal the node’s kubelet credentials and any mounted service-account tokens, then pivot toward the wider cluster and cloud account.

The point for 2026: the fix for this CVE is just a patch, but breaking this chain at steps 3 and 4 (least privilege, seccomp, no privileged pods) is what protects you from the kernel bugs that have not been discovered yet.

Identification

This is a useful repo shared by the Crusaders-of-Rust team for identification of the issue. A very detailed write-up is here.

2026 note — a word of caution on the proof-of-concept links above. The public exploit repository and write-up remain valuable for learning how the bug works, and they are safe to study. Only run proof-of-concept exploit code against an isolated, disposable lab cluster you own — never against production or shared infrastructure. Since the CVE is patched, a current lab will not even be vulnerable unless you deliberately build it on an old, unpatched kernel, which further reinforces that your production fleet should simply be kept up to date.

You can check the Node & Kernel Version used by running the following command:

kubectl get nodes -o jsonpath=‘{range .items[*]}Node - {.metadata.name}{“\n”}Kernel Version: {.status.nodeInfo.kernelVersion}{end}’

2026 update — the kubectl one-liner above still works, but do not rely on the raw version string to decide if you are vulnerable. Because distributions backport fixes into older-looking kernel versions (explained in the mitigation note below), a kernel that reads as “older than 5.16.2” may still be fully patched. In 2026 the reliable way to identify exposure is to let a vulnerability scanner that understands your distribution’s package metadata make the determination:

• Amazon Inspector continuously scans running EC2 nodes (including EKS worker nodes) and ECR images and will flag the specific CVE with backport awareness.
• Open-source scanners like Trivy or Grype can scan node images and container images in your CI pipeline before they ever reach the cluster.
• Kubernetes-native posture tools can additionally check whether risky settings (privileged pods, CAP_SYS_ADMIN, Unconfined seccomp) exist in your workloads, which is what actually turns a kernel bug into an escape.

The kubectl command is a fine first look; a scanner backed by proper vulnerability management is what you should trust for a yes/no answer at scale. Managing that at fleet scale is exactly what one team achieved by moving to managed VM vulnerability management, replacing self-run Wazuh.

Mitigation

A fix was released on the 18th as part of Kernel 5.16.2 and there have been several patches released to address this issue. These patches are released by Linux Kernel and other major distribution maintainers.

2026 update — the patch situation is fully resolved; here is the current, accurate picture. “The 18th” means January 18, 2022. Since then the fix (and distro backports) have been available for years across Red Hat/RHEL, Ubuntu, Debian, Amazon Linux, SUSE, and others, so any supported kernel you run in 2026 already includes it. One practical subtlety worth knowing: enterprise distributions backport the fix into their own older kernel versions rather than moving you to 5.16.2, so a kernel that looks older than 5.16.2 can still be patched. Do not judge exposure by version number alone — check your distribution’s security tracker for CVE-2022-0185 (linked below) or let a vulnerability scanner that understands backports make the call for you. The real 2026 lesson is process, not this one CVE: keep nodes on a maintained kernel with automated patching so the next container-escape CVE is closed within days, not months.

Here are the patches:

• https://access.redhat.com/security/cve/CVE-2022-0185
• https://ubuntu.com/security/CVE-2022-0185
• https://security-tracker.debian.org/tracker/CVE-2022-0185

It’s highly recommended to download and install the latest Kernel version. This applies to Linux users and administrators.

Upgrading the Linux kernel to version 5.16.2 or later addresses the problem. However, the update is not available for all distributions yet.

2026 update — this line is outdated: the fix is now available for every maintained distribution. The sentence “the update is not available for all distributions yet” was accurate only for a short window in January 2022. As of 2026, patched kernels have long shipped for all major distributions. If you are running an end-of-life kernel that never received the backport, the correct fix is to move to a supported version — the workarounds below (disabling unprivileged user namespaces, seccomp filtering) are fallbacks for a patching gap, not a permanent substitute for an updated kernel.

If patching is not an option, disable unprivileged user namespaces.

2026 update — the “defense in depth” mindset behind these workarounds is still exactly right. Even though this specific CVE is patched, the hardening steps in this section are permanent good practice, because they blunt whole classes of container-escape bugs:

• Disable unprivileged user namespaces where your workloads do not need them (kernel.unprivileged_userns_clone=0 on Ubuntu, user.max_user_namespaces=0 on RHEL-family systems). Many kernel exploits, including this one, depend on an unprivileged user obtaining CAP_SYS_ADMIN inside a new user namespace.
• Drop capabilities and never run --privileged in production. In Kubernetes, set securityContext.capabilities.drop: ["ALL"], allowPrivilegeEscalation: false, privileged: false, and readOnlyRootFilesystem: true. This exploit required CAP_SYS_ADMIN; a pod that cannot obtain it cannot run the attack.
• Enforce these with policy, not hope. Use Pod Security Admission at the restricted level, or a policy engine such as Kyverno or OPA Gatekeeper, so a risky pod spec is rejected at admission time rather than caught after it is running.

On Ubuntu, use this command to disable unprivileged namespaces:

sysctl -w kernel.unprivileged_userns_clone=0

For RedHat, users without containerized deployments disable user namespaces:

echo “user.max_user_namespaces=0” > /etc/sysctl.d/userns.confsysctl -p /etc/sysctl.d/userns.conf

If unprivileged containers are needed, in that case seccomp the filter should block the unshare call.

For individual workloads, Kubernetes has a detailed tutorial on how to add seccomp to the securityContext field definition. Check this out here.

2026 update — add runtime detection to patching and admission control. Prevention (patched kernels, dropped capabilities, seccomp, admission policies) stops the known and the preventable. To catch a live exploitation attempt of a kernel or container bug, add runtime threat detection built on eBPF — Kubernetes runtime security tools such as Falco, Tetragon, or the runtime monitoring in a CWPP platform watch for the exact behaviors this exploit produces: a process unexpectedly gaining new capabilities, an unshare/namespace manipulation, or a container process escaping to the host. This is the same real-time layer teams rely on for container security and real-time visibility across modern cloud. That way, even a brand-new kernel CVE with no patch yet (a true zero-day) generates an alert the moment someone tries to use it. The complete 2026 posture for kernel/container-escape risk is four layers: patch fast, minimize privileges, enforce with admission policy, and detect at runtime.

Cloud-Native Realm: A Comprehensive Look at Kubernetes Security with Steve Giguere
Explore Kubernetes security, cloud-native challenges, and DevSecOps best practices with Steve Giguere on Scale to Zero.

How can Cloudanix help?

Cloudanix helps you to improve your Cloud Security. Our platform offers CSPM, CIEM, and CWPP (Container Vulnerability) all in one – so your Kubernetes-based workloads running in any cloud or bare-metal can be secure.

AWS, Azure, GCP, DigitalOcean or any other cloud service

Your Kubernetes workloads could be running in any Cloud or baremetal - we support them all.

People Also Read

• Top 12 Container Security Best Practices
• What is Dirty Pipe Vulnerability and its impact on Containers?
• Improve Kubernetes Security with Cloudanix’s Add-On For Spectro Cloud
• Top 15 Cloud Misconfigurations in 2026 - How to Fix Them?
• The Ultimate Guide to Cloud Workload Protection
• Comprehensive Guide to Threat Modeling
• Top 18 Challenges of Cloud Security in 2026
• Using eBPF to Enhance Monitoring and Observability