The Blast Radius of Standing Access

A Pattern in Three Acts

Between late April and late May 2026, the supply chain attack pattern
that had been building since 2025 reached a kind of grim maturity.
The threat actor TEAM-PCP, which also operates under the aliases
PCPcat, DeadCatx3, ShellForce, and CipherForce, ran three connected
campaigns in roughly five weeks. The campaigns share enough
operational detail that they can be read as a single coordinated
effort, distinct in tradecraft from the more opportunistic supply
chain attacks of previous years.

The first act, which began on 29 April with the compromise of the SAP
Cloud Application Programming Model packages and continued through 30
April with PyTorch Lightning, was reconnaissance at scale. The
ecosystem that hosts hundreds of millions of weekly package downloads
turned out to have a very small number of credential surfaces that an
attacker needed to compromise to gain publication rights to vast
swaths of it. The reconnaissance produced targets.

The second act began on 11 May. Across roughly five hours that night,
the actor published more than four hundred malicious package versions
across one hundred and seventy two distinct packages on npm and PyPI.
The packages were not random. They were chosen for their position in
the dependency graph. The TanStack ecosystem, which includes the
react-router package that sees approximately twelve million weekly
downloads, was the largest single target. The UiPath, Mistral AI,
OpenSearch, and Guardrails AI ecosystems were attacked in parallel.
The CVE assigned to the TanStack compromise alone, CVE-2026-45321,
carries a CVSS score of 9.6 and covers forty two packages across
eighty four versions. The compromise was not a vulnerability in the
traditional sense. The malicious code was the package. The whole
release was the exploit.

The third act played out over the following ten days. OpenAI
disclosed that two employee devices had been compromised in the
TanStack chain, with internal source code accessed and platform code
signing certificates rotated. Mistral AI confirmed one device
compromise and a twenty five thousand dollar extortion demand for a
five gigabyte source code dump. Grafana confirmed that a stolen
GitHub token had been used to access its codebase. SailPoint
disclosed a third-party-application breach of its GitHub
repositories. The pattern culminated on 20 May with the disclosure of
approximately thirty eight hundred internal repositories exfiltrated
from the platform that hosts most of the world's open source code,
through a poisoned editor extension on one employee laptop.

By the time the actor open-sourced the worm under an MIT license on
the same platform they had just exfiltrated, the pattern was
visible. The pattern is what this post is about.

The Worm and Its Method

The malware family at the center of the campaign is called
Shai-Hulud, after the sandworm of Frank Herbert's Dune. The name has
been carried across multiple variants since 2025, most recently the
Mini-Shai-Hulud campaign that drove the May activity. The Shai-Hulud
operational model is worth understanding in some detail because the
defenses it defeats are the defenses most organizations have built.

The worm executes at package install time. There is no vulnerability
to patch. The install hook is a feature of every modern package
manager, and a maliciously published package version contains
arbitrary code that the package manager will execute as a matter of
course on every developer machine and CI runner that depends on it.

On execution, the worm enumerates the local environment for
credentials. The target list is comprehensive and tells you what
defenders are protecting badly. AWS IAM access keys. Google Cloud
service account JSON files. Azure managed identity tokens.
HashiCorp Vault tokens. Kubernetes service account tokens.
Personal Access Tokens for GitHub, GitLab, Bitbucket. npm publish
tokens. PyPI tokens. Docker registry credentials. SSH private keys.
The worm also extracts cloud metadata from the standard endpoints
when it finds itself on a runner, including the AWS Instance
Metadata Service 169.254.169.254 endpoint that has been a
recurring source of compromise since 2019.

The worm then attempts to self-propagate. The stolen npm or PyPI
publish tokens are used to push new malicious versions of any other
packages the developer or runner can publish. The stolen GitHub
tokens are used to push to repositories. The new releases carry the
same worm, which in turn extracts credentials from the next set of
machines that install them. The propagation is faster than human
incident response on most reasonable schedules.

Two features of the worm deserve specific attention because they
make conventional remediation harder. The first is persistence. The
worm installs hooks into Claude Code and VS Code that survive
reboots and re-execute on next launch. A developer who detects the
compromise, removes the package, and reboots is not clean. The
worm reappears. The second is the dead-man switch. The worm watches
for revocation of the tokens it has stolen, and on revocation, it can
execute destructive actions on the host. This shifts the operator's
incentive structure in a way that benefits the attacker. Fast
revocation, the standard incident response advice, can trigger
destruction of the developer's local data.

The worm source code is now public. The actor released it on GitHub
under an MIT license, which means the operational pattern is now
available to anyone who wants to fork it. The next wave of attacks
in this family will not necessarily be by TEAM-PCP. They will be by
whoever decides to fork the code and target a different ecosystem.

The Conventional Reading and Its Limits

The conventional reading of these incidents is that the editor and
package ecosystem need to harden. Better marketplace vetting for VS
Code extensions. Mandatory signing for npm and PyPI packages.
Behavioral analysis during installs. Sandboxed install environments.
Each of these proposals has merit. Each of them addresses the vector.
None of them addresses the blast radius.

The blast radius is the part of the incident set that should change
how every CISO in the industry thinks about developer endpoints. One
compromised laptop at a major code-hosting platform produced
exfiltration of thirty eight hundred internal repositories. Two
compromised laptops at an AI lab produced access to platform source
code substantial enough to require rotation of code signing
certificates. One compromised maintainer account at a SDK vendor
produced a five gigabyte source code leak. These are not separate
problems. They are the same structural problem, observed across
different victims.

The structural problem is that developer endpoints, in 2026, hold
trust relationships that are wildly out of proportion to the security
posture applied to the endpoint itself. The developer laptop has,
in normal practice, broad read access to organizational source code,
broad write access to selected repositories, cloud credentials for
the services the developer works with, container registry
credentials, kubectl credentials for development clusters, and
typically session tokens for any internal service the developer has
visited in the past week. The endpoint is treated by the operator as
a workstation. The endpoint is treated by the security architecture
as a low-privilege device. The endpoint is, in reality, a
high-privilege device that controls access to the organization's
most valuable assets.

The Shai-Hulud worm is what happens when this gap is exploited at
scale. The next worm in this family will exploit the same gap. The
attacker community has now learned, through five weeks of public
demonstration, that compromising developer endpoints is a high-yield
strategy. The investment in defending the rest of the stack against
network-level attacks, against perimeter intrusions, against
phishing of the executive class, has paid off enough that the
attacker economics have shifted. The endpoint that the developer
uses to read code is now the cheapest path to that code.

The Flat-Access Model and Why It Persists

The specific feature of developer endpoint access that produces the
catastrophic blast radius is what can be called the flat-access
model. Most engineering organizations above approximately fifty
engineers operate on a default where any employee in the engineering
function has read access to most or all of the company's source code.
The model is widespread. It is not particular to any one company. It
is the structural inheritance of the engineering culture that grew
out of the Google-style monorepo and the open-source development
practice that adjacent companies adopted.

The justifications for the model are coherent on their own terms.
Engineers need to read code that is not in their own service to
understand how systems interact. Internal mobility between teams
should not require lengthy access grants. Architecture diagrams,
runbooks, and postmortems are most useful when they are searchable
across the organization. Internal grep across all repositories is a
productivity multiplier that compartmentalization breaks.

The justifications are not wrong. They are the reasons high-velocity
engineering organizations have outperformed lower-trust environments
for the last twenty years. The cost is the one that has now become
visible. A compromised endpoint inherits the access of the user,
which in this model is access to the entire codebase.

The Zero Trust movement, which started in earnest with the Google
BeyondCorp project around 2014 and has been the official direction of
enterprise security architecture since approximately 2018, addresses
this problem in principle. The BeyondCorp model removes the
perimeter and treats every access decision as if the user were on
the public internet. The principle has been adopted in the abstract
by most major enterprises. The implementation has typically stopped
at the network layer. Strong authentication. Device posture checks.
Network microsegmentation. The implementation has not, in most
organizations, reached the source-code access layer in any meaningful
way.

The reason for the gap is the same reason flat access persists.
Just-in-time access tooling exists. Engineers do not like to use
it. The friction of request-and-wait, even when the wait is short,
even when the request is automated, is more visible than the
security risk it offsets. An engineer blocked on a thirty-second
access grant is a visibly blocked engineer. An endpoint compromise
that would have been contained by the same control is an invisible
saved incident. The trade-off is symmetric in expected value and
asymmetric in perception. Engineering organizations have repeatedly
chosen the visible thing.

The Spring 2026 pattern is the kind of event that should shift the
perception, because the cost of the choice has become legible in
ways that previous incidents did not make legible. Whether it will
shift the perception is a different question and the historical
pattern is not encouraging.

What Proper Access Boundaries Would Look Like

The architectural alternatives to standing flat access are
well-understood and have been implemented somewhere by someone. The
question is not whether they exist. The question is whether the
operational discipline exists to apply them at scale. Four patterns
are worth listing because they constitute most of the available
state of the art.

Scoped service accounts for tooling. Most developer interaction
with source code happens through tooling, not through the web
interface. The IDE clones the repository. The CI pipeline pushes
images. The local CLI fetches the latest. Each of these uses can be
authenticated through a token that is scoped to the specific
repositories the engineer actually works in, refreshed on a short
cadence (hours, not weeks), and revoked when no longer in active
use. The broad organizational session, which is the credential that
the worm actually wants to steal, can be reserved for the rare cases
where it is genuinely needed and protected by hardware token
authentication. The implementation requires fine-grained tokens,
which GitHub has supported since 2022 and which other forges support
in similar ways. The operational change is to actually use them
rather than treating them as an opt-in feature for the security-conscious.

Just-in-time elevation for cross-repository work. The standing
access for any given engineer should be their own team's repositories
and a small number of explicitly declared dependencies. Access to
other repositories requires an explicit request, justified by a
ticket or by a senior approval, with a defined expiration. The
existing tools (Sym, ConductorOne, AWS IAM Identity Center session
management, Microsoft Entra Privileged Identity Management,
Teleport, the new BeyondTrust EPM offering) all implement variations
of this pattern. The pattern slows things down. The slowdown is the
security control. The friction is the point, not a bug.

Read access logging at per-repository granularity with anomaly
alerting. If an engineer with broad access starts cloning every
repository in the organization, that pattern should produce an alert
in the first ten repositories, not the four thousandth. The volume
of cloning that preceded the exfiltration in the major incidents of
the spring 2026 pattern must have been enormous. Either it was
logged and not alerted on, or it was not logged at the granularity
required to detect. Both are problems. The right state is that
exfiltration of thousands of repositories from one endpoint
produces tooling alerts long before completion.

Endpoint isolation for the credential surface. The credentials
that grant access to internal repositories should not live on the
same endpoint as the credentials that get used by a
randomly-installed editor extension. Hardware tokens with explicit
touch confirmation for git operations. Dedicated workstations or
virtual machines for sensitive code, separated from the
extension-heavy IDE work that engineers do for daily development.
The pattern of a single laptop being the trust anchor for everything
an engineer does was always indefensible from a security architecture
perspective. The cost of separating it is real. The cost of not
separating it is what happened to thirty eight hundred repositories.

None of these four patterns is a silver bullet. All of them are
imperfect. Combined, they reduce the blast radius of a compromised
endpoint from thousands of repositories to dozens, which is the
difference between a structural breach of the organization and an
embarrassing incident.

The IDE Extension Layer

The vector that produced several of the spring 2026 incidents
deserves its own treatment, because while it does not address the
blast radius, it is also a category of problem that should not have
survived to 2026 in the state it is in.

The IDE extension model in VS Code, Cursor, JetBrains products, and
most other modern editors has no meaningful permission model. An
extension that the user installs from a marketplace has full access
to the user's home directory, all credentials stored on the machine,
all SSH keys, all cloud configuration, all environment variables,
all process memory in some configurations, and outbound network
access. The extension can do whatever the operating system allows
the user to do. The extension is in practice indistinguishable from
arbitrary code execution as the user.

This is a category of problem that browsers solved years ago. The
browser permission model is far from perfect, but at least an
extension that wants the user's microphone has to ask. The user
sees the request. The user can decline. The browser maker has
chosen to make capability-bound permission the default, and the
ecosystem has adapted around it.

The editor ecosystem has not made this choice. The architectural
debt has been visible for years. The Spring 2026 pattern is the
first time the debt has been paid back at scale in publicized
form. There were earlier incidents that pointed at the same
problem (the 2024 trojanized extensions with nine million installs,
the 2025 WhiteCobra crypto-stealing campaign), but they did not
produce structural change because the cost was always borne by
individual users.

The cost is now borne by GitHub, OpenAI, Mistral, Grafana, and the
broader open source ecosystem. The pressure for an editor extension
permission model has shifted from "would be nice" to "is overdue".
Microsoft, which owns both VS Code and GitHub, is in the position
to drive this change unilaterally. The economic incentive to do so
is now substantial. Whether the incentive will translate to
implementation is a separate question.

The honest summary is that the editor extension layer is the
vector that needs hardening, and the access model is the blast
radius that needs reducing. The two are independent fixes at
different layers. Implementing one without the other still leaves
the system exposed in different ways. Implementing both is the
direction that the Spring 2026 pattern points at.

The Cost of Doing This Right

Everything proposed above has a cost. The honest part of this
argument is that the cost is real and it is paid by engineers in
their daily work.

Scoped service accounts add complexity to developer tooling. The CI
pipeline needs to know which token to use for which repository. The
local clone needs the right credential helper. The token rotation
schedule needs to be visible. New engineers need to be onboarded to
a more complex credential model than the single Personal Access
Token they currently get.

Just-in-time access adds latency to cross-team work. The engineer
who needs to read another team's repository has to request access,
wait for the request to clear (even if the wait is automated and
short), and remember to do this on every new piece of cross-team
work. The grep-across-everything pattern that produces serendipitous
insight is broken. The replacement, which is grep within
already-granted scopes plus targeted requests for the rest, is
genuinely less convenient.

Per-repository read alerting generates false positives. The
investigation cost of those false positives is paid by the security
team and ultimately by the engineering organization through reduced
appetite for adding more alerts. The signal-to-noise ratio is the
practical constraint.

Endpoint isolation adds hardware cost and operational overhead. The
dedicated workstation for sensitive code is a physical object that
has to be procured, maintained, patched, and replaced on a schedule.
The virtual machine equivalent has its own friction. Engineers who
have to context-switch between machines lose some of the seamless
flow that drove the unified-laptop model in the first place.

The total tax on engineering productivity from a serious
implementation of these controls is substantial. It is paid every
day, by every engineer, in exchange for reducing the impact of
incidents that happen rarely. The trade-off is real and the answer
is not obvious. Different organizations will land in different
places, and the differences will be visible in the next round of
breach disclosures.

Why This Time May Be Different

The pattern of past incidents has been that public breaches produce
short-term attention and long-term reversion. The 2015 Sony breach
did not change studio infrastructure investment for more than a
fiscal year. The 2020 SolarWinds attack did not change SBOM
adoption for more than a quarter. The 2021 Log4Shell event
produced six months of intense scrutiny followed by approximate
return to baseline. The expectation, based on this history, is that
the spring 2026 supply chain pattern will produce six months of
serious work and then quiet attrition of priority.

There are two reasons to think this time may break the pattern.

The first is the cumulative weight of the incidents. The breach
disclosure cadence in spring 2026 was approximately one major
public incident every two weeks. Engineering teams that survived
this quarter without being directly hit have nonetheless had to
explain to their leadership why they will not be next. The
leadership attention is unusually durable when the question is
"could this happen here" rather than "did this happen here", and
the answer in most organizations is "yes, plausibly". The
post-mortem fatigue that usually erodes priority has not yet kicked
in because the post-mortems are not yet finished.

The second is that the threat model has changed in ways that even
non-security executives can see. The Shai-Hulud worm being released
under an MIT license is a meaningful event. It means the cost of
running the next campaign in this family has dropped to near zero
for any actor with moderate skill. The supply of threat actors who
can run this kind of campaign just expanded by approximately the
size of the global population of people who can read GitHub code.
The defensive posture that was barely adequate against TEAM-PCP
will not be adequate against a hundred copycats running variations.

Whether these two factors are enough to overcome the historical
pattern of post-breach attention decay is the question that the
remainder of 2026 will answer.

Closing

The Spring 2026 supply chain attack pattern made visible something
that has been true for a long time. Developer endpoints, in the
configuration most engineering organizations use, carry trust
relationships that are wildly out of proportion to the security
investment the endpoint receives. The compromise of one such
endpoint can produce a structural breach of the organization.

The fix is not at the endpoint alone, though endpoint hardening is
necessary. The fix is at the trust model. The access an engineer
holds should be the minimum required for the work they are
currently doing. The persistence of that access should be the
minimum duration the work requires. The visibility into the use of
that access should be the maximum granularity the logging
infrastructure can support.

The patterns to implement this are known and the tools to support
it exist. The remaining question is whether engineering
organizations will absorb the friction cost. The historical answer
has been no. The cost of saying no has just become substantially
higher than it was a quarter ago.

The actor community has learned what this quarter taught them.
Defenders have a finite window to learn the same lesson before the
next campaign arrives.