[phoen-ix]

Summary: minimatch versions before 7.0.0 do not contain the vulnerable code, so the affected range should start at 7.0.0 instead of 0.

The advisory describes globParts amplification in firstPhasePreProcess() when optimizationLevel >= 2. Both firstPhasePreProcess and the optimizationLevel option first appear in minimatch 7.0.0 (published 2023-02-20). No release of an earlier major line has either of them.

I checked the published npm tarballs by searching their JavaScript for firstPhasePreProcess or optimizationLevel:

version	matches
3.1.5 (latest 3.x)	0
4.2.5, 4.2.6 (latest 4.x)	0
5.1.9 (latest 5.x)	0
6.2.0, 6.2.3 (latest 6.x)	0
7.0.0	3
10.2.6	8

Command to reproduce for one version:

curl -sL https://registry.npmjs.org/minimatch/-/minimatch-6.2.3.tgz | tar -xzO --wildcards '*.js' | grep -c 'firstPhasePreProcess\|optimizationLevel'

Why it matters: minimatch 3.x is still everywhere through eslint 9 (@eslint/eslintrc, @eslint/config-array) and multimatch. Those projects get Dependabot alerts they cannot act on: minimatch 11 has no default export, so it can't replace 3.x under eslint 9.

The change: "introduced": "0" → "introduced": "7.0.0".

[mdwekat]

Independent verification corroborates that minimatch 3.1.5 lacks the optimizer described by GHSA-g3hv-75wg-m249.

We checked integrity-verified official npm packages 3.1.5, 10.2.6 and 11.0.3. The versioned 3.1.5 source contains neither firstPhasePreProcess, secondPhasePreProcess, nor the optimization-level implementation changed by the advisory's fix. The maintainer advisory lists affected 10.2.6, while the global record currently covers every release below 11.0.1.

A bounded comparison of the documented preprocessing mechanism, with a requested 64-pattern expansion cap, produced one pattern in 3.1.5, exhausted a 64 MiB child heap in 10.2.6, and stopped at 64 patterns in 11.0.3. Each child had a three-second external deadline inside a resource-limited disposable container. A smaller 10.2.6 control produced 4/16/64 patterns for 2/4/6 repeated segments. With the actual lint consumers' default optimization options, all three versions instead produced one pattern immediately.

Our scope is the confirmed absence of this particular mechanism in 3.1.5; we did not independently establish the earliest affected release and are leaving that lower-bound decision to the version-history review here. This does not claim minimatch 3 is free of every denial-of-service issue. It explains why overriding legacy callable 3.x with incompatible 11.x solely to clear this alert is unnecessary; modern 10.2.6 consumers have been upgraded to 11.0.3 independently.

[shelbyc]

Closed as a duplicate of #10807