Notifications
Clear all
Topic starter
18/08/2026 2:51 pm
TL;DR: Across npm and PyPI, 165 malicious packages were reported in one week, including a PyPI campaign that pushed nearly 85 versions of bingo-ai in 23 minutes and a RAT that hid command traffic behind a free JSON service, according to Xygeni. The pattern shows supply chain abuse is now fast, automated, and designed to evade both human review and static egress controls.
NHIMG editorial — based on content published by Xygeni: a weekly malware digest covering malicious npm and PyPI package activity
By the numbers:
- Xygeni confirmed 165 malicious packages between July 17 and July 24, 2026, across npm and PyPI.
- A single PyPI package, bingo-ai, reached nearly 85 confirmed versions in a 23-minute window on July 21.
- The gcli-control package escalated from version 0.1.0 to full capability in about 13.5 hours.
Questions worth separating out
Q: What breaks when malicious package installs are allowed to execute code by default?
A: Malicious packages can run before review, harvest tokens from the local environment, and create persistence through repositories or automation paths.
Q: Why do package impersonation and dependency confusion still work against mature teams?
A: They succeed because naming, namespace ownership, and registry precedence are still treated as convenience settings instead of security controls.
Q: How do you know if package security controls are actually working?
A: Look for fewer unexpected publishes reaching build systems, lower rates of install-time outbound connections, and measurable reductions in secret exposure during pipeline execution.
Practitioner guidance
- Block rapid-burst package patterns Flag packages that publish many versions in a short window, especially when the pattern includes inflated version numbers or sudden namespace changes.
- Inspect install-time behavior Run package sandboxing or dynamic analysis that watches for file access, credential harvesting, and outbound connections during install, preinstall, and build steps.
- Restrict secret availability in build paths Remove broad cloud, CI, and developer tokens from environments where third-party code executes.
What's in the full report
Xygeni's full post covers the operational detail this analysis intentionally leaves for the source:
- Package-by-package detection notes for the confirmed malicious npm and PyPI campaigns
- The full timeline for the gcli-control RAT and its command-and-control behaviour
- Impersonation cluster details for the Twilio and crypto/DeFi lookalike packages
- Malware validation notes that show how the publication patterns were confirmed
👉 Read Xygeni's weekly malware digest for npm and PyPI supply chain threats →
npm and PyPI package flooding: what DevSecOps teams need now?
Explore further
18/08/2026 3:33 pm
Supply chain malware is now an identity problem, not just a code problem. Once a package runs inside a build or automation workflow, it inherits machine trust and can act on behalf of that environment. That makes secrets, service credentials, and pipeline permissions the real prize. Organisations that still separate software supply chain security from identity governance are missing the operating model attackers are exploiting. Practitioner conclusion: treat package execution as a governed non-human identity event.
A question worth separating out:
Q: Who is accountable when an AI agent or automation system installs a malicious dependency?
A: The accountable team is the one that granted autonomous execution without a policy boundary. If a bot or AI agent can install third-party code, the organisation has created a delegated trust chain and should govern it like any other privileged non-human identity. Accountability sits with platform owners, security governance, and the workflow owner together.
👉 Read our full editorial: Malicious package publishing is accelerating across npm and PyPI
