In July 2026 Hugging Face disclosed that an intruder who gained a foothold on a single dataset processing worker escalated to node level access, harvested cloud and cluster credentials, and moved across multiple internal clusters over a weekend. A Cloud Security Alliance post mortem read Hugging Face’s July 2026 disclosure as a textbook case of lateral movement: the break in touched one machine, but what followed turned that one machine into the run of the whole estate. We walk the shape of that problem here on an invented example app, Acme Cluster, and the controls that actually contain it.
The break in is rarely where the damage comes from
Most incident write ups spend their energy on the entry: the unpatched service, the leaked token, the phishing click. But a single compromised host is usually a small problem. It becomes a large one because of what the attacker does next, and what they do next is almost always the same move repeated. Land on one machine, read the credentials sitting on it, use those credentials to reach the next machine, and start again.
The damage scales with how far that loop can travel before something stops it. If the first host holds a credential that opens ten more, and each of those opens ten more, one foothold is the whole cluster within a few hops. The thing worth controlling is not only whether someone gets in. It is how far they get once they are in.
The entry is a door. The blast radius is the building. Guarding the door while leaving every internal room open is how one worker becomes every cluster.
What lateral movement actually looks like
Strip away the tooling and lateral movement is a plain sequence. Consider Acme Cluster, a typical machine learning platform with a fleet of worker nodes, a few internal services, and a cloud account behind them. An attacker gets code execution on one worker, perhaps through a poisoned dependency in a job. From there the steps are boring and reliable:
- Read what is in reach. Environment variables, files mounted into the container, an on disk cache of tokens. Secrets handed to a process at start up tend to stay readable for the life of that process.
- Ask the platform who it is. On a cloud host, the instance metadata endpoint hands back the machine’s own role credentials to anything that can make an HTTP request from that host. On a Kubernetes node, a mounted service account token names a workload identity the API server already trusts.
- Reuse to reach the next hop. Those credentials were minted for the workload, not the person, so they work the same from an attacker’s shell as from the real job. A database password, an internal API key, or a cloud role is now in hand.
- Repeat. Each new host is searched the same way, and standing trust between services means each hop rarely asks for a fresh proof of identity.
Two of those credential sources deserve a closer look, because they are where a single host quietly turns into many. The cloud metadata endpoint is covered in our piece on the instance metadata service, and the Kubernetes case in service account token abuse. Both describe the same failure: a credential that a compromised host can read and replay with no extra check.
Why over scoped and long lived credentials do the real work
The loop only pays off when the credential it finds is worth more than the host it was found on. Two properties make that true. First, scope: a token that can touch the whole cluster is far more useful than one that can touch a single queue. Second, lifetime: a credential that never expires can be harvested today and used next week, which is exactly what a weekend long intrusion needs. An over scoped, long lived credential sitting on a low value worker is a bridge from that worker to everything the credential can reach.
Technique matters too, not just theft. Some moves never read a stored secret at all. An NTLM relay forwards a victim’s authentication to a third service in real time, so the attacker moves sideways without ever seeing a password. Same shape, different mechanism: one identity, reused where it should never have reached.
Containing the blast, not just guarding the door
If the loop is read, reuse, repeat, then the defenses all aim at breaking one link in it. None of them stop the initial break in, and that is the point. They stop the second host from falling.
- Least privilege and tightly scoped credentials. The worker that runs a data job needs the one bucket and the one queue for that job, and nothing else. When its token is stolen, the blast radius is that bucket, not the account. Scope is the wall between hops.
- Short lived over long lived. Swap static keys for credentials that expire in minutes and refresh through the platform. A token harvested from a worker is close to worthless if it dies before the attacker can reach the next host with it.
- Network segmentation. A worker node has no business opening a raw connection to the billing database or another team’s cluster. Default deny between segments means a foothold can only talk to what its job genuinely needs.
- Remove standing trust between services. “Any workload inside the network is trusted” is the assumption that turns one hop into all of them. Make every service prove who it is on every call, so a stolen identity is checked, not waved through.
Notice that these are access control decisions, not intrusion detection ones. Most of them live in the same family as the failures we cover under access control: a system trusting a caller because of where it sits rather than checking what it is allowed to do.
How do you catch it while it is happening?
Prevention narrows the blast radius, but you still want to see the loop in motion. The signal is reuse in the wrong place. A worker’s service account normally talks to two endpoints, then suddenly enumerates the whole cluster. A credential minted for a job in one region is used from an address in another. A node identity that has read the same three secrets for months reaches for a fourth it has never touched.
None of these are malformed requests. Each one is a valid credential used by the wrong hands, which is why the useful detections watch behavior against a baseline rather than scan for bad payloads. Log which identity touched which resource, learn the normal shape per workload, and alert when a credential steps outside the path it has always taken.
This is the kind of assumption an autonomous researcher is built to probe: not “is there a known payload here” but “does this system trust a caller it has no reason to trust, and can that trust be walked from one host to the next.” In our own early testing, a frontier model drove the full methodology on its own and identified and verified real access control and injection issues in test applications it had not seen before. More of our writing sits under access control and on our about page.
Frequently asked questions
What is lateral movement?
Lateral movement is what an attacker does after the first break in: read the credentials sitting on a compromised host, reuse them to reach the next host, and repeat until they hold the whole environment. The initial entry touches one machine, but this loop is what turns one machine into many.
Why does blast radius matter more than the initial entry?
Because a single compromised host is a small problem until the attacker can move off it. If the credentials on that host are tightly scoped and expire quickly, the damage stays contained to one machine. Over scoped, long lived credentials are what let one foothold become the whole cluster.
How do short lived credentials help?
A credential that expires in minutes is close to worthless once stolen, because the attacker has to reach the next host before it dies. Long lived static keys can be harvested today and replayed next week, which is exactly what a slow, multi day intrusion needs.
What credentials do attackers look for on a compromised host?
Environment variables, secrets mounted into the container, an instance metadata endpoint that returns the host’s cloud role, and a Kubernetes service account token. Each one names an identity the rest of the system already trusts, so it can be replayed to reach further.
How do you detect lateral movement in progress?
Watch for a valid credential used in the wrong place: a service account that suddenly enumerates the whole cluster, a token used from an unexpected region, or a node identity reaching for a secret it has never read. The requests are well formed, so detection works off behavior against a baseline, not bad payloads.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.