Notifications
Clear all
Topic starter
19/08/2026 3:48 pm
TL;DR: A single npm operator published five trojanized packages across two rounds in three days, then relaunched the campaign 74 minutes after takedown using the same command-and-control infrastructure, according to Xygeni. Import-time execution bypasses install-hook scanning and shifts supply-chain defense toward dependency review, runtime egress control, and network-based detection.
NHIMG editorial — based on content published by Xygeni: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- The gap between removal and relaunch was 74 minutes.
- Round one was unpublished on 2026-07-05 at 14:14 UTC.
Questions worth separating out
Q: What breaks when npm security controls only scan install scripts?
A: They miss malicious code that runs at import time inside normal module initialisation.
Q: Why do transitive dependencies create more software supply chain risk than direct packages alone?
A: Transitive dependencies hide exposure inside nested libraries that are often missed by top-level package reviews.
Q: How should security teams detect rebranded malicious packages?
A: They should look for infrastructure reuse, payload behaviour, and transitive import patterns instead of relying on package names alone.
Practitioner guidance
- Scan for import-time execution paths Review dependency source for module-level exec, fetch, eval, or dynamic loading patterns in both ESM and CommonJS entry points.
- Block reuse of campaign infrastructure Add DNS, proxy, and egress detections for tracker.bvgroup.co, remote.agyn.org, and related operator domains, then hunt for those indicators in historical logs.
- Trace transitive import chains Map packages that act only as carriers for other utilities, especially where a small wrapper imports another obscure dependency at load time.
What's in the full analysis
Xygeni's full analysis covers the operational detail this post intentionally leaves for the source:
- Source code excerpts showing exactly how the import-time payload is embedded in both ESM and CommonJS entry points
- A round-by-round timeline of the neon-* and agn-* packages, including publication, takedown, and relaunch timing
- Indicators of compromise for proxy, DNS, and endpoint hunting, including the reused command-and-control infrastructure
- Package-level behavioural clues that help distinguish a harmless utility from a carrier package with hidden execution paths
👉 Read Xygeni's analysis of the npm import-time malware campaign →
Import-time npm malware: what practitioners need to act on now?
Explore further
19/08/2026 4:24 pm
Import-time malware is the next control gap in dependency security: install-hook scanning was built for preinstall and postinstall abuse, but this campaign executes at module load. That shifts the defensive problem from package metadata to code-path inspection and runtime control. Teams that still equate dependency hygiene with hook scanning are protecting the wrong boundary. Practitioners should treat import-time execution as a first-class supply-chain threat.
A question worth separating out:
Q: Who should be accountable when compromised npm packages spread through CI and developer systems?
A: Accountability should sit with the teams that own workflow identity, dependency governance, and secret management together, because the failure spans all three. Security, platform engineering, and application owners need a shared response model for package poisoning, credential rotation, and publishing control. That shared ownership is what prevents a supply-chain issue from becoming an open-ended identity incident.
👉 Read our full editorial: Import-time npm supply chain malware is bypassing install-hook defenses
