Machine identity systems are supposed to end the era of long-lived secrets sitting in config files. Instead of handing every service a password that never changes, SPIFFE and its reference implementation SPIRE issue each workload a short-lived, cryptographically signed credential and rotate it constantly. Unit 42 researcher Eviatar Garzi has now shown what happens when the one assumption underneath all of that fails.
Get root on the machine, and the machine will lie for you.
In newly published research, Garzi demonstrates that an attacker with root access on a Kubernetes node can forge the metadata SPIRE uses to work out which container is asking for a credential, and walk away with the identity of a completely different workload on that node. Unit 42 says plainly that it has not observed the technique being used in attacks.
How SPIRE decides who is asking
Every node runs a SPIRE agent. When a workload wants a credential, it connects to that agent over a local socket, and the agent works out who the caller is by looking at the process. The Kubernetes plugin reads the caller's control group path from the /proc filesystem, which is the Linux mechanism that records which container a process belongs to. From that path it extracts the pod identifier and the container identifier, asks the kubelet for that pod's metadata, and builds a list of attributes: namespace, service account, pod name, labels, container image and so on. If those attributes match a registration entry on the SPIRE server, the agent hands over the credential.
Every step of that chain reads from files on the node. Root controls those files.
A container that claims to be its neighbour
Garzi set up a registration entry for a pod called workload-a and first confirmed the guardrail worked as designed: asking the agent for that identity from the host itself returned a flat refusal, "no identity issued". He then located the real pod's process, forged the control group path so the agent would read the victim workload's pod and container identifiers instead of the attacker's own, and asked again. This time the agent matched the spoofed attributes against the registration entry and issued the credential.
The practical consequence is that anything trusting that identity, any internal service, database or API that accepts the workload's credential over mutual TLS, will now accept the attacker. Short credential lifetimes do not help, because the attacker is not stealing a certificate that expires. They are impersonating the workload at the point of issue, and can simply ask for a fresh one whenever they like. Unit 42 also released an open-source tool, Spooffe, so defenders can test how far this reaches in their own clusters and see which identities a single compromised node actually exposes.
Treat node root as identity root
Unit 42's guidance is a threat modelling correction more than a patch note. Organisations running SPIFFE and SPIRE should assume that root-level access to a node grants access to every cryptographic identity scoped to that node, and design blast radius accordingly. The concrete steps are node hardening, restricting who and what can obtain root, prohibiting privileged containers and host access, and reducing reliance on weak selectors, meaning attributes that are easy for a process on the same box to fake rather than ones anchored in something an attacker cannot control.
None of this is a flaw in SPIFFE's cryptography, and nothing here is a patchable vulnerability with a version number attached. It is the trust boundary working exactly as documented, in a situation the documentation warns about and many deployments quietly assume will not happen. It sits alongside the recurring lesson from cluster-level research such as Kubernetes storage flaws that let one tenant read another's files and container escapes that reach the host: shared infrastructure keeps proving to be a shared fate.
The value of a machine identity system is that it makes the question "who is this service" answerable. Garzi's work is a reminder that the answer is only ever as good as the node being asked.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.