Notifications
Clear all
Topic starter
02/08/2026 11:44 am
TL;DR: A wave of malicious npm and PyPI packages shows how quickly compromised maintainers, look-alike domains, and postinstall or import-time execution can turn normal dependency installs into credential-harvesting incidents, according to Semgrep. The operational lesson is that exposure analysis, token rotation, and lockfile discipline matter more than reacting to package names alone.
NHIMG editorial — based on content published by Semgrep: LLMjacking: How Attackers Hijack AI Using Compromised NHIs
By the numbers:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging (37%) and over-privileged accounts (37%).
Questions worth separating out
Q: What breaks when a malicious package runs during dependency installation?
A: The main failure is that installation becomes code execution inside a trusted environment.
Q: Why do malicious packages create an identity problem as well as a code problem?
A: Because the attacker is not only shipping code, they are trying to consume identities that already exist in the environment.
Q: How do teams know whether a malicious package actually affected them?
A: They need a full exposure determination across repositories, CI runs, and build artefacts, not a guess based on package name alone.
Practitioner guidance
- Run exposure search across all repos and build paths Query dependency graphs for every suspicious package name and version range across active projects, archived branches, and CI artefacts before deciding the blast radius.
- Rotate any secrets present in the execution environment Assume the package could have read cloud keys, publish tokens, SSH material, and registry credentials from developer or CI hosts.
- Pin builds to exact versions and deterministic installs Use package-lock with npm ci for Node and exact pins for Python so a clean rebuild cannot silently drift back to a known malicious dependency.
What's in the full article
Semgrep's full post covers the operational detail this post intentionally leaves for the source:
- Dependency search examples for pinpointing affected repos and packages across active projects
- Advisories dashboard workflow for validating whether your organisation matched any recent detections
- Step-by-step secret rotation guidance for tokens, cloud keys, SSH material, and registry credentials
- Lockfile and exact-pin recovery steps for Node and Python rebuilds after cleanup
👉 Read Semgrep's analysis of malicious npm and PyPI packages affecting supply chains →
Malicious dependency alerts: what should supply chain teams do next?
Explore further
02/08/2026 12:55 pm
Malicious package incidents are identity incidents once install-time code can reach secrets. The package itself is only the delivery mechanism. The real control failure is that build and developer environments still contain long-lived secrets that can be read at execution time. That makes this a Non-Human Identity governance issue as much as a supply chain issue, because service tokens, cloud keys, and publish credentials are the assets being abused.
A question worth separating out:
Q: What should teams do after a malicious dependency is discovered?
A: Contain the affected endpoints, revoke any credentials that were reachable from those systems, and rebuild trust from known-clean environments. Then review where secrets are stored, not just which package was compromised. If the same workstation holds cloud, SSH, and SaaS credentials, the incident response plan must cover all three identity domains.
👉 Read our full editorial: Malicious open-source packages expose the limits of SCA-only response
