A single Kubernetes worker falls to root, and every service that trusts SPIFFE identities from that box becomes a door. Attackers harvest and spoof co-located workload identities, then call APIs that still believe the caller is a legitimate sidecar or job. Unit 42 documented this post-exploitation path in SPIFFE/SPIRE. Your cybersecurity program will cordon the node. The identities already walked off it. Teams that treated node loss as a compute incident will spend the next week learning which production APIs accepted those stolen SVIDs.

Node Root Converts SPIFFE Trust Into Impersonation

You put SPIFFE/SPIRE in so pods stop sharing long-lived cloud keys. Short-lived SVIDs, bound to a SPIFFE ID, presented over mTLS. That beats a static token sitting in an environment variable for six months. It also creates a failure mode a lot of threat-protection designs never priced in: the identity issuer lives on the same kernel as the workloads it attests.

SPIRE’s agent sits on the node. Workloads ask it who they are. The agent answers from selectors it can observe, service accounts, process metadata, filesystem layout. Root on that worker can read the same metadata, reach the same sockets, and request or copy identities for neighbors that never got popped on their own. The mesh does not get a vote.

Root access on a compromised Kubernetes node lets an attacker use SPIFFE/SPIRE metadata to spoof and harvest co-located workload identities.

Unit 42’s finding is the part you should tape to the on-call wiki. Once those identities exist, east-west checks that only verify the SPIFFE ID will pass the traffic. Your firewall and network policy can be letter-perfect and still usher the caller through, because the caller looks exactly like the payment adapter, the job runner, or the secret consumer you intended to trust.

Brute-force against those short-lived credentials is the wrong picture. The attacker is not guessing. They are borrowing. Shared-kernel workers with a mix of anonymous front-end pods and anything that can mint cloud credentials give them a buffet. Dedicated node pools and VM-isolated hosts change that math. A crowded worker does not.

Draining the Worker Leaves Stolen Identities Alive

Most Kubernetes incident response playbooks stop at the host. Cordon. Drain. Reimage. Maybe rotate a bootstrap token. That closes the machine. It leaves conversations already opened with stolen SVIDs, cached JWTs, or downstream tokens those workloads exchanged while they still looked legitimate.

SPIFFE IDs are meant to expire quickly. Expiry is not revocation. If your services accept a JWT SVID until the clock runs out, and your X.509 path has no revoke step anyone has ever rehearsed, the attacker keeps a window. They will use it the way your operators use it: talk to the APIs those identities were authorized for.

Threat detection that watches for mystery Deployments or weird images will miss a caller that already holds a blessed identity. You need logs that say which SPIFFE ID called which service, from which node, at which time. Plenty of meshes can emit that. Plenty of SOCs never onboarded it, because the original pitch was that workload identity retired a class of alerts.

Human identity failed the same way, on a different plane. Attackers have been calling employees’ personal phones since at least May 2026, posing as internal IT, then walking into Microsoft 365, SharePoint, OneDrive, and mail. Microsoft’s researchers say the dwell can last weeks. Different ingress. Same lesson for cyber security programs: once the IdP or the mesh believes the caller, interior traffic looks authorized.

When a worker is owned, assume every identity it could issue is hostile until you prove otherwise. Reimaging the node without hunting those IDs is how stolen SPIFFE credentials outlive the isolation ticket.

Cybersecurity Containment That Stops at the Node Still Fails

Write the node-compromise runbook as if SPIRE were an identity provider, because it is. Do the host work and the identity work on the same clock. Security hardening on the worker lowers the odds of root. Defense in depth is what you have left after root anyway: authorization audiences, network policy, and a revoke path you have actually fired in anger.

Run these steps in real environments, without waiting on a specific vendor feature:

• Today: snapshot the worker, then cut it off from the control plane and from the SPIRE server so it cannot mint fresh SVIDs while you investigate.
• Today: enumerate every pod, service account, and SPIFFE ID that ran there for the full SVID lifetime, not just the pods still scheduled when you noticed.
• Today: revoke those SVIDs and rotate every downstream cloud key, database role, queue credential, and CI token those workloads could mint or read.
• Today: hunt mesh, gateway, and application logs for those SPIFFE IDs calling unexpected audiences; treat a hit as confirmed identity abuse, not as noisy east-west traffic.
• After: pin high-value issuers, vault agents, and CI runners to tainted node pools so a rooted general worker cannot stand next to them.
• After: bind JWT SVIDs to explicit audiences, ship Workload API issue logs into the same SIEM path you use for human IdP sign-ins, and tabletop a rooted worker twice a year with identity revocation as the pass condition.

If you cannot name the SPIFFE IDs that lived on a given worker, and you cannot kill them in an hour, the mesh is an accountability hole. Rebuild from a known image. Do not “clean” the node and return it to rotation. The control you wanted from SPIFFE still depends on a host you no longer believe.

Sources

• The Machine With Many Faces: Post-Exploitation Identity Misuse in SPIFFE/SPIRE
• Attackers call employees’ personal phones to break into Microsoft 365 accounts