Amazon Just Named the North Korean Group Behind a String of npm Supply-Chain Attacks

If you run production workloads on AWS, and especially if any of it is Node.js, this one is worth ten minutes of your actual attention.

Amazon's own threat intelligence team just published an attribution tying a string of npm supply-chain attacks to a North Korean state-sponsored hacking group. One of the compromised packages has over 100 million weekly downloads. If your build pipeline touches Node.js at all, there is a real chance one of these packages has been in your dependency tree at some point.

This post starts from zero. You do not need a security background, just an interest in what is actually running inside the containers your team ships.

First: what is npm, and why does one package matter to everyone?

npm is the package manager for JavaScript and Node.js. When your code says import debug from "debug" or import axios from "axios", npm is what fetched that code from a public registry and dropped it into your project.

Here is the part that makes this dangerous: modern applications do not just depend on a handful of packages. They depend on hundreds, and each of those packages often depends on more packages underneath it. A single popular package like axios (used for making web requests) or debug (used for logging) can sit quietly inside thousands of other projects, invisible unless you go looking.

That makes popular packages an extremely efficient target. Compromise one package that 100 million downloads touch every week, and you potentially get a foothold in a huge number of unrelated companies' infrastructure at once, without ever attacking any of them directly.

What actually happened

Amazon tracked four separate campaigns, all targeting npm, attributed with medium confidence to a group known by several names depending on which security vendor is tracking it: SAPPHIRE SLEET, STARDUST CHOLLIMA, BlueNoroff, CageyChameleon, and Alluring Pisces. "Medium confidence" is standard threat-intelligence language: it means the evidence, shared techniques and shared command-and-control infrastructure across the campaigns, is credible and consistent, but stops short of the smoking-gun certainty a court case would need.

It is worth understanding why a nation-state would bother with something as unglamorous as a JavaScript logging library. Groups linked to North Korea, most famously the Lazarus Group, have a long, well-documented history of cybercrime used specifically to generate revenue for a government operating under heavy international sanctions, cryptocurrency theft above all. A popular open-source package is not a target for espionage here. It is a distribution channel: one compromise can plant credential-stealing or crypto-draining code inside thousands of unrelated companies at once, which is a far more efficient path to funding than robbing any one of them directly.

• March 2025, typo-crypto. A small campaign, likely a testing ground for the technique.
• September 2025, debug and chalk. Two extremely common packages, compromised in the same event.
• March 2026, axios. The big one. Over 100 million weekly downloads.

The attackers did not brute-force their way in. They used social engineering against trusted maintainers, the real humans who legitimately control these packages, to get access and push malicious updates through completely normal, expected channels. From the outside, an update to a trusted package looked exactly like every other update.

The scale during the debug and chalk incident is the number that should get your attention: Wiz Research reported that roughly 1 in 10 cloud environments were affected within a two-hour window.

How they hid it: split the attack, obfuscate the pieces

The technical evolution here is genuinely worth understanding, because it explains why this kind of attack keeps getting harder to catch with normal review.

Fragment-level attacks. Instead of putting all the malicious logic in one obviously suspicious package, the attackers spread it across multiple packages. Any single one, read in isolation, looks fine. The malicious behavior only exists when the pieces come together.

Multi-layer obfuscation. The payloads combined base64 encoding, XOR ciphers, and AES-GCM encryption. Not simple hiding, layered hiding, the kind that takes real effort to unwind.

Environment-aware execution. The code checked its surroundings before doing anything malicious, specifically to avoid running inside a sandbox or analysis environment where a researcher might catch it in the act.

Patience. Some of these packages stayed genuinely useful and well-behaved for weeks or months before the malicious update landed, building exactly the kind of trust that makes a team stop scrutinizing an update closely.

Put together, this is a supply chain attack designed specifically to survive the kind of casual review most teams actually do, which is to say, not much, because the package "has always been fine."

The part that should worry you most: AI-native attack techniques

This is the detail that makes this story different from a typical supply-chain writeup, and the reason I wanted to cover it here. As the reporting on Amazon's findings put it: generative AI is already changing what malicious software packages look like, and how threat actors are beginning to probe AI-based code systems themselves.

Slopsquatting. AI coding assistants sometimes hallucinate package names that sound completely plausible but do not actually exist. Ask an AI assistant for a helper library and it might confidently suggest npm install some-helper-that-sounds-real, except that package was never real, until an attacker registered it first, deliberately, anticipating exactly that hallucination. A developer trusting their AI assistant's suggestion, and quickly running the install command, can pull down attacker-controlled code that was purpose-built to be recommended by AI tools.

Indirect prompt injection against AI code reviewers. As more teams use AI to help review pull requests and dependency updates, attackers have started hiding instructions inside comments, READMEs, and docstrings, text specifically crafted to manipulate an AI reviewer into approving something it should flag. The malicious content is not aimed at a human reader. It is aimed at the AI sitting between the code and the human.

Amazon's own write-up also flags AI-powered malware mutation: using generative AI to produce novel variants of malicious code that do not share a stable signature, making traditional pattern-based detection harder to rely on. Each variant can be mutated, renamed, and re-encrypted independently, so there is no single signature left to match against. Malware that looks one of a kind in every deployment breaks the pattern-matching approach most detection has relied on for years.

This is also quietly changing the oldest, cheapest defense there is: eyeballing a package before you trust it. AWS CISO CJ Moses put it plainly, quoted in The Register's coverage: 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 broken English, thin documentation, and obvious copy-paste that used to tip off a careful reviewer are gone. Generative AI can fake the whole trust signal, not just the exploit.

None of this replaces the basics. It sits on top of them, making an already hard problem harder specifically for teams that have started trusting AI tools with more of the review process.

Worth knowing too: this was not an isolated event that week. Separate npm incidents were being reported around the same time, including one campaign that published over 600 compromised packages and a malicious package impersonating an OpenAI Codex tool that stole authentication tokens. Different actors, not attributed to this North Korean group, but the same target and the same moment. If it feels like the npm ecosystem is having a genuinely bad stretch right now, that is not just this one story making it feel that way. And the read from security researchers is that this is a preview, not a peak: the same AI-generated evasion techniques used here are expected to show up in future ransomware campaigns too.

Why this matters specifically if you run AWS

If your infrastructure lives on AWS, and especially if it touches e-commerce, checkout flows, or anything customer-facing, a compromised dependency does not stay contained to a build step. It runs with whatever access your build pipeline and runtime environment have, which is often broader than anyone intends.

The good news: AWS has tooling built specifically for this, and if you are already on AWS, you likely have easy access to it.

• Amazon Inspector was the tool Amazon's own team used to investigate this specific campaign, and the findings were reported into the public OSV vulnerability database as a result. That is not the same as Inspector being a real-time npm-malware detector you can passively rely on, but scanning your dependency tree with a tool like Inspector in CI is still the baseline you want in place before the next campaign, not after.
• Amazon GuardDuty shares observed indicators of compromise, so environments that were touched by infrastructure like this get flagged automatically, rather than relying on someone noticing manually.
• The response is not Amazon acting alone. AWS is one of more than a dozen founding members, alongside Anthropic, Google, Microsoft and GitHub, IBM, NVIDIA, OpenAI, Cisco, Red Hat, and others, of a new Linux Foundation-hosted initiative called Akrites, backed by a joint $12.5 million investment, aimed specifically at defending open source against AI-enabled supply chain threats, working alongside the Open Source Security Foundation (OpenSSF) to share findings across the industry.

This is not a hypothetical "someday" risk for an AWS-heavy shop. It is the kind of thing your existing cloud tooling is already positioned to catch, if it is actually turned on and someone is watching it.

Why this is a Kubernetes problem too, not just a build-pipeline problem

Here is the part worth sitting with if your Node.js apps run on Kubernetes, on EKS or anywhere else. A compromised package does not stop mattering once your image is built. If it runs inside a container that Kubernetes schedules, it inherits whatever that pod can reach.

That usually includes more than people expect by default:

• The pod's own service account token, mounted automatically at a well-known path unless you have gone out of your way to disable it. That token is a real Kubernetes credential, and malicious code running inside the container can read it just as easily as your application can.
• The cloud instance metadata service (IMDS), reachable from inside a pod unless it is specifically blocked, which can hand over the underlying node's own cloud credentials. I wrote about exactly this escalation path, from a compromised pod to node credentials to cluster-admin, in the Kubernetes chapter of the Hugging Face incident.
• Whatever secrets and environment variables the deployment manifest injected into that pod, which a postinstall script or a fragment-level payload can read the moment the container starts.

This is the same pattern I keep coming back to on this blog: Trivy's compromise was used specifically to hunt for Kubernetes credentials inside CI/CD. The Hugging Face intrusion turned one compromised pod into cluster-admin using exactly the primitives above. A compromised axios or debug update sitting inside a running pod is the same opportunity, a foothold that is only as dangerous as the access you left reachable from inside the container.

The mitigation is the same one that shows up in nearly every post on this blog: scope what a pod can reach as if you assume one of your containers will eventually be compromised, because sooner or later, through a dependency rather than a bug, one will be. Disable service account token auto-mounting for workloads that do not need the Kubernetes API. Block pod-level access to instance metadata. Keep secrets scoped to exactly the pods that need them, not the whole namespace.

What to actually do

1. Turn on dependency scanning in CI, not just at deploy time. Amazon Inspector or an equivalent should be checking your dependency tree on every build, not occasionally.

2. Treat a sudden update to a long-trusted package with the same scrutiny as a new, unknown one. "This package has always been fine" is precisely the trust these attackers are exploiting.

3. Be specifically skeptical of AI-suggested package names. Before installing something an AI assistant recommended, check that the package actually exists, has a real history, and matches what you expect, rather than trusting the suggestion because it sounded right.

4. Do not let AI code review be your only reviewer for dependency changes. If prompt injection can specifically target the AI reviewer, a human still needs to be in that loop for anything touching your supply chain.

5. Scope what a compromised pod could actually reach. Disable service account token auto-mounting where it is not needed, block pod-level access to instance metadata, and keep secrets scoped tight. If a dependency turns malicious while running in your cluster, this is what limits it to "one pod" instead of "the whole cluster."

6. Know your blast radius in advance. If a build-time dependency were compromised tomorrow, would you know which services it touched, and could you rotate what it had access to, quickly? This is the same "assume breach, build resilience" muscle worth having regardless of which specific package eventually turns out to be the next one.

The whole post in four lines

• Amazon attributed a wave of npm supply-chain attacks, including one inside axios (100M+ weekly downloads), to a North Korean state-sponsored group, using social engineering against trusted maintainers to push malicious updates.
• The attacks used fragment-level obfuscation split across multiple packages, layered encryption, and sandbox-aware code, precisely the kind of thing that survives casual dependency review.
• Two AI-native techniques make this harder going forward: slopsquatting (registering package names AI assistants hallucinate) and indirect prompt injection aimed at AI code reviewers.
• If that code ends up running inside a Kubernetes pod, it inherits whatever the pod can reach, service account tokens, instance metadata, secrets, so scope pod access as if a container will eventually be compromised, because eventually one will be.

The scariest line in the whole report is not about North Korea. It is that roughly 1 in 10 cloud environments were affected by just the debug and chalk compromise within a two-hour window. Your dependency tree is not someone else's problem to watch.

Sources and further reading

• Amazon: Amazon identifies North Korean hacker group behind open-source supply chain attacks. The primary source for everything in this post, Amazon's own threat intelligence write-up.
• OSV Database: MAL-2026-3400. Amazon's tracking entry for the malicious packages identified in this campaign.
• Linux Foundation: Linux Foundation and Industry Leaders Launch Akrites. The official announcement, with the full list of founding members and the $12.5 million investment.
• The Register: Amazon links four poisoned npm packages to one North Korean crew. Source for AWS CISO CJ Moses's quote on generative AI faking trust signals in malicious code.
• TechRadar: Amazon flags North Korean hacker group as being behind the surge in open source supply chain attacks. Source for the Wiz Research attribution on the 1-in-10 environments stat, and for the related, separately attributed incidents happening around the same time.
• OpenSSF: Open Source Security Foundation. The industry body Amazon is collaborating with to share findings across the ecosystem.
• My earlier post on the Trivy supply-chain compromise, a different tool, the same underlying pattern of attacking trusted software to reach production credentials.