North Korea npm Supply Chain Attack: UK 2026 Audit

What Amazon's research actually found

AWS published research this week attributing four separate npm package compromises — typo-crypto, chalk and debug, and Axios — to the same operation, tracked as Sapphire Sleet and widely regarded as a Lazarus Group offshoot. Amazon's confidence is described as medium, based on shared infrastructure, technical overlaps, and consistent patterns in how targets were selected and approached.

Google had already linked the Axios compromise to this group, which it tracks as UNC1069. Amazon's contribution is to argue the same operation was behind all four incidents, and that the targets grew progressively more ambitious — moving from an obscure package with few downloads towards dependencies used across millions of projects.

The attack path: people, not platforms

None of the four compromises involved exploiting npm's infrastructure or a software zero-day. Instead, the crew allegedly built relationships with maintainers, harvested their credentials, and then published malicious updates through the maintainer's own trusted account — meaning the malicious code arrived via the exact channel developers already rely on for legitimate updates.

This matters for procurement and engineering leads alike: a compromised maintainer account looks identical to a routine release. Standard code-signing or registry-level checks won't flag it, because the publishing identity itself is legitimate. Teams that implement robust vulnerability management strategies need to extend that thinking to publisher and maintainer trust, not just package contents.

Generative AI is lowering the cost of the con

AWS CISO CJ Moses set out why this tactic is becoming more durable rather than less: "Attackers can now produce thousands of lines of coherent, idiomatic, well-commented code, complete with convincing documentation, plausible commit histories, and synthetic maintainer identities, wrapped around a backdoor."

The practical effect is that pattern-matching defences degrade. Because each malicious variant can be mutated, renamed, restructured and re-encrypted, there's no stable signature for detection tooling to lock onto. That pushes the emphasis away from purely technical scanning and towards managed detection & response capable of spotting behavioural anomalies after code is already running.

This is bigger than four packages

Amazon's findings sit inside a much larger pattern. Reporting this April identified more than 1,700 malicious packages across npm, PyPI, Go, Rust and Packagist since January 2025, and earlier 2025 reporting on the related Contagious Interview campaign found 67 malicious npm packages that had already accumulated over 17,000 downloads before removal. A separate June 2025 count put the tally at 35 malicious packages from 24 accounts, with six still live and downloadable at the time of that report.

The UK's own National Cyber Security Centre, in a joint warning with the Republic of Korea, has framed this explicitly as an organisational supply-chain problem rather than an individual-developer issue, noting that DPRK-linked actors are increasingly targeting software supply-chain products worldwide and have used zero-days in third-party software to gain access. Related incidents — including a Mastra AI supply-chain compromise linked to North Korean hackers, and the Phantom Circuit campaign that hit 233 victims across two waves — show the same actors working across multiple software ecosystems, not just JavaScript.

What UK infrastructure teams should do now

The Axios compromise offers a useful lesson on timing: the malicious releases were reportedly live for only around three hours yet still delivered a remote-access trojan, showing how fast CI pipelines and automated dependency resolution can turn a brief compromise window into broad exposure. That argues for treating dependency updates as an event worth logging and reviewing, not a background process.

Concretely, UK buyers should pull an accurate software bill of materials for production systems, cross-reference it against known-compromised package names and maintainer accounts, and check whether historical typosquats or clone packages from earlier waves are still sitting in build caches or lockfiles. This connects directly to broader supply-chain hygiene covered in our further insights into supply chain security, and should feed into how organisations review their IT procurement processes for any software with open-source dependencies baked in.

Longer term, this campaign is a strong argument for adopting a Zero Trust approach to build and deployment pipelines, so that a single compromised publishing account can't automatically propagate into production. Teams should also prepare for effective incident response scenarios specifically modelled on dependency poisoning, since the entry point looks nothing like a conventional breach.