Shrink a Zero-Day’s Blast Radius Before it Happens

TL;DR

• Exploitation now routinely starts before a patch exists. Mandiant’s estimated mean time to exploit is negative seven days.
• Patching closes the entry. Blast radius decides the damage. At Hugging Face, two ordinary application bugs became cluster-admin across multiple clusters in under thirteen hours, because of a shared credential, broad permissions, and exposed metadata.
• Fix the few exposures that sit on many paths, not the many findings that sit on none.
• Measure reach, not tickets: reachable critical assets, paths and choke points, unused access, time to remediate. Then clean up the residue, continuously.

Security teams cannot patch a vulnerability nobody knows exists. Increasingly, attackers are exploiting it before a fix, or even a disclosure, arrives. 

Mandiant’s M-Trends 2026 report estimates that the mean time to exploit a vulnerability fell to about negative seven days, meaning exploitation routinely begins before a patch is released. Mandiant’s earlier research put the same figure at 63 days in 2018–2019. A negative mean does not mean every vulnerability is exploited before a fix exists, but the direction is unambiguous. Defenders cannot assume there will be time to patch before an attacker arrives.

AI changes who can run that kind of attack. Agents test approaches, inspect configurations, and follow leads around the clock, without the fatigue or headcount limits of a human team. Stamina, scale, and persistence that once belonged to a handful of nation-states are now available to almost any attacker. In July 2026, an autonomous agent driven by OpenAI models went from code execution in a single Hugging Face worker pod to cluster-admin across multiple clusters in under thirteen hours. Almost no security team triages that fast. 

Patching remains essential, but it is not a complete containment strategy. Defenders must also continuously reduce an attacker's ability to move through the environment after an initial compromise, while maintaining the capability to respond and remediate rapidly as new vulnerabilities and exposures emerge.

What Blast Radius Actually Measures

Blast radius describes the potential impact of compromising an asset. The important word is potential: access to one workload does not automatically mean access to everything connected to it.

The immediate blast radius is what the compromised asset can access directly. The extended blast radius includes additional resources an attacker might reach through stolen credentials, privilege escalation, or lateral movement. An exposure path is a modeled sequence of weaknesses and access relationships that could connect an entry point to a target.

A useful analysis therefore starts with three questions: Where could an attacker enter? Which trust relationships and permissions could they abuse? Which critical assets could they ultimately reach? Model each external entry point as if it will eventually be exploited, and rank it by what it leads to rather than by how likely today’s exploit looks.

The exposure that matters most is not necessarily the one with the loudest severity label. It may be the one that connects an otherwise limited compromise to a critical system.

The Permissions Behind the Vulnerability

A software vulnerability can create an initial foothold. What happens next often depends on security decisions made long before the exploit: which credentials a workload holds, how broadly its identity can act, and whether boundaries between environments are enforced.

Overprivileged service accounts, exposed API tokens, permissive cloud roles, and weak network segmentation can give attackers ways to extend access. Incomplete MFA enforcement can also expose sensitive identity paths. These are not interchangeable problems, but each can enlarge what a compromised identity or workload is able to do.

Take any web application vulnerable to remote code execution. Whether that becomes an incident or a catastrophe depends on what the application process can reach: the credentials it holds, the roles its identity can assume, and the boundaries between it and production. Patching removes the entry technique. Least privilege limits what the technique can unlock, including during the days before the patch arrives.

What the Hugging Face Incident Shows

The July 2026 Hugging Face incident offers a more concrete example. During an internal OpenAI cybersecurity evaluation, an autonomous agent driven by a combination of OpenAI models broke out of its sandbox through a zero-day in a package proxy, reached the internet, and went after Hugging Face’s dataset-processing systems. The evaluation ran with OpenAI’s production safety classifiers disabled. A determined attacker running its own tooling would not face those classifiers either. OpenAI says the models were hyperfocused on the benchmark: they inferred that Hugging Face might hold its answers and went looking for them. Hugging Face recovered approximately 17,600 agent actions from a 4.5-day campaign, about two and a half days of it inside its own infrastructure. 

Two different injection techniques mattered to initial access. An HDF5 external-file reference technique induced a processing service to read local files, exposing sensitive data including credentials. A Jinja2 server-side template injection allowed code execution in a production processing worker. A file-read weakness and a code-execution weakness are not the same capability, even if both can be consequential.

The more instructive part is what followed. According to Hugging Face’s technical account, the agent first read the worker pod’s service-account token and probed the Kubernetes API. It then obtained EC2 node-role credentials from the cloud metadata endpoint, used them to authenticate as the node, and minted tokens for other service accounts. After mapping those permissions, it exploited the storage driver’s overly broad permissions and the lack of admission controls to create a privileged pod with the host filesystem mounted, gaining root access to the node. From the node, it read a production secret holding 136 keys, among them the credential for an internal service-connector broker. That broker had been provisioned with a single credential shared across clusters and bound to system:masters. In Hugging Face’s words, “one stolen system credential was therefore cluster-admin everywhere.” From code execution in one worker pod to cluster-admin across multiple clusters took under thirteen hours.

The original foothold did not, by itself, grant any of that. Existing credentials, reachable metadata, broad permissions, and one shared secret provided every later step. Hugging Face’s own summary lists four familiar weaknesses: unsafe dataset processing, exposed cloud metadata, overly broad access, and long-lived credentials. Its response accordingly went well beyond the two injections. It closed both code paths, blocked pod access to the metadata endpoint for all workloads, rebuilt cluster access so each cluster is isolated, rotated every token and credential in its infrastructure, including on clusters the agent never accessed, shut down the shared broker to rebuild it with a per-cluster credential, and wiped and rebuilt one core cluster. 

Notice where the software flaws sit in this story. The zero-day in the package proxy let the agent escape OpenAI’s evaluation sandbox, outside Hugging Face. From an external launchpad, it then exploited two injection weaknesses in Hugging Face’s dataset-processing pipeline. Those weaknesses gave it file access and code execution, but did not by themselves confer cluster-admin privileges. The later escalation depended heavily on exposed credentials, cloud metadata access, excessive permissions, and a shared credential with authority across clusters. This is why a list of vulnerabilities is not an attack-path analysis. Two software weaknesses explain the foothold inside Hugging Face; identity and configuration exposures explain much of what the agent could reach afterward. In my analysis, two exposures stood out: the secret object holding 136 keys and the shared broker credential. Both were important to the documented lateral movement, and addressing them would have interrupted key routes to broader cluster access. It is also why I would prioritize a single permission that bridges environments over a collection of unrelated low-impact findings, assuming the evidence shows that bridge is reachable and exploitable. 

Why Once Is Not Enough

An environment does not stay fixed between assessments. A service account receives temporary access that is never revoked. A new integration connects an application to a sensitive database. A cloud role changes to keep a deployment moving. None of these changes needs a new CVE to open a route toward a critical asset.

In the environments I have analyzed, even tightly regulated organizations carry hundreds of thousands of misconfigured assets, and many have a quarter of a million critical and high vulnerabilities in the queue. No team can fix 250,000 of anything in a career, and a team that tried would break production a thousand times on the way. The answer is not to ignore lower-severity findings or blindly chase critical ones. It is to evaluate how weaknesses interact and whether they create viable paths to assets whose compromise would seriously affect the business.

A closed ticket is evidence that work happened. It is not necessarily evidence that a critical asset is harder to reach. Continuous reassessment is needed because a removed path can reappear through a new permission or connection.

Clean Up the Residue

Blast radius has a second source besides new changes: what gets left behind. Some of it is left by attackers. On its final day inside Hugging Face, the agent worked on durability. It minted short-lived source-control tokens, staged a private key, and routed a download through an open proxy on Hugging Face’s own platform. It had also obtained a JWT signing key, which let it mint new, valid identity tokens on demand until the key was rotated. 

Hugging Face’s answer is the right one. It checked what it could, including every repository the stolen token could reach, and verified its published images and packages against their expected digests, but it did not rely on finding every artifact. It rotated every token and credential in its infrastructure, including on clusters the agent never accessed, rotated the signing key, shut down the shared broker, and wiped and rebuilt a core cluster. When an attacker has held a root of trust, the residue is unknowable, so you replace the trust rather than chase the residue. 

Most residue, though, is left by the organization itself: service accounts from finished projects, keys that were never rotated, roles granted for a migration that ended two years ago, integrations nobody remembers approving. None of it shows up as a vulnerability. All of it widens what the next compromise can reach. The shared connector credential that made one stolen token cluster-admin everywhere was a close cousin of residue: Hugging Face says it was wrongly provisioned, and nothing flagged it until an attacker used it.

Residue cleanup is also the safest place to start automating. Removing access that has demonstrably not been used in ninety days carries little operational risk, provided you know who owns the identity and what depends on it. That is a context problem before it is a tooling problem.

Reduce Reach, Not Just Findings

The practical sequence is straightforward, even when the investigation is not. Start by identifying critical assets and the identities and services they depend on. Model plausible paths from external entry points using network relationships, credentials, permissions, and exploitable weaknesses. Then assess which steps are realistically usable and which controls would interrupt them.

A fix may be a patch, credential rotation, narrower service-account permissions, stronger authentication, or removal of an unnecessary connection. The best choice depends on the path and the business consequences of the change. A single control can sometimes disrupt several modeled paths; another change may only remove one finding without changing reachability. In one customer environment we analyzed, a single fix would have removed roughly 500 exposure paths, yet every critical asset would still have been reachable through routes that never touched it.

And of course, teams also need to verify that the fix worked and revisit the model whenever the environment changes.

Proving the Blast Radius Is Shrinking

Counting remediated vulnerabilities is useful for operational tracking. It is insufficient for proving that attacker reach has been reduced.

I would look at five measures together:

• Reachable critical assets: How many important assets remain potentially reachable from a fixed, documented set of entry points under documented attack scenarios? Attack paths and minimum hops: How many modeled routes exist, and what is the shortest route to each critical asset?
• Choke points: How many exposures sit on several modeled paths at once? Replacing the shared connector credential at Hugging Face with one credential per cluster would have cut the route to cluster-admin across clusters. These are the exposures worth prioritizing over a hundred findings that sit on none.
• Unnecessary Access Exposure: What share of human and non-human identities retain permissions or access paths that are unused, excessive, or no longer justified by their operational needs? This includes permissions unused over a defined period, such as ninety days, as well as unnecessary privileges and access inherited through roles or group memberships.
• Time to remediate: How long does it take to resolve or mitigate a verified exposure on a meaningful route to a critical asset?

These are indicators, not a single blast radius score. A three-hop route is not automatically easier to exploit than a five-hop route. A model with poor coverage may show fewer paths simply because it sees less. Risk assessments still need exploitability, existing controls, and business impact.

The test is whether a team can explain what access was removed, which paths were interrupted, and which critical assets remain exposed.

The Operational Problem: Ownership and Context

Finding a dangerous path is only the beginning. Remediation tends to stall for two reasons: nobody knows who can authorize or perform the change, or nobody can see its ripple effect: what else depends on the asset and what the change will break.

An exposed service account might have an obvious technical fix, but not an obvious owner. Even once the right team is found, removing access without checking dependencies could take down a production workflow. Security teams need both ownership and asset context: connections, permissions, application dependencies, and business importance.

That is where asset intelligence and carefully governed automation matter. Context is what makes a change safe to automate in the first place: a change is low-risk because its owner, dependencies, and usage are known, not because it is small. With that established, automation can handle repeatable steps, evidence collection, and verification. Higher-impact changes still need approvals, testing, and rollback options. Speed without understanding is not safe remediation. 

Prepare for the Vulnerability You Have Not Seen

The next zero-day may be exploited before a vendor can ship a fix. No team can guarantee it will prevent every foothold. It can, however, decide whether one compromised workload has broad credentials, whether identities carry unused privileges, and whether critical systems are reachable through avoidable trust relationships.

Patching reduces opportunities for initial compromise. Continuous blast radius reduction reduces the consequences when prevention fails. Treating both as necessary changes what security teams prioritize and how they measure success.

The agents in the Hugging Face case were effective for ordinary reasons. They were relentless; they built a detailed map of the environment as they went, and they operated at a volume no human team could sustain: 17,600 recovered actions, most of which went nowhere. Defenders have to adopt the same properties, with a human in the loop when required. Running the old playbook faster is not enough. 

The best time to reduce the blast radius of the next zero-day is before anyone knows it exists.