Notifications
Clear all
Topic starter
21/08/2026 4:51 pm
TL;DR: In 2025, 3,180 confirmed malicious packages were reported, with the heaviest activity in October, November, and December and a clear shift toward automated multi-version publishing, enterprise tool impersonation, and CI/CD-targeted supply-chain abuse, according to Xygeni. The pattern shows that registry trust, version history, and basic scanning are no longer enough to contain package-led compromise.
NHIMG editorial — based on content published by Xygeni: The State of Malware in Open Source Ecosystems for 2025
By the numbers:
- Xygeni confirmed 3,180 malicious packages across 2025, showing sustained growth in open-source malware activity.
- The report says 156% one-year growth in malicious open-source packages left teams exposed to faster and more industrialised abuse.
Questions worth separating out
Q: What breaks when malicious packages reach build pipelines unchecked?
A: Unchecked packages can execute before conventional controls inspect them, which means secrets, environment variables, and internal tokens can be exposed during install or runtime.
Q: Why do malicious packages in developer workflows create such high risk?
A: Because developer and automation environments often hold long-lived credentials, deployment access, and internal package trust that attackers can reuse.
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
- Enforce lockfile-only installs Use npm ci or pip install --require-hashes in CI/CD so the build consumes only the exact dependency tree already approved in version control.
- Block installs on behavioural risk signals Fail builds when packages show suspicious postinstall scripts, obfuscation, rapid version pumping, or maintainer anomalies that indicate active abuse.
- Harden build runners against secret theft Run builds in hardened containers with minimal secrets exposed, and move registry credentials into secrets managers instead of environment variables.
What's in the full report
Xygeni's full report covers the operational detail this post intentionally leaves for the source:
- Confirmed malicious package families and the published detection patterns behind each cluster.
- Behaviour-based indicators used to distinguish obfuscated loaders from benign package activity.
- Build-blocking examples for CI/CD pipelines when malicious code is detected.
- Weekly and monthly incident tracking that security teams can use for monitoring and reporting.
👉 Read Xygeni’s full 2025 recap of malicious package activity across npm and PyPI →
Malicious packages in 2025: what security teams need to act on?
Explore further
21/08/2026 5:09 pm
Package ecosystems now behave like identity-adjacent infrastructure. Malicious package campaigns are no longer just code quality issues. They sit at the intersection of software supply chain control, secrets governance, and non-human identity exposure because build systems, tokens, and deploy automation are often the first assets touched. Practitioners should treat package trust as part of identity lifecycle governance, not as a separate hygiene task.
A question worth separating out:
Q: Who is accountable when a malicious package reaches production systems?
A: Accountability usually sits across security, engineering, and platform operations. Engineering controls the dependency choices, security defines the detection and response requirements, and platform teams govern build pipelines and package trust policies. Frameworks such as NIST CSF, NIST 800-53, and MITRE ATT&CK support shared ownership of prevention, detection, and response.
👉 Read our full editorial: Open-source malware in 2025 shows supply-chain abuse at industrial scale
