Amazon links debug and chalk npm hijack to North Korea

On 30 July 2026, new attribution analysis revisited the September 2025 compromise of the popular debug and chalk npm packages. Amazon Threat Intelligence assessed with medium confidence that this incident, the March 2026 axios compromise and an earlier typo-crypto package were conducted by the same North Korea-linked actor.

This is not a newly discovered debug or chalk compromise. The actor assessment and campaign context changed. Technical response to the historic malicious versions remains determined by each incident’s execution mechanism, not the threat-group name.

What Amazon actually assessed

In an AWS Security Blog post published on 29 July, Amazon connected:

• typo-crypto from March 2025;
• the September 2025 debug and chalk hijack;
• the March 2026 axios compromise.

Amazon cited shared tactics, techniques and procedures, trojanised packages, post-install scripts in some campaigns, code reuse and overlapping command-and-control indicators. It assessed with medium confidence that the activity belongs to an actor tracked as Sapphire Sleet, Stardust Chollima, BlueNoroff, CageyChameleon and Alluring Pisces.

Those vendor names do not always represent perfectly identical activity sets. “A DPRK-linked actor across overlapping clusters” is the more precise formulation.

Independent analysis published on 30 July noted that Amazon disclosed limited supporting detail. Its post names classes of similarity without mapping each indicator to every incident. Attribution remains a medium-confidence intelligence assessment rather than mathematical proof.

What happened to debug and chalk

In September 2025, an attacker phished a maintainer through a lookalike npm domain and introduced malicious code into at least 18 packages. Their combined popularity exceeded two billion weekly downloads, but a download count is not a count of infected endpoints or harmed organisations.

The payload operated in browser code. It hooked fetch, XMLHttpRequest and cryptocurrency-wallet APIs to replace transaction addresses before signing. It did not create conventional host persistence.

That mechanism has two important consequences:

1. malicious behaviour did not depend on postinstall;
2. code could enter a frontend bundle and execute for end users long after the application build.

Blocking install scripts was insufficient. Responders needed to remove affected versions from lockfiles, caches, CDNs, web artifacts, images and deployed applications.

axios used a different mechanism

The March 2026 axios compromise used an npm lifecycle script and installed the WAVESHAPER.V2 backdoor. Google attributed that incident to UNC1069, while Microsoft used Sapphire Sleet and described overlap with other actor names.

That is meaningful support for the axios attribution but not automatic proof for debug and chalk. Execution differed:

• axios — installation-time code;
• debug/chalk — bundled browser code active during application use;
• typo-crypto — a function waiting for a specific trigger.

One operator can use different techniques, but detection and response scope must still match each case.

typo-crypto as a possible test run

Amazon found a trojanised core.js inside typo-crypto, published in March 2025. The package name, description and keywords impersonated the popular crypto-js, while the file name suggested another legitimate project, core-js.

The malicious path waited for a hash input beginning 0098273, then retrieved an operating-system-specific second stage for Windows, macOS or Linux. It used Base64 and XOR with the key 01042025.

Amazon published:

• npmjs[.]store;
• 216[.]74[.]123[.]126;
• OSV record MAL-2026-3400;
• the package and core.js.

Amazon interprets low download volume as a likely testing ground before larger campaigns. That is an assessment, not a confirmed operator statement.

An inconsistency in the initial-access narrative

Amazon describes a shared playbook: social-engineer a trusted maintainer, then publish a malicious update. Registry data discussed on 30 July shows only one typo-crypto version—4.3.0—published as the package’s first release. The publisher account did not match the author in metadata.

That record resembles a package created to impersonate a legitimate project from its first publish rather than an update to a previously clean package. Registry history cannot establish how the account was obtained, but it does not show an earlier benign version.

This does not disprove the broader attribution. It means “every incident began the same way” is wider than the public evidence supports.

Indicator hash discrepancies

The 30 July review also identified differences between hashes in Amazon’s post and the tarball served by npm. A value described as the package hash may have represented a file, while the stated core.js hash was not found in the retrieved artifact.

Possible explanations include a labelling error, a different sample copy or an artifact change. Until clarified, one hash should not be the sole closure criterion.

Validation should combine:

• package name and exact version;
• lockfile integrity;
• tarball contents;
• core.js logic;
• trigger and key values;
• network indicators;
• process or application behaviour.

Available in the registry does not mean executed

As checked on 30 July, [email protected] remained available. It declared no install script, so downloading it alone did not execute the described path.

Preserve the distinction:

• presence in cache or lockfile establishes the artifact;
• loading the package creates an execution opportunity;
• trigger satisfaction starts the malicious path;
• network and process evidence can confirm later stages.

Do not dismiss the package because the trigger appears specific, but do not claim every installation was compromised.

What npm 12 changes

npm 12, released on 8 July, disables dependency lifecycle scripts by default. This is valuable against postinstall chains such as the axios variant.

It does not prevent:

• import-time execution;
• malicious browser bundles;
• maintainer account takeover;
• runtime retrieval from an external resource;
• input-triggered malicious logic;
• projects that explicitly enable scripts.

On 28 July, npm began scanning newly published packages for malware before making them installable. The control applies to new publishes, is not retroactive proof for the entire registry and may struggle with behaviour split across several innocuous-looking packages.

Emerging package attack patterns

Amazon describes patterns that belong in modern threat models:

• fragmentation — a blob, decryptor and downloader live in separate packages;
• long trust-building — useful releases precede the attack;
• behaviour decoupling — remote resources control an apparently clean package;
• runtime cryptography — keys come from context or a server;
• sandbox avoidance — execution depends on real-environment signals.

Scanning one tarball cannot reveal behaviour that emerges only across a dependency graph and active runtime.

How to assess an environment

Search:

• package-lock.json, yarn.lock and pnpm-lock.yaml;
• SBOMs for historical releases;
• npm caches and corporate proxies;
• frontend artifacts and source maps;
• container images;
• static CDN assets;
• CI logs and maintainer tokens;
• IOC traffic and unusual wallet hooks.

For debug and chalk, backend-container review alone may miss a payload bundled into JavaScript delivered to users. Establish which bundle versions were live and for how long.

Response plan

1. identify exact malicious versions from authoritative advisories;
2. stop promotion of dependent builds;
3. remove artifacts from proxies, caches, CDNs and images;
4. rebuild from a clean lockfile and verified sources;
5. review npm, Git and CI publication credentials;
6. validate frontend and application integrity;
7. analyse transactions and telemetry if the application handled wallets;
8. preserve evidence and distinguish download from execution;
9. monitor identities and infrastructure after rebuilding.

Maintainer compromise also requires publication hardening: phishing-resistant MFA, short-lived tokens, trusted publishing, two-person review for critical releases and alerts on ownership changes.

Attribution must not drive containment

DPRK context helps connect campaigns, anticipate financial motivation and enrich indicators. It does not change the first actions: remove malicious versions, establish execution, rotate reachable credentials and verify artifacts.

Record:

• fact — a specific version contained specific code;
• observation — infrastructure or code overlaps;
• assessment — Amazon attributes with medium confidence;
• uncertainty — public material does not map every piece of evidence to every incident.

Our Cyber Threat Intelligence lifecycle explains how to preserve those levels.

Proving that the replacement build is clean

A rebuild provides little assurance if it reuses the same cache, proxy or base image. Start from an approved lockfile, an empty cache and a registry or proxy that stores the exact reviewed artifacts. After installation, compare the dependency graph, tarball hashes, SBOM and final bundle contents with the expected state.

For a front-end application, absence from node_modules is not enough. Confirm that old JavaScript has been removed from the CDN, service workers, container images and browser caches. If the code could run in a wallet context, separately examine transactions and user approvals from the exposure window.

Retain provenance attestation for the release: commit, workflow identity, dependency set, artifact digest and build environment. This does not prevent maintainer compromise, but it makes it much faster to determine where a malicious release actually landed. The closure criterion is “no malicious code in any active artifact,” not merely “npm install now selects a safe version.”

Sources versus Breachroad conclusions

Amazon confirms its DPRK assessment, related packages, MAL-2026-3400, typo-crypto behaviour and package-attack trends. Aikido and Wiz previously documented debug and chalk, while Google and Microsoft attributed axios. Registry and hash discrepancies come from the independent 30 July review.

Our bundle scoping, confidence-level and response-order recommendations are Breachroad conclusions. The software supply-chain attack guide and our TeamPCP dependency analysis provide further technical context.

Cybersecurity training for development teams helps people recognise maintainer compromise and escalate it safely. An IT security audit can cover CI/CD, package proxies, SBOM, secrets and release governance.