Typosquatting is the least sophisticated supply chain attack there is. It is also, stubbornly, one of the most effective — and the campaign that landed on 7 July 2026 shows why the sophistication is now in the payload, not the delivery.
What happened
Roughly 17 packages were published across npm and PyPI impersonating payment provider SDKs — names including paysafe-checkout, paysafe-node, and neteller. Per GitGuardian's analysis, each ran a background routine that harvested environment variables.
The harvesting logic is worth reading closely, because it tells you exactly what the attacker's shopping list looks like in 2026:
- Pattern sweep: any environment variable whose name matched
KEY,SECRET,TOKEN,PASS,AUTH, orAPI. - Named targets:
AWS_SECRET_ACCESS_KEY,GITHUB_TOKEN, andNPM_TOKENexplicitly. - Evasion: the routine detected sandbox conditions — including low CPU core counts — and exited without doing anything.
Detection came in roughly six minutes from publication. Fast. Genuinely impressive ecosystem response.
Six minutes is also plenty. A CI system with a scheduled dependency-refresh job does not sleep for six minutes.
Three things this campaign gets right
Naming that survives a code review. paysafe-node does not look wrong. It looks like exactly the package name a Node SDK for Paysafe would have. This is not expresss with three s's — this is plausible naming in a namespace where the real package might be @paysafe/sdk, paysafe, paysafe-js, or node-paysafe, and nobody can tell you from memory which. Payment SDKs are a particularly good target because integration is usually done once, under deadline, by a developer following a blog post rather than official docs.
Targeting the environment, not the disk. Reading process.env requires no privilege escalation, no file system traversal, no persistence. It is a single expression. And in a modern CI runner, the environment is where everything lives: cloud credentials, registry tokens, signing keys, database URLs. The attacker does not need to be clever because CI hands the secrets over.
The specific inclusion of NPM_TOKEN is the part that should make you sit up. That is not credential theft for resale. That is credential theft to publish the next compromise — which is precisely how the jscrambler attack four days later obtained its publishing rights, and how self-propagating worms like the Shai-Hulud and Miasma families spread.
Sandbox evasion, in a typosquat. This is the notable escalation. Checking CPU core count to decide whether you are in an analysis environment is malware-analysis-evasion technique, appearing in a throwaway typosquatted npm package. It exists for one reason: to defeat automated dynamic analysis in security vendors' sandboxes and in CI-based scanning that runs the package to see what it does.
If your defence is "we execute new packages in a sandbox and watch them," the attacker has already read that playbook. A payload that does nothing when observed and everything when it matters is indistinguishable from a benign package under observation.
The environment variable problem is the actual problem
Step back from typosquatting for a moment. Across all four July campaigns — the PyPI worm wave, these payment SDKs, jscrambler, AsyncAPI — GitGuardian's conclusion was that every one "targeted credentials sitting in developer environments and build pipelines."
That is not four attack techniques. That is one prize, reached four ways.
And the prize exists because of a design decision almost every organisation has made by default: long-lived credentials, injected as environment variables, present for the entire duration of every job. Your CI runner has AWS_SECRET_ACCESS_KEY in its environment from the first second of the job to the last, available to every line of every dependency that executes, whether or not that step needs AWS at all.
A build step that compiles TypeScript does not need your production cloud credentials. It has them anyway, because that is how the pipeline was configured in 2019 and nobody revisited it.
Fix that, and typosquatting becomes an availability nuisance instead of a breach.
Practical hardening, today
- Pin exact versions and use lockfiles with integrity hashes. A typosquat has to be installed once to work; a lockfile means it has to be installed deliberately.
- Scope secrets to the steps that need them. Not the job. The step. Most CI systems support this and most teams do not use it.
- Prefer OIDC federation over static cloud keys. Short-lived, audience-scoped credentials are worth far less when stolen.
- Deny arbitrary egress from build environments. Almost every payload has to phone home.
- Use a private registry proxy with an allowlist, so a package nobody has approved cannot be installed at all — this is the control that actually stops typosquatting dead.
- Audit for near-miss names in your manifests. It takes an afternoon and you will find something.
How Safeguard helps, at scale
Typosquat and namespace-confusion detection at ingest. Safeguard's Supply Chain Core flags packages whose names are edit-distance-near to popular components, newly published, low-download, and unaffiliated with the vendor they appear to represent — the exact signature of paysafe-node. Across an organisation pulling from thousands of manifests, this is a control that cannot be done by human review; nobody knows the canonical package name for every vendor SDK.
500K+ pre-vetted zero-CVE components. The definitive answer to a six-minute detection window is to not source from the open registry at all for anything that matters. A curated, pre-vetted component set means a package published six minutes ago is not reachable by your builds, full stop.
Behavioural analysis that does not depend on executing the sample. Because this campaign specifically evaded sandboxes, dynamic analysis alone is unreliable. Safeguard's eleven scanners combine static analysis of the actual code paths — environment sweeping, egress construction, evasion checks — with behavioural deltas, so a package that contains sandbox-detection logic is itself a strong signal regardless of whether it chose to run.
Lion, for the structural fix — this is the one that matters. Lion enforces just-in-time secret brokering so credentials are not resident in the environment for a dependency to sweep, capability scoping so a build step gets only the access it needs, and egress allowlists so a payload that does execute cannot reach its collection endpoint. At fleet scale this converts the entire campaign class from "breach" to "noise." A process.env sweep of an environment that holds no standing credentials returns nothing.
Secret scanning across manifests, CI configs, and history. Safeguard finds the AWS_SECRET_ACCESS_KEY that is in your workflow file, your .env.example, or your git history — the ones that would be swept — and Griffin authors the remediation PR to move them behind brokered access.
Eagle and Griffin for the aftermath. Eagle scopes which pipelines actually ran an affected version and what was resident in those environments at the time — the only honest basis for deciding what to rotate. Griffin then authors and tests the pinning, removal, and rotation PRs across every affected repository at once.
Six minutes to detection is a good ecosystem outcome. Designing so that six minutes does not matter is a better organisational one.
Sources: GitGuardian: Four More Supply Chain Attacks Hit npm and PyPI · Unit 42: The npm Threat Landscape · Security Boulevard
