Open-source software makes modern development faster, but it also creates an enormous chain of trust. A single JavaScript application may depend on hundreds or even thousands of packages, many maintained by volunteers whom developers will never meet. When attackers compromise one widely used dependency, malicious code can quietly spread into countless projects through what appears to be a routine software update.
Amazon Threat Intelligence has now connected four separate NPM package compromises—axios, debug, chalk and typo-crypto—to the same threat actor linked to the Democratic People's Republic of Korea. Amazon made the attribution with medium confidence after identifying overlapping infrastructure, reused code and similar operational techniques across attacks that occurred between March 2025 and March 2026.
Four Apparently Separate Attacks, One Shared Pattern
The earliest known incident in Amazon's timeline affected the relatively obscure typo-crypto package in March 2025. Six months later, attackers compromised the much more recognisable debug and chalk packages. Axios followed in March 2026.
Axios is particularly significant because it is one of the most commonly used HTTP-client libraries in the JavaScript ecosystem. Amazon estimated that it was receiving more than 100 million weekly downloads when the compromise occurred. An attack involving such a dependency does not need to target companies individually; a malicious update can potentially reach every environment configured to download the latest version automatically.
Amazon says the four incidents shared several fingerprints. These included social engineering against trusted maintainers, malicious updates released under legitimate accounts, the use of installation scripts that automatically execute during package setup and portions of reused code.
Command-and-control infrastructure and other overlapping techniques led Amazon to conclude that the attacks were probably conducted by the same DPRK-linked group. The actor is tracked under several industry names, including SAPPHIRE SLEET, STARDUST CHOLLIMA, BlueNoroff, CageyChameleon and Alluring Pisces. The axios incident had already been publicly associated with this group, but Amazon says the connections to typo-crypto, debug and chalk had not previously been disclosed.
Why Popular Dependencies Are Such Attractive Targets
A software supply-chain attack turns trust into a distribution mechanism.
Instead of breaking into thousands of companies individually, an attacker compromises a package already used by those companies. Developers continue installing it because the package name, maintainer account and update process all appear familiar.
This is especially dangerous when organisations automatically accept dependency updates. A malicious version can enter development machines, automated build systems, cloud environments or production deployments before anyone realises that the maintainer's account or publishing access has been compromised.
Amazon believes the campaign was financially motivated. DPRK-linked groups have frequently been associated with operations intended to generate revenue, steal cryptocurrency or obtain access to financially valuable environments. Popular open-source dependencies offer an efficient way to reach a large number of potential targets through a very small number of initial compromises.
The speed of that downstream exposure can be remarkable. Amazon cited Wiz Research's estimate that approximately one in ten cloud environments was affected by the debug and chalk incident within two hours. That does not necessarily mean every affected environment suffered a complete compromise, but it illustrates how quickly a widely used dependency can propagate across automated systems.
Maintainer Accounts Remain a Critical Weak Point
The incidents were not described as attackers breaking NPM's core infrastructure. Instead, trusted maintainers were reportedly manipulated into giving attackers the access needed to publish new package versions.
That distinction matters because technical controls cannot solve every supply-chain problem. A registry may be operating correctly while still distributing malicious code signed in through a legitimate maintainer account.
Volunteer maintainers are particularly attractive targets. Many support widely used projects in their spare time, often with limited funding, little administrative assistance and no dedicated security team. Attackers can exploit that imbalance through carefully prepared messages, fake collaboration requests or other social-engineering approaches.
Once access is obtained, the attacker needs to behave legitimately only long enough to publish one dangerous release. The trusted package name then does most of the distribution work.
The situation resembles the broader lesson from the XZ Utils backdoor: a patient attacker may spend months building credibility or applying pressure around an understaffed project before using that trust at the moment when it provides the greatest access.
The Smaller Typo-Crypto Incident May Have Been a Trial Run
Amazon discovered the earlier typo-crypto compromise while investigating infrastructure associated with the later axios activity.
The package contained a trojanised file designed to resemble the legitimate and widely recognised core-js package. Amazon observed relatively few downloads and believes the operation may have served as a small-scale test rather than a campaign intended to produce immediate widespread impact.
That possibility makes the incident more concerning, not less. It suggests that the attackers may have spent more than a year refining their package-compromise process before moving on to far more popular dependencies.
The malicious component could download an additional payload and select behaviour appropriate to Windows, macOS or Linux. It also used multiple layers of obfuscation and attempted to maintain persistence after execution.
Amazon Inspector reported the malware to the Open Source Vulnerabilities database, where it is tracked as MAL-2026-3400.
Malicious Behaviour Is Being Split Across Several Packages
Traditional package scanning often evaluates one package at a time. Attackers are increasingly designing campaigns specifically to exploit that limitation.
Amazon Inspector has observed malicious workflows divided across several packages that look harmless when viewed separately. One package may contain encrypted data disguised as configuration, another may provide the code needed to decrypt it and a later package may connect the pieces and execute the resulting payload.
Individually, none of them necessarily contains the full malicious operation. There may be no obviously dangerous installation command, suspicious network request or recognisable payload for a scanner to flag.
The threat only becomes visible when the packages are installed together and allowed to interact within the intended dependency chain.
This represents a major challenge for security tools. Identifying risk now requires analysing relationships and behaviour across an entire dependency graph rather than approving each component in isolation.
Attackers Are Willing to Build Trust Before Using It
Not every malicious package begins with an obviously suspicious first release.
Some attackers publish genuinely useful software, respond to issues, improve documentation and maintain the project for weeks or months. As the package gains users and dependent projects, its reputation grows.
The harmful code may only arrive later, once the attacker has accumulated enough trust and distribution.
A similar strategy can be used against established projects. Rather than creating a new dependency, an attacker may attempt to become a contributor, help an overwhelmed maintainer and gradually obtain publishing rights.
This long-term approach weakens one of the assumptions developers often use when assessing software: that an established package with a convincing history must be safe.
A project's history is useful context, but it cannot guarantee that its current maintainer account, publishing pipeline or external infrastructure remains secure.
A Package Can Change Behaviour Without Publishing a New Version
Another increasingly difficult problem involves packages that depend on remotely controlled resources.
A library may appear safe when reviewed because it retrieves an ordinary configuration file, licence check or support script from an external server. As long as that remote resource remains benign, the package passes inspection.
The attacker can later replace the external content or activate a previously dormant endpoint. Installed copies may then begin behaving maliciously even though no new package version has been released.
This separates the code users reviewed from the behaviour that eventually runs.
It also means a package should not be considered safe merely because its source code looked harmless at one moment. Defenders need to understand what remote resources it depends on, whether those resources are integrity-checked and how much control they have over runtime behaviour.
Encryption Is Making Static Analysis Less Reliable
Older malicious packages sometimes relied on basic concealment techniques such as minification, simple encoding or obviously scrambled JavaScript.
Amazon says newer campaigns are increasingly using stronger encryption and multi-stage loaders. The encrypted content may remain unreadable until the package runs on an intended target and obtains a key from a remote service, licence value or machine-specific information.
An analyst can possess the entire published source code and still be unable to see the final payload through static inspection alone.
The package may initially look like a harmless decryptor or configuration utility. Its true behaviour only becomes visible when it runs under the correct conditions.
This forces defenders to combine code review with controlled execution, network monitoring and behavioural analysis.
Malware Is Learning to Recognise Sandboxes
Automated analysis depends on executing suspicious software inside isolated environments. Attackers know this and increasingly check whether their code is being watched.
According to Amazon, modern payloads may examine system uptime, hostnames, usernames, terminal activity, local file history, operating-system details, cloud metadata and other signs that distinguish a genuine developer machine from an automated sandbox.
If the environment looks artificial, the package may remain inactive or return harmless content.
Some delivery servers also provide different responses depending on the requesting software. An ordinary browser or generic scanner may receive a decoy, while the malware's expected client receives the real payload.
A clean automated verdict may therefore mean only that the sandbox failed to look convincing enough to trigger the attack.
Generative AI Is Removing Traditional Warning Signs
Malicious packages were once easier to notice when they contained awkward language, thin documentation, inconsistent naming or poorly copied code.
Generative AI can remove many of those obvious clues.
Attackers can produce professional documentation, plausible release notes, well-commented code and realistic maintainer profiles. They can also generate many slightly different versions of the same malware, changing names, structure and encryption so that signature-based detection has no stable pattern to match.
The malicious package may look just as polished as a legitimate open-source project.
This does not mean that every professionally documented package is suspicious. It means that presentation quality can no longer be treated as meaningful proof of trustworthiness.
"Slopsquatting" Creates an Entirely New Supply-Chain Risk
Amazon also highlighted a threat known as slopsquatting.
This occurs when an AI coding assistant recommends a package that does not actually exist. An attacker can register that hallucinated package name and wait for developers—or autonomous coding agents—to install it.
Unlike traditional typosquatting, the victim has not mistyped a legitimate package name. They have followed an apparently confident recommendation generated by an AI system.
The risk becomes more serious as development agents gain permission to install dependencies automatically. A mistaken recommendation could move directly from an AI response into a build environment without meaningful human review.
AI Reviewers Could Become Targets Themselves
AI is increasingly being used to examine pull requests, review code and triage suspicious packages. Attackers are likely to adapt by writing content intended not only for human developers, but also for the AI systems reviewing it.
Amazon expects indirect prompt-injection instructions to appear inside source-code comments, README documents, tests and documentation. Such instructions could attempt to persuade an automated reviewer to mark dangerous code as safe, skip a particular file or perform an unintended action during analysis.
This creates two simultaneous payloads. One portion of the package performs the technical attack, while another portion attempts to manipulate the machine responsible for reviewing it.
Organisations introducing AI-based code analysis therefore need to treat repository content as untrusted input. An AI reviewer should not blindly follow instructions contained inside the material it is supposed to inspect.
What Development Teams Should Take from the Findings
The most important defence is reducing automatic trust.
Organisations should know which open-source packages they use, which versions are approved and when a package's maintainer or release behaviour changes. Lockfiles and controlled update processes can prevent a newly published version from entering production simply because it is marked as the latest release.
Maintainer accounts should use strong authentication and narrowly scoped publishing credentials. Release workflows should ideally require multiple trusted approvals, particularly for packages used by large numbers of downstream projects.
Security tools also need to examine installation behaviour, remote dependencies and interactions between packages instead of judging each archive independently.
A software bill of materials can help organisations identify where a compromised dependency is present, but inventory alone is not enough. Teams also need monitoring capable of detecting unexpected network connections, newly introduced installation scripts and unusual activity during builds.
Amazon's Response
Amazon Threat Intelligence worked with Amazon Inspector to track and report the typo-crypto malware through the OSV database. Indicators associated with the campaign were also shared with Amazon GuardDuty so AWS customers could check their environments for related activity.
Amazon says it is updating detection logic, collaborating with package registries and working with the Open Source Security Foundation to improve protection around critical open-source projects.
These measures are useful, but no single cloud provider, registry or scanner can solve the entire problem. Open-source security depends on maintainers, package platforms, software vendors and the organisations that build products from those components.
Final Thoughts
Amazon's investigation suggests that the axios, debug, chalk and typo-crypto compromises were not unrelated incidents. They appear to form part of a longer DPRK-linked campaign that tested its methods on a smaller package before progressing towards dependencies with enormous downstream reach.
The attacks also show how quickly software supply-chain techniques are evolving. Malicious behaviour can be divided across several packages, activated remotely, encrypted until runtime and designed to remain dormant inside analysis environments.
Generative AI adds another complication. It can help attackers build more convincing packages, register dependencies suggested by hallucinating coding assistants and potentially manipulate automated systems responsible for reviewing code.
Open-source software remains essential, and these incidents are not an argument for abandoning it. They are an argument for treating dependency updates as changes to executable code rather than routine administrative tasks.
A familiar package name, a professional README and a trusted maintainer account may all look reassuring. None of them should replace verification—especially when one compromised update can reach thousands of environments before defenders have time to react.
Comments 0