Four Dependabot Updates runs have been failing on master since at least 2026-07-26, showing as red checks on the commit alongside the actual CI workflow. They are unrelated to #1882 / #1883.
Scope: dev-only, no consumer impact
All four packages are absent from the production dependency tree (verified with npm ls <pkg> --omit=dev). Nothing here reaches anyone who installs mssql — the exposure is confined to CI and release tooling. There is no security clock running on this.
Why each one fails
| Package |
Dependabot reason |
Detail |
tar |
downgrades_dependencies |
Patched 7.5.21 exists, but the available path would downgrade semantic-release 25.0.3 → 24.2.9. Reached four ways: libnpmdiff@8.1.10, node-gyp@12.4.0, npm@11.17.0, pacote@21.5.1 |
js-yaml |
downgrades_dependencies |
Patched path would downgrade @commitlint/cli 20.5.3 → 17.3.0 |
brace-expansion |
dependency_still_vulnerable |
npm "still resolves it to 1.1.18"; three copies in tree (1.1.12, 2.0.2, 5.0.4) |
undici |
update_not_possible |
Two copies present: 7.24.4 and 6.24.1 |
These runs fail by design when a security update isn't viable — it's Dependabot reporting that it can't act automatically, not a broken pipeline. They don't block merges.
Options
- Leave them. They resolve on their own when
semantic-release and @commitlint/cli bump their own trees. Cost: four persistent red checks on every commit.
- Add
overrides to pin the patched transitives — this is Dependabot's own suggestion (option 2 in its explanation).
If we go with (2), the tar override is the one to be careful with: semantic-release reaches tar through a bundled npm@11.17.0 → pacote / node-gyp / libnpmdiff. Forcing tar across all of those risks breaking the actual publish path — i.e. jeopardising the release pipeline to silence a dev-only advisory. That warrants a dry-run release before merging, not a quick pin.
js-yaml, undici and brace-expansion are lower risk and could be pinned independently of tar if we want to cut the noise down without touching the release path.
Filed for visibility so the red checks on master have a known cause; no urgency implied.
Four Dependabot Updates runs have been failing on
mastersince at least 2026-07-26, showing as red checks on the commit alongside the actual CI workflow. They are unrelated to #1882 / #1883.Scope: dev-only, no consumer impact
All four packages are absent from the production dependency tree (verified with
npm ls <pkg> --omit=dev). Nothing here reaches anyone who installsmssql— the exposure is confined to CI and release tooling. There is no security clock running on this.Why each one fails
tardowngrades_dependenciessemantic-release25.0.3 → 24.2.9. Reached four ways:libnpmdiff@8.1.10,node-gyp@12.4.0,npm@11.17.0,pacote@21.5.1js-yamldowngrades_dependencies@commitlint/cli20.5.3 → 17.3.0brace-expansiondependency_still_vulnerableundiciupdate_not_possibleThese runs fail by design when a security update isn't viable — it's Dependabot reporting that it can't act automatically, not a broken pipeline. They don't block merges.
Options
semantic-releaseand@commitlint/clibump their own trees. Cost: four persistent red checks on every commit.overridesto pin the patched transitives — this is Dependabot's own suggestion (option 2 in its explanation).If we go with (2), the
taroverride is the one to be careful with:semantic-releasereachestarthrough a bundlednpm@11.17.0→pacote/node-gyp/libnpmdiff. Forcingtaracross all of those risks breaking the actual publish path — i.e. jeopardising the release pipeline to silence a dev-only advisory. That warrants a dry-run release before merging, not a quick pin.js-yaml,undiciandbrace-expansionare lower risk and could be pinned independently oftarif we want to cut the noise down without touching the release path.Filed for visibility so the red checks on
masterhave a known cause; no urgency implied.