{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/tags/gcp/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["Google Kubernetes Engine (GKE)"],"_cs_severities":["medium"],"_cs_tags":["gcp","kubernetes","privilege-escalation","container-security","cloud-security","host-ipc"],"_cs_type":"advisory","_cs_vendors":["Google"],"content_html":"\u003cp\u003eThis threat brief describes a privilege escalation vector in Google Kubernetes Engine (GKE) where an attacker with appropriate permissions creates or modifies a Kubernetes pod to enable \u003ccode\u003ehostIPC\u003c/code\u003e namespace sharing. This configuration allows the pod to access and manipulate Inter-Process Communication (IPC) mechanisms on the underlying host node, potentially leading to unauthorized access and control over the host operating system. This technique is a well-known method for container escape and privilege escalation in Kubernetes environments, enabling a compromised pod to break out of its isolation and affect other workloads or the cluster infrastructure. Defenders should focus on detecting this specific pod configuration to prevent adversaries from elevating their privileges within GKE clusters.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eInitial Access\u003c/strong\u003e: An attacker gains initial access to the GKE cluster, potentially through compromised credentials, exploitation of a vulnerable application running within a pod, or misconfigured access controls.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Discovery\u003c/strong\u003e: The attacker assesses their current permissions within the cluster, identifying roles or service accounts that allow for pod creation, update, or patching.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMalicious Pod Specification\u003c/strong\u003e: The attacker crafts a Kubernetes pod specification that includes \u003ccode\u003ehostIPC: true\u003c/code\u003e in its configuration.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePod Creation/Modification\u003c/strong\u003e: The attacker either creates a new pod with the malicious specification or patches an existing pod to enable \u003ccode\u003ehostIPC\u003c/code\u003e sharing. This action requires specific API permissions within the GKE cluster.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eHost IPC Access\u003c/strong\u003e: The newly created or modified pod is now able to interact with the host system's IPC facilities, such as System V IPC or POSIX message queues.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003ePrivilege Escalation\u003c/strong\u003e: The attacker leverages the host IPC access to exploit vulnerabilities or misconfigurations on the host node, allowing them to gain elevated privileges or achieve a container escape.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eImpact\u003c/strong\u003e: With host-level privileges, the attacker can then perform further actions, including lateral movement to other nodes, data exfiltration from the host, or disruption of critical cluster services.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eSuccessful exploitation of this privilege escalation technique allows an attacker to break out of the container's isolation and gain elevated privileges on the underlying GKE host node. This can lead to a complete compromise of the node, enabling the adversary to access sensitive data, install malicious software, disrupt services running on the node, or potentially move laterally to other nodes or even the entire Kubernetes cluster control plane. While no specific victim count is provided, any organization utilizing GKE clusters is susceptible if proper security controls are not in place to prevent or detect such configurations.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eDeploy the Sigma rule \u0026quot;GKE Pod Created With HostIPC\u0026quot; to your SIEM to detect attempts to create or modify pods with host IPC enabled.\u003c/li\u003e\n\u003cli\u003eEnsure GKE audit logging is enabled and configured to capture \u003ccode\u003eio.k8s.core.v1.pods.create\u003c/code\u003e, \u003ccode\u003eio.k8s.core.v1.pods.update\u003c/code\u003e, and \u003ccode\u003eio.k8s.core.v1.pods.patch\u003c/code\u003e events for the \u003ccode\u003egcp.audit\u003c/code\u003e log source.\u003c/li\u003e\n\u003cli\u003eImplement and enforce Pod Security Standards (PSS) or Pod Security Policies (PSP, deprecated) in your GKE clusters to prevent the deployment of pods with \u003ccode\u003ehostIPC: true\u003c/code\u003e in untrusted namespaces.\u003c/li\u003e\n\u003cli\u003eBaseline legitimate usage of \u003ccode\u003ehostIPC\u003c/code\u003e in your environment and configure exclusions in the \u0026quot;GKE Pod Created With HostIPC\u0026quot; rule for trusted users or namespaces if necessary, after thorough review.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-06T16:54:43Z","date_published":"2026-07-06T16:54:43Z","id":"https://feed.craftedsignal.io/briefs/2026-07-gcp-gke-host-ipc-escalation/","summary":"A privilege escalation threat in Google Kubernetes Engine (GKE) involves an attacker creating or modifying a pod to enable host Inter-Process Communication (IPC) namespace sharing, which exposes host IPC mechanisms and can lead to privilege escalation within the cluster by allowing the pod to interact directly with the underlying host's processes.","title":"GKE Pod Created With HostIPC Sharing","url":"https://feed.craftedsignal.io/briefs/2026-07-gcp-gke-host-ipc-escalation/"}],"language":"en","title":"CraftedSignal Threat Feed - Gcp","version":"https://jsonfeed.org/version/1.1"}