Because repeated publishing gives attackers more chances to evade review, reappear under nearby versions, and reach different consumers before one package is removed. The risk is not only the payload, but the campaign structure itself. Teams need controls that watch publication behaviour over time, not just package contents at a single point.
Why multi-day campaigns are riskier than one-off malicious releases
A one-time bad package is dangerous, but a campaign that runs for days or weeks is harder to contain because it can iterate. Each publish gives the attacker another chance to slip past review, vary the payload, target a different downstream consumer, or restore reach after a takedown. That means defenders have to think in terms of campaign telemetry and timeline, not just the contents of the package at a single point in time.
For practitioners, the important distinction is that the attacker is not trying to win with one artifact alone. They are using publication cadence, version churn, and registry visibility as part of the attack path. The longer the campaign persists, the more likely it is that at least one release lands before the defensive response catches up.
What repeated publishing changes in practice
Repeated publishing expands the attack surface in ways a single release does not. A campaign can test which package names, versions, metadata patterns, or dependencies survive review, then adjust quickly. It can also exploit the fact that different consumers update at different speeds, so even if one version is removed, another nearby version may still be installed by users who have already pulled it or who refresh on a different schedule.
This is why campaign structure matters as much as payload quality. The attacker can split risk across multiple releases, which reduces the chance that any one detection event ends the operation. In the open source ecosystem, that often means looking for clusters of related package names, near-duplicate releases, and unusual version timing rather than treating each upload as an isolated event.
- Watch for bursts of new versions from the same publisher or namespace.
- Correlate package publication timing with new dependency adoption or installation spikes.
- Flag releases that appear to be replacements, rebrands, or near-duplicates of earlier suspicious packages.
How campaigns evade cleanup and reach more victims
Campaigns are effective because removal is not the same as containment. Once a malicious release has been published, it may already be mirrored in caches, locked into build pipelines, or installed in environments that do not immediately refresh. A new release can also ride the attention created by the first takedown, because defenders often focus on the specific artifact they just removed and miss the follow-on version that carries the same objective under slightly different packaging.
LiteLLM PyPI package breach is a useful example of why package-level harm can extend beyond a single release, because the impact includes the publication pattern and the resulting exposure path. Campaigns are also easier to scale across consumers: one publisher action can affect many environments, but each consumer may notice at a different time, which creates uneven exposure windows.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while SLSA, NIST CSF 2.0, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Build provenance and supply chain integrity | Multi-day package campaigns depend on repeated artifact publication and trust in build provenance. |
| Recommendation — Require provenance checks for every release and reject unverified rebuilds or republished artifacts. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and recorded | Repeated package releases create evolving exposure that must be tracked over time. |
| Recommendation — Track package exposure as a changing risk, not a one-time review outcome. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | Package campaigns are a software supply chain issue requiring continuous intake and review controls. |
| Recommendation — Continuously validate third-party packages and alert on suspicious release patterns. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Supply-chain-aware architecture must account for repeated malicious releases and downstream consumers. |
| Recommendation — Design dependency intake to detect and quarantine repeated malicious releases. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The question is about malicious package release campaigns used to reach victims through trusted distribution. |
| Recommendation — Map package campaign activity to supply-chain compromise detections and hunting rules. | ||
Practitioner Guidance
What to prioritise: Build detection around publisher behaviour over time, not just file hashes or package contents. The most useful signals are version cadence, namespace reuse, abnormal release timing, and repeat appearance after removal.
What to verify: Confirm whether your build and intake systems treat a package as trusted only once, or whether they re-evaluate newly published versions, maintain provenance checks, and block suspicious publishers across the full campaign window.
Decision rule: If a package has already shown malicious behaviour once, treat nearby versions, republished variants, and same-namespace follow-ons as high risk until you have evidence that the publisher and delivery path are clean.
Practitioner takeaway: The defensive unit of analysis is the campaign, not the single bad artifact, because attacker success often comes from persistence, repetition, and timing rather than from a single perfect payload.
Related resources from NHI Mgmt Group
- Why do self-propagating package compromises create more risk than a single malicious release?
- Why do coordinated fake package campaigns create more risk for software supply chains than a single malicious package?
- How should teams reduce risk from malicious npm package installs?
- Why do package mirror abuse campaigns create more risk than simple malicious packages?