They persist because attackers treat package repositories as an automation problem, not a one-off compromise. If one package is removed, scripts can generate a new account, upload a replacement, and update references elsewhere. That makes the defender’s workload reactive and manual while the attacker’s workflow scales. The imbalance grows when moderation depends on finite human bandwidth.
Why package campaigns rebound so fast
Open-source ecosystems make scale the attacker’s ally. A campaign against one package name, maintainer account, or namespace is easy to replace because the attacker is not trying to keep a single foothold alive, they are trying to keep the workflow alive. That means removal, takedown, or reputation scoring often clears only the current instance, not the underlying automation loop.
The pattern is reinforced by ecosystem structure: package publishing is cheap, identity creation is often low friction, and distribution paths are fragmented across registries, mirrors, bots, and downstream references. Once a malicious release is detected, the attacker can iterate faster than human review queues can absorb new submissions. The same operational logic shows up in repeated package incidents such as PyPI Breach, Shai Hulud npm malware campaign, and LiteLLM PyPI package breach, where the value came from repeatable abuse of the publishing pipeline, not from a single payload.
What makes the defender’s job asymmetric
Defenders usually have to confirm harm, verify provenance, coordinate removals, notify downstream users, and then watch for reuploads or lookalike packages. Attackers only need one successful path through publishing, dependency confusion, typo-squatting, token theft, or account takeover to keep the campaign moving. That creates a structural mismatch: the defender is responsible for certainty, while the attacker is rewarded for volume and speed.
The operational weak point is not just malware detection, but lifecycle control over the objects that make publishing possible. If maintainers, tokens, build systems, and release channels are easy to recreate or reuse, the campaign survives individual takedowns. This is why package abuse so often overlaps with exposed secrets, as seen in Nx Package Attack, 2,300+ Credentials Leaked and GitHub Dependabot Breach, where the publishing channel and the credentials behind it became part of the attack surface.
What to harden if you want fewer repeat campaigns
Reducing resurfacing requires shrinking the attacker’s replacement capacity, not just the current malware sample. Registries and maintainers need stronger verification, faster token revocation, tighter release controls, and better visibility into who can publish what and from where. Security teams should also assume that campaign recurrence is normal unless package identity, build provenance, and secret handling are continuously enforced.
What to verify: Confirm that package publishing credentials are short-lived, revocable, and monitored, and that compromised accounts cannot immediately recreate the same trust path under a new name. If takedowns do not materially slow the next publication attempt, the control set is too reactive.
What practitioners underestimate: The challenge is not just malicious code removal, it is reducing the attacker’s ability to industrialise reentry. Without friction in account creation, release approval, and secret abuse, every cleanup becomes a temporary pause.
Practitioner takeaway: Treat recurring malicious packages as a supply chain persistence problem, not a content moderation problem, because the most important control is the one that makes the next upload slower, harder, and easier to attribute.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 5 — Account Management | Package campaigns often reenter through new or abused publishing accounts. |
| CIS 6 — Access Control Management | Stopping repeat uploads depends on limiting who can publish and where. | |
| CIS 8 — Audit Log Management | Rapid resurfacing requires visibility into repeated publish attempts and takedown evasion. | |
| Recommendation — Restrict and revoke publishing access quickly for compromised package accounts. Enforce least-privilege publishing rights for package release workflows. Log package publication and token-use events for rapid abuse detection. | ||
| NIST CSF 2.0 | PR.AA — Identity Management, Authentication, and Access Control | Resurfacing is driven by weak publisher identity and access enforcement. |
| DE.CM — Continuous Monitoring | Campaigns recur quickly when new uploads are not continuously watched. | |
| RS.MI — Mitigation | Takedown speed alone is insufficient unless the next publication path is interrupted. | |
| Recommendation — Harden publisher authentication and access paths for package release systems. Monitor registry and repository activity for rapid reupload patterns. Interrupt the attacker’s reupload workflow as part of containment. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The question is about repeated abuse of the software supply chain. |
| T1585 — Establish Accounts | Campaigns resurface by creating replacement accounts or identities. | |
| T1552 — Unsecured Credentials | Many package campaigns rely on stolen tokens and leaked secrets. | |
| Recommendation — Map repeated package abuse to supply-chain compromise and hunt upstream abuse paths. Detect account creation and onboarding patterns used to restart malicious publishing. Hunt for leaked publishing tokens and remove exposed credentials quickly. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | Malicious package campaigns often depend on exposed developer and publishing secrets. |
| Recommendation — Reduce secret exposure in package pipelines and revoke compromised credentials fast. | ||
Related resources from NHI Mgmt Group
- Why do package-lock discipline and dependency pinning matter when attackers target open-source ecosystems?
- How should DevSecOps teams respond when a malicious open source package is republished under new versions to evade detection?
- Why do standing publish privileges increase risk for package maintainers in open-source ecosystems?
- Who should own response when malicious packages are discovered in open-source ecosystems?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
