BuildNot yet confirmed elsewhere1 publisher2 min readPublished
Deno's audit --fix left deno.lock untouched on a semver ReDoS with a patched version available
Deno 2.9.7's `deno audit --fix` left deno.lock byte-for-byte identical on a vulnerable semver, a dev.to author reported. The post says --ignore and --frozen-lockfile did the same, so CI needs its own check that a fix happened.
The Engineer · Build desk
What happened
- The author's test project pinned minimist 0.0.8, lodash 4.17.4 and semver 7.5.1, and deno audit reported advisories from the GitHub Advisory database the same way across three runs.
- To build the simplest qualifying case, the author installed semver 7.5.1 and then widened the range to ^7.5.1 in package.json without reinstalling.
- On the stale lockfile, deno audit --fix printed the exact same high-severity report as the plain audit, ending in 'Found 1 vulnerabilities'.
Why it matters
- contradiction The documented promise covers this case, and the lockfile still did not move. Either the docs overstate what --fix does, or the flag has a bug in this state.
- decision A pipeline that runs --fix and moves on has no evidence from this test that anything was remediated. Each run needs a lockfile diff and a second audit.
- constraint The result transfers only to projects whose lockfile pins a vulnerable direct dependency while the manifest range already reaches the fix.
The audit half of the command passed the author's checks. Each advisory carried a severity, an affected range and a GitHub advisory link, and the lodash entry read critical, vulnerable below 4.17.12 [7]. The author checked the entries against the public record and found them real, including CVE-2022-25883 for the semver ReDoS [8]. The post's headline counts 13 findings in the test project [19].
The install side also behaved. Deno warned that it had ignored build scripts for npm:core-js@3.39.0, and no script ran [9]. After `deno approve-scripts core-js`, the postinstall ran and the approval was written to deno.json as an allowScripts array, so it shows up in a diff [10]. The author called it the one claim in the post that worked exactly as documented [10].
The `--fix` flag is the problem. It is documented as a Deno 2.8 addition, so this is recent behavior [3]. The documentation says it will "automatically upgrade vulnerable direct dependencies to a patched, semver-compatible version," skipping only major-version bumps and transitive dependencies with no clean upgrade path [11]. The test case sits inside that promise. semver is a direct dependency, and the move from 7.5.1 to 7.8.5 stays within major 7, so neither documented skip applies [18].
The author staged the lockfile by pinning semver to 7.5.1, installing, and then widening the range to ^7.5.1 without reinstalling [12]. The author wrote that this is "how a lockfile actually goes stale in practice" [13]. A fresh install of the same range resolved to 7.8.5, so the fix was reachable [15]. After `--fix`, deno.lock was unchanged [17].
The evidence is one package and one advisory. The post's text ends mid-sentence in the --fix section, so the --ignore and --frozen-lockfile results rest on the author's one-sentence summary [4].
In our view, a CI job should treat the lockfile as the evidence. Hash deno.lock before and after the flag, then run a second audit and read it. A fix flag that reprints the report is, in effect, a second audit.
What to watch
- A Deno issue, reply or release after 2.9.7 that fixes --fix or documents why it made no change in this state.
- The full --ignore and --frozen-lockfile runs, or an independent reproduction on a lockfile that agrees with its manifest.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence58
- Adoption
- Insufficient
- Hype gap+15
- Incentives
- Insufficient
- Confidence55
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
deno audit is Deno's built-in command for checking npm dependencies against known vulnerabilities, and the post's author says it works well for that.
- [2]
The author tested on Deno 2.9.7, installed fresh from the official installer.
- [4]
The author says --fix, --ignore and --frozen-lockfile, three flags documented to act on audit findings, each left the vulnerable state completely untouched when tried.
- [5]
The test project depended on minimist 0.0.8, lodash 4.17.4 and semver 7.5.1, chosen because they are old enough to be vulnerable to issues fixed upstream.
- [6]
After deno install, deno audit pulled from the GitHub Advisory database and reported the same result across three separate runs on the test project (minimist 0.0.8, lodash 4.17.4, semver 7.5.1).
- [7]
Every advisory came with a severity, the affected version range and a link to the GitHub advisory; the lodash prototype pollution entry read critical, vulnerable below 4.17.12, GHSA-jf85-cpcp-j695.
- [8]
The author checked the advisories against the public record and found them real, and names the semver ReDoS as CVE-2022-25883.
- [9]
Running deno install with core-js@3.39.0 printed a warning that build scripts were ignored for npm:core-js@3.39.0, and no script ran.
- [10]
After deno approve-scripts core-js, the postinstall script ran and the approval was written to deno.json as an allowScripts array, visible in a diff and in code review; the author calls this the one claim in the post that worked exactly as documented.
- [11]
Deno's documentation says --fix will "automatically upgrade vulnerable direct dependencies to a patched, semver-compatible version," skipping only major-version bumps and transitive dependencies with no clean upgrade path.
- [12]
The author pinned semver to exactly 7.5.1, installed it, then widened the constraint to ^7.5.1 in package.json without reinstalling, to simulate a stale lockfile.
- [13]
The author wrote that loosening a version range without immediately running install is "how a lockfile actually goes stale in practice".
- [14]
semver 7.5.1 is vulnerable to a ReDoS, GHSA-c2qf-rxjj-qqgw, fixed in 7.5.2.
- [15]
A fresh install of ^7.5.1 with no prior lockfile resolved to 7.8.5, which the author calls a clean, same-major, semver-compatible upgrade.
- [16]
On the stale lockfile, deno audit reported semver as high severity, vulnerable >=7.0.0 <7.5.2, ending 'Found 1 vulnerabilities'; deno audit --fix printed the exact same report.
- [17]
deno.lock was byte-for-byte identical before and after deno audit --fix.
- [18]
semver is a direct dependency and the move from 7.5.1 to 7.8.5 stays within major version 7, so neither documented skip condition (major bumps, transitive dependencies without a clean path) applies to the test case.
- [19]
The post's headline says deno audit --fix found 13 vulnerabilities and fixed none of them.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toDeno's audit --fix flag found 13 vulnerabilities and fixed none of them
1 article · October 13, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.
Topics
- Software Supply Chain SecurityFollow
- Lockfiles and CI gatingFollow
- Dependency auditingFollow