{
	"id": "cc26ddee-216f-4366-8718-eb7ab302076b",
	"created_at": "2026-04-06T00:17:57.417037Z",
	"updated_at": "2026-04-10T03:20:54.467131Z",
	"deleted_at": null,
	"sha1_hash": "16e1bad7701a97fc5b2a1bf156aecf4a166ea306",
	"title": "Kubernetes Container Escape Using Linux Kernel Exploit | CrowdStrike",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1930918,
	"plain_text": "Kubernetes Container Escape Using Linux Kernel Exploit |\r\nCrowdStrike\r\nBy Manoj Ahuje\r\nArchived: 2026-04-05 16:15:46 UTC\r\nOn Jan. 18, 2022, researchers found a heap base buffer overflow flaw (CVE-2022-0185) in the Linux kernel (5.1-\r\nrc1+) function “legacy_parse_param” of filesystem context functionality, which allows an out-of-bounds write in\r\nkernel memory. Using this primitive, an unprivileged attacker can escalate its privilege to root, bypassing any\r\nLinux namespace restrictions.\r\nCVE-2022-0185 Needs CAP_SYS_ADMIN\r\nThis flaw is triggered by sending 4095 bytes or greater input to legacy_parse_param function, which provides\r\nwrite primitive to exploit this vulnerability. The input data is added via fsconfig system call, which is used for\r\nconfiguring filesystem creation context (e.g., ext4 filesystem superblock).\r\nfsconfig(fd, FSCONFIG_SET_STRING, \"\\x00\", val, 0);\r\nUse of fsconfig system call to add NULL terminated string pointed by “val”\r\nTo use the fsconfig system call, an unprivileged user must have CAP_SYS_ADMIN privileges at least in its\r\ncurrent namespace. That means if a user can enter another namespace that has these privileges, it will be enough\r\nto exploit this vulnerability. If CAP_SYS_ADMIN privileges are unavailable to an unprivileged user, attackers\r\nhave another way to get these privileges using unshare(CLONE_NEWNS|CLONE_NEWUSER) system call.\r\nUnshare system call lets a user create or clone a namespace or user that can have necessary privileges required to\r\nconduct further attack. This type of technique becomes very relevant in Kubernetes and the container world where\r\nLinux namespaces are used to isolate pods.Let’s take a closer look at how an unshare system call can add\r\nCAP_SYS_ADMIN privileges in Kubernetes and the mitigation. The exploit code and proof of concepts were\r\nreleased Jan. 25 on github by the research team that discovered this vulnerability.\r\nhttps://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/\r\nPage 1 of 8\n\nunshare to Gain CAP_SYS_ADMIN Privileges on Kubernetes\r\nSeccomp profile protects Linux namespace boundaries by blocking dangerous system calls being used by pods\r\nthat are isolated using such namespaces. Docker and other runtimes have used such profiles to protect namespace\r\nboundaries for a long time. But Kubernetes by default doesn’t apply any Seccomp or AppArmor/SELinux profile\r\nrestrictions when the pod is scheduled to run. Hence, such a pod by default gets free access to dangerous system\r\ncalls that allow it to escalate privileges and gain necessary capabilities such as CAP_SYS_ADMIN for further\r\nattack. In the following example, you can see that a non-privileged Kubernetes pod is scheduled to run and what\r\nits capabilities are. As you can see, this pod doesn’t have CAP_SYS_ADMIN privileges assigned to its root user.\r\n$ # create non-privileged pod\r\n$ kubectl run attacker --image=manojahuje/attacker\r\npod/attacker created\r\n$ kubectl exec -it attacker bash\r\nroot@attacker:/# lsns | grep user\r\n NS TYPE NPROCS PID USER COMMAND\r\n4026531837 user 4 1 root /bin/sh -c while true;do sleep 5; done\r\nroot@attacker:/# capsh --print\r\nCurrent: cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_net_bin\r\nBounding set =cap_chown,cap_dac_override,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_ne\r\nAttacker pod doesn’t have CAP_SYS_ADMIN privileges\r\nNow let’s escalate the privileges of our command line session to achieve CAP_SYS_ADMIN capabilities using an\r\nunshare system call. As you can see below, the attacker pod has gained CAP_SYS_ADMIN privileges after the\r\nuse of unshare.\r\nkubectl exec -it attacker bash\r\nroot@attacker:/# unshare -Urm\r\n#\r\n#\r\n# capsh --print\r\nCurrent: =ep\r\nBounding set =cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setui\r\n#\r\n# lsns | grep user\r\n NS TYPE NPROCS PID USER COMMAND\r\n4026532810 user 2 3149 root -sh\r\nAttacker pod gained CAP_SYS_ADMIN privileges, and user namespace is changed\r\nMitigation\r\nhttps://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/\r\nPage 2 of 8\n\nSince v1.22, Kubernetes has provided a way to add default Seccomp or AppArmor profiles using SecurityContext\r\nto protect any pod, deployment, statefulset, replicaset or daemonset. Though this feature is Alpha at the moment, a\r\nuser can add their own Seccomp or AppArmor profile and define it in SecurityContext. Let’s take a look at the\r\nfollowing pod yaml where a default Seccomp profile is applied to a pod.\r\napiVersion: v1\r\nkind: Pod\r\nmetadata:\r\n name: protected\r\nspec:\r\n containers:\r\n - name: protected\r\n image: manojahuje/attacker\r\n securityContext:\r\n seccompProfile:\r\n type: RuntimeDefault\r\nPod with RuntimeDefault seccomp profile\r\nNow, let’s schedule this unprivileged pod and try to gain CAP_SYS_ADMIN privileges using unshare. As you\r\ncan see below the unshare system call is blocked and potential attackers are unable to escalate privileges.\r\n$ kubectl apply -f pod-test.yaml\r\npod/protected created\r\n$ kubectl exec -it protected bash\r\nroot@protected:/#\r\nroot@protected:/# unshare -Urm\r\nunshare: unshare failed: Operation not permitted\r\nPod fails to escalate privileges using unshare\r\nKubernetes Container Escape Using CVE-2022-0185\r\nAs we saw, container orchestrators like Kubernetes heavily rely on namespace isolation to separate pods from\r\neach other on the node operating system. In addition, some of the pods or namespaces even on hosts outside the\r\ncontext of Kubernetes will always have CAP_SYS_ADMIN privileges. Hence if these pods are not protected by\r\nSeccomp or AppArmor profile, there is a good chance even a novice attacker will be able to get\r\nCAP_SYS_ADMIN privileges using unshare system call as discussed earlier or by any other means (e.g., by\r\ncompromising privileged pods). Once such privileges are gained, this vulnerability can be exploited with relative\r\nease. The POC was posted by researchers on twitter to show that reliable exploitation is possible on any\r\nvulnerable Kernel i.e. 5.1-rc1 and above with high probability of success.\r\nMitigation\r\nhttps://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/\r\nPage 3 of 8\n\nYou can secure your Kubernetes and Linux deployments using the following mitigation steps:\r\nCrowdStrike recommends upgrading the Kernel version to the latest as soon as possible. Patches are\r\nalready out thanks to responsible disclosure by researchers on all major distros including Ubuntu and Red\r\nHat.\r\nIf you are using Kubernetes, use SecurityContext to apply Seccomp and AppArmor/SELinux policies. It\r\nhas been available as an alpha feature since v1.22.\r\nYou can also use Pod Security to enforce policy throughout the cluster using the admission controller. This\r\nfeature has been available since v1.23, replacing the older Pod Security Policy (PSP).\r\nIf you have a non-containerized environment, you can use the following command to disable the\r\nfunctionality.\r\n$ sudo sysctl -w kernel.unprivileged_userns_clone=0\r\nOn Red Hat, you can disable user namespaces using the following commands (it is recommended that you\r\ndo so for non-containerized environments):\r\n# echo \"user.max_user_namespaces=0\" \u003e /etc/sysctl.d/userns.conf\r\n# sysctl -p /etc/sysctl.d/userns.conf\r\nCrowdStrike Protection\r\nThe CrowdStrike Falcon® platform protects Kubernetes workloads by auditing the runtime configuration of each\r\ndeployment. CrowdStrike follows CIS benchmarks for Kubernetes to identify any indicators of misconfiguration\r\n(IOMs). As we saw, Kubernetes workloads running without Seccomp or AppArmor/SELinux profiles are a huge\r\nrisk and can result in container escape and cluster compromise. Figures 1 and 2 show CrowdStrike alerts when a\r\nKubernetes workload is detected running without a seccomp or AppArmor/SELinux profile or with an incorrect\r\nseccomp profile. This helps with early detection of IOM and enables users to take immediate preventative\r\nmeasures.\r\nhttps://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/\r\nPage 4 of 8\n\nFigure 1. IOMs that CrowdStrike identified as missing seccomp profile on Kubernetes workload\r\nhttps://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/\r\nPage 5 of 8\n\nFigure 2. IOMs that CrowdStrike identified as missing AppArmor or SELinux profile on Kubernetes workload\r\nHunting with Falcon to Find Unshare Uses\r\nhttps://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/\r\nPage 6 of 8\n\nAs discussed, attackers can use Linux utility unshare to make unshare() system calls to gain CAP_SYS_ADMIN\r\nprivileges. To hunt for the uses of unshare utility throughout the container environment you can use the following\r\nFalcon query, which casts the widest net possible to locate unshare utility uses within your container environment.\r\nindex=main sourcetype=ProcessRollup2* event_simpleName=ProcessRollup2 event_platform=Lin OciContainerId=*\r\n| search FileName=unshare\r\n| stats dc(aid) as ContainerAid count(aid) as detectionCount, values(ComputerName) as endpointNames by ParentBas\r\n| sort - detectionCount\r\nYou can further drill down using CrowdStrike Threat Graph® to learn more about the issue. Figure 3 shows\r\nunshare utility being used within a container located with the above Falcon hunt query.\r\nFigure 3. CrowdStrike Threat Graph for unshare utility (Click to enlarge)\r\nConclusion\r\nOrchestration platforms like Kubernetes are distributed systems software that depend on a number of small\r\ncomponents with their own lifecycle and attack surfaces. From time to time we see that a relatively simple bug can\r\nbecome a huge security risk when combined with design mechanics, security issues and default insecure\r\nconfigurations. It is therefore paramount that users stay on top of any security concerns and make appropriate\r\nchanges as soon as possible. Securing containers need not be an overly complex task. Using the Falcon platform,\r\nyou can easily identify security issues in your environment in real time. You can use built-in features of\r\nKubernetes and best practices to keep your container environment safe. For enhanced security you can use\r\nintegrated container security products such as CrowdStrike Falcon® Cloud Security that can protect your\r\nkubernetes environment seamlessly. CrowdStrike strives to support organizations that allow their users to stay\r\nahead of the curve and remain fully protected from adversaries and breaches.\r\nAdditional Resources\r\nLearn more about CrowdStrike Falcon® Cloud Security.\r\nLearn more about CrowdStrike Falcon® Insight™ endpoint detection and response .\r\nhttps://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/\r\nPage 7 of 8\n\nTest CrowdStrike next-gen AV for yourself. Start your free trial of Falcon Prevent™ today.\r\nSource: https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/\r\nhttps://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.crowdstrike.com/blog/cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit/"
	],
	"report_names": [
		"cve-2022-0185-kubernetes-container-escape-using-linux-kernel-exploit"
	],
	"threat_actors": [],
	"ts_created_at": 1775434677,
	"ts_updated_at": 1775791254,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/16e1bad7701a97fc5b2a1bf156aecf4a166ea306.pdf",
		"text": "https://archive.orkl.eu/16e1bad7701a97fc5b2a1bf156aecf4a166ea306.txt",
		"img": "https://archive.orkl.eu/16e1bad7701a97fc5b2a1bf156aecf4a166ea306.jpg"
	}
}