Release storms in trusted npm type packages expose supply chain gaps

At a glance

What this is: StepSecurity found a release storm in well-known npm @types packages, where a scheduled publishing workflow kept emitting identical deprecated versions instead of stopping after the first notice.

Why it matters: For IAM, NHI, and software supply chain teams, this shows that automation control failures can create trust noise that weakens monitoring, release governance, and downstream confidence in package provenance.

Context

A release storm is a repeated publishing pattern where the same package version or near-identical package state is emitted over and over by automation. In this case, the issue sat inside a trusted npm publishing workflow rather than an attacker-controlled package, which makes the governance lesson sharper: trusted automation still needs explicit stop conditions, inventory checks, and monitoring for abnormal repetition.

The identity angle is indirect but real. The workflow was acting on behalf of a managed publishing identity inside GitHub Actions, so the failure was not only in software release logic but in how automated trust was delegated to a machine process. When package governance depends on scheduled automation, the control boundary shifts to the identity and lifecycle of that automation itself.

Key questions

Q: What breaks when a package publishing workflow lacks idempotency?

A: The workflow can repeat the same release action every time it runs, even when the package state has not changed. That creates noisy version churn, weakens trust in release telemetry, and can obscure real supply chain abuse because analysts stop treating repetition as unusual.

Q: Why do repeated package releases matter even when they are benign?

A: Repeated releases matter because they distort the provenance trail and train monitoring systems to ignore abnormal behaviour. In dependency ecosystems, trust depends on predictable publishing patterns, so even a harmless loop can reduce confidence in the controls that protect downstream consumers.

Q: What are the signs that automated package publishing is misconfigured?

A: Common signs include identical release content, version bumps with no code changes, repeated deprecation notices, and publish events appearing on a fixed schedule without state change. Those signals usually mean the workflow is missing a reliable stop condition or skip check.

Q: How should teams govern CI/CD publishing identities for open source packages?

A: Teams should treat publishing workflows as privileged machine identities with scoped authority, explicit approval paths, and lifecycle ownership. The key control question is who or what is allowed to publish, under what state conditions, and how the workflow proves it should stop.

Technical breakdown

How a scheduled publishing workflow creates repeated releases

The workflow in question ran on a fixed schedule and evaluated a package list before publishing deprecated @types stubs. In a healthy design, the first publish marks the package as no longer needed and subsequent runs should short-circuit. Here, the control failure was logical, not infrastructural: the workflow kept reaching the publish path because its state check did not resolve as intended. That means the release system lacked a reliable idempotency barrier, so every scheduled execution could create another release event even when no package content had changed.

Practical implication: build explicit idempotency and stop conditions into scheduled release automation.

Why undefined values break guardrails in publishing logic

The root cause described by StepSecurity was a JavaScript quirk where the code passed undefined instead of the intended publish label. In many libraries, undefined can silently fall back to default behaviour or override the expected default path in ways that are hard to spot in review. The result here was that the workflow never applied the label logic it relied on for de-duplication, so the same deprecation action repeated every run. This is a classic automation governance problem: a tiny variable-handling defect can defeat a control that looks sound on paper.

Practical implication: test workflow edge cases where defaults, labels, and conditional skips determine whether a package republishes.

Why trusted package ecosystems need anomaly monitoring

Package ecosystems such as npm depend on trust signals as much as on code integrity. Repeated deprecated releases do not necessarily indicate compromise, but they do indicate that the publishing system is behaving outside its intended operating model. That matters because release noise can mask real malicious activity, train analysts to ignore abnormal version churn, and distort the provenance trail used by downstream consumers. For supply chain governance, the important question is not only whether a release is malicious, but whether the publishing system can be relied on to behave predictably under automation.

Practical implication: monitor release cadence, version churn, and unusual publish repetition as supply chain control signals.

Threat narrative

Attacker objective: The objective was not a hostile intrusion but uncontrolled repeated publication of deprecated packages, which created operational noise and trust confusion across the ecosystem.

1. Entry occurred through a scheduled GitHub Actions publishing workflow that executed every 30 minutes across the DefinitelyTyped package set.
2. Credentialed automation then republished deprecated @types packages because the de-duplication check failed to apply the expected publish label.
3. The repeated loop produced 70+ identical releases with no code changes, creating supply chain noise and weakening trust signals in the package ecosystem.

Breaches seen in the wild

• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Release noise is now a supply chain governance issue, not just an operational annoyance. A repeated publish loop can be benign in intent and still harmful in effect because it creates the same visibility problem that attackers seek to exploit. The practical lesson is that release systems need controls for repetition, not only for malicious code. Practitioners should treat publish cadence anomalies as a control failure in their supply chain programme.

Identity-bearing automation is part of the trusted computing surface. When a GitHub Actions workflow publishes on behalf of a project, the workflow identity becomes a governance object in its own right. If the logic around that identity is weak, the organisation has delegated trust without adequate containment. Practitioners should manage CI/CD publishing identities with the same lifecycle discipline they apply to other privileged machine identities.

Idempotency is the named concept this incident exposes. A publishing process that cannot prove it has already completed its intended state change will eventually repeat that state change. In package governance, idempotency is what separates controlled deprecation from endless release churn. Practitioners should design release automation so a second execution cannot reproduce the first publish outcome unless the state truly changed.

Monitoring must distinguish benign automation bugs from malicious supply chain activity without dismissing either. The same kind of noisy version churn can hide credential abuse, compromised maintainers, or mass package poisoning elsewhere in the ecosystem. That means detection teams should alert on the pattern even when the immediate cause is a bug. Practitioners should use the anomaly as both a release-control signal and a threat-hunting cue.

Trusted open-source infrastructure needs lifecycle controls, not just maintainer goodwill. The speed of the fix is reassuring, but it does not remove the underlying governance gap that allowed repeated releases to occur. Open-source publishing paths now sit inside enterprise risk boundaries because they can influence downstream dependency trust at scale. Practitioners should treat package publishing workflows as governed production systems.

What this signals

Release storms reveal a trust gap in software supply chain governance. The issue is not only whether a publish event is malicious, but whether the automation behind it can be trusted to stop after completing its intended state change. For readers running dependency-heavy programmes, the practical shift is to monitor repetition as a control failure signal rather than a mere noise event.

Machine identities that publish artefacts need lifecycle controls just like human-administered privileged accounts. The workflow identity in this case was effectively authorised to make ecosystem-visible changes on a schedule. That means publishing automation belongs in the same governance conversation as other privileged non-human access, with ownership, scope, and termination conditions clearly defined.

For practitioners

• Implement publish idempotency checks Ensure scheduled package release jobs can only publish a deprecated or replacement version once unless the package state genuinely changes.
• Monitor release cadence anomalies Alert on repeated version bumps, identical release content, and unusually frequent publish events across trusted package namespaces.
• Review workflow identity and guard logic Audit CI/CD publishing workflows for default handling, skip conditions, and the machine identity allowed to publish packages.
• Tighten package deprecation controls Verify that deprecated packages cannot be republished repeatedly by automation when the package already reflects the intended deprecation state.

Key takeaways

• The incident shows that even trusted open-source publishing pipelines can fail in ways that produce repeated release noise and erode confidence in dependency governance.
• The evidence was a flood of more than 70 identical deprecated releases across @types packages, triggered by a scheduled workflow rather than a code change.
• The control lesson is to enforce idempotency, publish-state checks, and anomaly monitoring on package release automation before repetitive behaviour becomes normalised.

Key terms

• Release Storm: A release storm is a burst of repeated software publications that should have happened once or not at all. It usually points to broken automation, not deliberate change, and it can pollute package history, mask real activity, and erode trust in the software supply chain.
• Publishing Idempotency: Publishing idempotency is the property that running a release workflow multiple times produces the intended package state only once. In supply chain governance, this prevents scheduled automation from re-emitting the same artefact or deprecation event on every execution.
• Workflow Identity: A workflow identity is the non-human identity represented by an automated CI/CD process when it authenticates, accesses secrets, or performs actions in other systems. In practice, it is the authority carried by the pipeline itself, and it must be governed with explicit scope, review, and revocation.
• Release Cadence Anomaly: A release cadence anomaly is an unusual pattern of version publication, such as repeated identical releases, excessive frequency, or activity without code change. It is a control signal that can indicate automation defects, misconfigured deprecation logic, or supply chain abuse.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a practical foundation for governing privileged automation and the identities behind it.