Kubernetes Attack Lets Hackers Steal SPIFFE Workload Identities and Impersonate Applications

A post-exploitation technique that lets attackers with root-level access to a Kubernetes node steal workload identities issued through SPIFFE/SPIRE and impersonate legitimate applications running on the same host.

The technique undermines the node-trust assumption behind cloud-native machine identity systems, potentially enabling attackers to access services protected by mutual TLS and identity-based authorization.

Palo Alto Networks Unit 42 said it has not observed the technique being exploited in the wild.

SPIFFE, or the Secure Production Identity Framework for Everyone, is an open standard designed to replace static secrets, API keys access, and long-lived certificates with short-lived, cryptographically verifiable workload identities.

SPIRE is the production-oriented reference implementation used to attest workloads, issue credentials and distribute trust material across Kubernetes, virtual machine and bare-metal environments.

A workload receives a SPIFFE ID, generally formatted as spiffe://trust-domain/workload-path, and an associated SPIFFE Verifiable Identity Document, or SVID.

The SVID can be delivered as an X.509 certificate for mTLS authentication or as a JWT for application-level authorization. Relying services validate the credential against a trust bundle before accepting the workload’s identity.

This model provides strong boundaries while the host remains trustworthy. But Unit 42’s research shows that the boundary collapses after node-level compromise.

Unit42 Researchers highlights that, a critical limitation for organizations using SPIFFE/SPIRE: once a Kubernetes node is compromised at the root level, every workload identity available to that node should be considered exposed.

Kubernetes Identity Attack

Rather than needing to break the cryptography protecting a target application’s SVID, an attacker can abuse the local identity-issuance process trusted by that application.

The attack targets SPIRE workload attestation, the process used by a SPIRE agent to determine whether a local process is entitled to receive a particular workload identity.

In Kubernetes deployments, the agent can derive workload attributes from Linux /proc data and cgroup paths, then correlate the discovered container and pod details with Kubernetes metadata.

Those attributes, known as selectors, may include Kubernetes namespace, service account, pod UID, pod name, container image and Linux UID or GID.

The SPIRE agent compares the selector set with locally cached workload registration entries before releasing the corresponding SVID.

Unit 42 found that an attacker with root privileges can manipulate cgroup metadata for an attacker-controlled process to make it appear associated with another co-located container.

The malicious process can then request credentials through the local SPIFFE Workload API, causing the agent to issue a valid SVID belonging to the impersonated workload.

The consequences extend beyond credential theft. A stolen X.509 SVID could let the attacker authenticate to internal services over mTLS as the victim application.

A JWT-SVID could be accepted by identity-aware APIs or authorization layers where the target workload’s SPIFFE ID is trusted. In effect, node compromise can become a lateral-movement and privilege-escalation opportunity inside the cluster.

To help defenders test exposure, Unit 42 released Spooffe, an open-source assessment tool.

It scans a node for running workloads, identifies their cgroup paths, creates spoofed cgroup structures for its own process and queries the local SPIRE agent for the identities that may be retrievable.

The tool is intended for authorized defensive validation, allowing security teams to identify which SVIDs could be harvested if an adversary gains administrative access to a worker node.

It also includes functionality to examine agent-impersonation scenarios, though the research focuses primarily on selector spoofing through cgroup manipulation.

The finding does not indicate that SPIFFE cryptography is broken. Instead, it reinforces that workload identity is only as strong as the node’s security boundary.

Organizations should treat root access on a Kubernetes worker as exposure of all identities scoped to that node.

Defenders should harden nodes, tightly restrict root and privileged-container access, prevent unnecessary host namespaces, sockets and filesystem mounts, and minimize dependence on weak or overly broad workload selectors.

Security teams should also review which high-value identities can be issued from each node and use Spooffe in controlled environments to measure the potential blast radius.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC