[1abcdefggs]

Updates

• Affected products
• CVSS v4

Comments
The advisory lists every minimatch version below 11.0.1 as affected. The code it describes (firstPhasePreProcess(), the **/.. clone step and the optimizationLevel option) does not exist in the older release lines, and the behaviour does not reproduce there. Dependency scanners therefore also flag minimatch 3.x and 5.x (which build tools such as electron-builder pull in transitively) and 6.x, which fall inside the stated range. I checked every published version from 5.0.0 to 10.2.6; the method and results are below so they can be reproduced.

1. Where the code exists (84 published tarballs, 5.0.0 to 10.2.6)

Method: npm pack minimatch@<version>, extract, and search the .js files for three markers: firstPhasePreProcess, optimizationLevel, and the clone step other[gs] = '**'.

Versions	firstPhasePreProcess	optimizationLevel	clone step
5.0.0 to 6.2.3 (32 versions)	absent	absent	absent
7.0.0 and 7.0.1 (2 versions)	present	absent	present
7.1.0 to 10.2.6 (50 versions)	present	present	present

All 84 tarballs downloaded and each contained a package.json with the matching version and its JavaScript sources; no version from 7.0.0 to 10.2.6 loses a marker. Versions below 5.0.0 were not scanned, except 3.1.5, which has none of the markers.

2. Behaviour (reproduction with the pattern from the upstream fix)

Method: the test added by the upstream fix (isaacs/minimatch commit 77a0f5c, test/preprocess-limits.ts, which uses n = 30) builds the pattern Array(n).fill('**/../a/b').join('/'). I constructed new Minimatch(pattern, options) for n = 2, 4, ..., 14 and recorded set.length and construction time (Node 24.17.0, heap limited to 512 MB, 40 s timeout). Timings depend on the machine and on its load (the same code took 28 s on 7.0.0 and 13 s on 7.0.1); n = 14 is shown.

Version	Default options	optimizationLevel: 2
3.1.5, 5.1.9, 6.2.3	1 set	1 set
7.0.0	16384 sets, 28.2 s	16384 sets, 19.5 s
7.0.1	16384 sets, 13.3 s	16384 sets, 9.0 s
7.1.0	1 set	16384 sets, 12.0 s
9.0.9	1 set	16384 sets, 11.9 s
10.2.6	1 set	16384 sets, 8.7 s
11.0.1 (fixed)	1 set	16384 sets, 0.27 s

So the advisory's claim is confirmed for 9.x and 10.x at optimizationLevel 2, and the older lines (3.x, 5.x, 6.x) are not affected. For 7.1.0 and later the default level does not trigger it. For 7.0.0 and 7.0.1, which have no optimizationLevel option, the amplification happens with default options. Ordinary patterns (30 everyday globs, including deep paths) finished in milliseconds on every version I tried (3.1.5, 5.1.9, 7.0.1, 9.0.9, 10.2.6 and 11.0.1), with default options and with optimizationLevel 2.

3. Attack requirements metric

The description says the problem occurs "when optimizationLevel >= 2". From 7.1.0 the default is not 2, and the table above shows no growth with defaults on 7.1.0, 9.0.9 and 10.2.6. The current vector has Attack Requirements: None. Because a non-default option is needed, Present looks like the better value for 7.1.0 and later. 7.0.0 and 7.0.1 are the exception: they amplify with defaults.

Suggested change

1. Set the affected range to start at 7.0.0 (>= 7.0.0, < 11.0.1).
2. Review Attack Requirements (None -> Present) for 7.1.0 and later, noting the 7.0.x exception.

Why this matters

Build tooling such as electron-builder still depends on minimatch 3.x and 5.x, and the glob patterns it processes come from the project's own configuration. Reporting those copies as affected adds alerts that cannot be acted on and cannot be fixed by a version bump: an override to 11.x breaks consumers that call the old CommonJS function export, such as @electron/asar.

[github]

Hi there @isaacs! A community member has suggested an improvement to your security advisory. If approved, this change will affect the global advisory listed at github.com/advisories. It will not affect the version listed in your project repository.

This change will be reviewed by our Security Curation Team. If you have thoughts or feedback, please share them in a comment here! If this PR has already been closed, you can start a new community contribution for this advisory