On February 17, 2026, StepSecurity AI Package Analyst flagged something unusual: a sudden flood of version releases across several well-known @types/ packages on npm — including @types/mapbox__point-geometry, @types/tar, and others. What started as an anomaly alert turned into a fascinating investigation into a subtle automation bug in one of the most important open-source toolchains in the JavaScript ecosystem.
Background: What Are @types Packages?
@types/ packages on npm are community-maintained TypeScript type definitions for JavaScript packages that don't ship their own types, hosted on DefinitelyTyped. As more packages began bundling types natively, their corresponding @types/ stubs became redundant and are marked deprecated. For a deeper overview, see the official TypeScript handbook.
What We Observed
Our AI Package Analyst detected the following anomalies across multiple @types/ packages:
No code changes between releases — only version number bumps
The first release in each chain was a legitimate deprecation notice (correct behavior: these are stubs packages whose originals now include their own types)
All subsequent releases were identical deprecated versions, repeating endlessly
This pattern was a clear red flag. Legitimate deprecation publishing should be a one-time event per package. Something was stuck in a loop.
Tracing the Source: An Automated GitHub Workflow
Digging deeper, we traced all the releases back to a single GitHub Actions workflow: microsoft/DefinitelyTyped-tools → publish-packages.yml
This workflow is responsible for automating npm package publishing for DefinitelyTyped. A few key details about how it works:
It runs every 30 minutes on a scheduled trigger.
On each run, it reads notNeededPackages.json from the DefinitelyTyped repository — a file listing all @types/ packages that are no longer needed because their source packages now bundle types directly
For each package in that list, it publishes a deprecated version to npm
Under normal circumstances, this is a “publish once and move on” process. But something was causing the workflow to keep re-publishing deprecated versions on every run, incrementing the version each time — over and over, every 30 minutes.
The Root Cause: A Broken Loop Guard
The workflow was designed to publish a deprecated version of a package exactly once — before each run, it checks npm to see if the package is already marked as deprecated and skips it if so.
The bug came down to a JavaScript quirk: the code was supposed to pass "latest" as the publish label, but instead passed undefined, which silently overrides built-in library defaults rather than falling back to them. So the label was never applied, the check never found it, and a new version was published on every run — every 30 minutes — resulting in 70+ identical releases with no code changes.
The fix was a one-liner ensuring the label always defaults to "latest", which immediately broke the loop. We raised the issue in the repository here, and maintainer jakebailey who jumped on it immediately — diagnosing the root cause, opening a fix, and getting it reviewed and merged all within the same day. That kind of responsiveness in open source is rare and genuinely appreciated.
Why This Matters
At first glance, this might seem like a minor operational hiccup — a few extra deprecated versions on npm that nobody will install. But it’s worth thinking about the broader implications:
Noise becomes cover: An attacker who understands how automated pipelines work could potentially exploit or mimic this pattern. A flood of innocuous-looking version bumps is exactly the kind of signal that gets ignored. Our monitoring systems are designed to surface exactly this kind of anomaly before it can be used as camouflage.
Automated publishing pipelines need tight guardrails: This workflow runs every 30 minutes and publishes packages on behalf of one of the most widely used TypeScript toolchains in the world. A bug in the logic — even a one-liner involving undefined — can have outsized, cascading effects across the npm ecosystem.
Supply chain visibility matters: If we weren’t monitoring npm release patterns at scale, this incident could have continued for days or weeks without anyone noticing. The @types/ packages collectively have millions of weekly downloads. Any unexpected behavior in this space deserves attention.
Conclusion
This was a case where proactive monitoring caught a real automation bug — one that was entirely benign in intent, but had the potential to go unnoticed and erode trust in a critical part of the TypeScript ecosystem. We commend the DefinitelyTyped-tools maintainers for their swift response.
At StepSecurity, we continuously monitor npm, GitHub Actions workflows, and other supply chain vectors for anomalous behavior. This incident is a good reminder that even well-maintained, widely trusted projects can have subtle bugs with ecosystem-wide blast radius.
If you’re interested in how we monitor npm release patterns or want to learn more about supply chain security, reach out to us.
References
• microsoft/DefinitelyTyped-tools PR #1255
.png)
