Amazon says it has linked multiple high-profile NPM supply-chain attacks targeting the Node Package Manager (npm) ecosystem to a North Korean threat actor. In its findings, the company connects compromises of several widely used open-source libraries—spanning the typo-crypto, debug, chalk, and axios packages—to a campaign attributed to Sapphire Sleet (also known as BlueNoroff and Stardust Chollima).
The cases, according to Amazon, did not happen all at once. Instead, the activity appears to have unfolded in stages across 2025 and 2026, escalating from an initial trojanized package to broader attacks involving popular libraries that sit directly in the dependency chains of countless applications.
What Amazon linked in the npm ecosystem
Amazon’s core point is that several separate npm incidents share enough overlap to point toward the same threat actor behind the larger campaign. The company links these compromises through shared tactics, techniques, and procedures (TTPs), similarities in command-and-control infrastructure, and other operational signals observed across the activity.
Instead of focusing on a single event, Amazon frames the incidents as part of a connected effort that leveraged public package distribution mechanisms. That matters because npm packages are routinely installed automatically as part of development and deployment workflows.
Timeline: from trojanized testing to major package takeovers
March 2025: typo-crypto trojanization
Amazon reports that the activity began in March 2025, when the attacker trojanized the typo-crypto package. In Amazon’s view, this early compromise likely functioned as a testing ground—an initial step to validate the approach before moving into higher-impact targets.
September 2025: debug and chalk compromises
In September 2025, the campaign expanded. Amazon says the attacker compromised debug and chalk, which are widely used libraries. The company estimates that the impact reached roughly 10% of cloud environments within about two hours of the malicious activity emerging.
This rapid spread highlights a key weakness in dependency-based ecosystems: once a compromised package update is published, downstream systems can fetch it quickly—often with little friction and limited visibility.
March 2026: targeting axios at massive scale
Then, in March 2026, the attacker targeted axios, one of npm’s most popular libraries. Amazon notes that axios receives more than 100 million weekly downloads.
Importantly, Amazon also acknowledges that the axios incident has already been publicly attributed to actors linked to DPRK. What Amazon adds is the connection between axios and the earlier package compromises, suggesting a broader campaign rather than isolated incidents.
How the attackers pushed malicious updates
Amazon says the attackers gained access through social engineering of npm package maintainers. After gaining the ability to publish or influence package content, the threat actor released malicious updates that then propagated automatically to users who installed dependencies.
This approach leverages normal developer workflows. When teams pull updates from npm repositories—sometimes as part of CI/CD processes—malicious changes can enter production without a human explicitly approving the specific update content.
Confidence level and why attribution is tricky
Amazon states that the linkage to Sapphire Sleet is made with medium confidence. The basis for that confidence includes alignment across observed TTPs, command-and-control infrastructure, and operational similarities.
That “medium confidence” framing is significant. In real investigations, attackers can reuse patterns that appear in multiple campaigns, and overlaps can be caused by common tools or industry-wide behaviors. Amazon’s assessment suggests enough consistency to connect the dots, but not so much that it reaches high confidence.
Why target popular npm packages
Amazon also suggests the attackers had financial motivations. Rather than compromising a narrow set of systems directly, targeting popular libraries creates indirect access to a large “downstream” population all at once.
In other words, a malicious change inside a widely depended-on package can act like a force multiplier. It scales impact with each project that updates dependencies—even if the attacker has no direct relationship with those organizations.
Trends Amazon says are showing up in recent supply-chain attacks
Beyond the specific linked incidents, Amazon highlights several patterns that show up repeatedly in supply-chain threats. These trends explain why such attacks are hard to detect using traditional controls.
- Malicious functionality split across multiple packages: Attackers distribute harmful components through several seemingly benign libraries, complicating analysis and correlation.
- Long-term trust building: Threat actors may spend months maintaining legitimate projects or becoming contributors before introducing malicious code, reducing suspicion.
- Behavior decoupled from package contents: Instead of placing all malicious logic directly inside the package, attackers may rely on external scripts, configuration files, or later-deployable servers.
- More advanced payload delivery: Amazon reports stronger encryption and multi-stage payloads, sometimes using runtime or remotely fetched keys that make static inspection harder.
- Environment-aware execution: Malware can delay actions until it detects real developer or production environments, helping it evade sandbox-based analysis.
- Exploiting “slopsquatting”: Attackers register package names that are “hallucinated” by AI coding assistants, hoping developers or autonomous agents will install them.
Amazon also notes that AI can enhance and simplify these efforts. For example, attackers can generate code, documentation, and maintainer identities more quickly, supporting the trust-building phase and speeding up the creation of convincing malicious packages.
What organizations can do in response
Amazon highlights a multi-pronged response approach, including reporting findings and intelligence to the broader community and collaborating with partners such as OpenSSF.
The company also points to investments—specifically $12.5M in the Akrites initiative—aimed at protecting critical open-source software from AI-enabled attacks.
For security teams and engineering orgs, the practical takeaway is that defenses need to cover the entire dependency and deployment pipeline, not just the initial package download.
Test detection at every layer
Amazon’s report is also a reminder that real-world defenses often miss what they can’t see. Security teams, according to a referenced whitepaper, log successful attacks at a rate of 54% but alert on only 14%. The remaining activity can move through environments without triggering alerts.
The implication is straightforward: if detection relies on SIEM or EDR rules that were never exercised against realistic scenarios, supply-chain threats can slip by. Regular breach and attack simulation testing helps teams validate that their monitoring, detection logic, and response workflows actually stop suspicious dependency activity before it becomes a full compromise.
Conclusion
Amazon’s linkage of multiple NPM supply-chain attacks to North Korean hackers connects several major library compromises across 2025 and 2026. By tying together incidents involving typo-crypto, debug, chalk, and axios—and explaining how malicious updates can spread automatically after social engineering—Amazon underscores both the scale of the risk and the difficulty of attribution.
Equally important, the report outlines the evolving tactics behind these threats, from splitting malicious behavior across packages to using AI-supported trust-building and environment-aware payloads. For defenders, the next step is to ensure security controls are tested across the full chain of dependency management, detection, and incident response—so attackers don’t get the advantage of stealth.
