Repository navigation
GHSA-g3hv-75wg-m249: clarify minimatch 3.1.5 applicability and affected range #10811
Description
Could the advisory reviewers and original publisher clarify whether minimatch 3.1.5 is affected by GHSA-g3hv-75wg-m249 / CVE-2026-118764, and correct the published affected range if this version is excluded?
The maintainer's advisory lists affected version 10.2.6. The GitHub Advisory Database record lists <11.0.1. Both describe input amplification in firstPhasePreProcess() with optimizationLevel >= 2, followed by quadratic secondPhasePreProcess() work. Why does the database include all earlier versions, including 3.1.5, when the described optimizer is absent from that source?
Our Nutrition App mobile lock at source 1efa58ccbcd4e8c5ef710d82b2072b190c0a7a34 installs four copies of minimatch 3.1.5 under these dependency paths (relative to apps/mobile):
| Installed package path | Owning dependency path |
|---|---|
node_modules/@jest/reporters/node_modules/minimatch |
@jest/reporters → glob@7.2.3 → minimatch@3.1.5 |
node_modules/jest-config/node_modules/minimatch |
jest-config → glob@7.2.3 → minimatch@3.1.5 |
node_modules/jest-runtime/node_modules/minimatch |
jest-runtime → glob@7.2.3 → minimatch@3.1.5 |
node_modules/test-exclude/node_modules/minimatch |
test-exclude → minimatch@3.1.5, also used by its glob@7.2.3 |
All four complete installed package payloads match the original npm 3.1.5 archive. The archive SHA256 is d81817ecf72de3c8c5d3724407752d943c9e1a42af5c437d9cb923be8a72c648; its SHA512 lock integrity is sha512-VgjWUsnnT6n+NUk6eZq77zeFdpW2LWDzP6zFGrCbHXiYNul5Dzqk2HHQ5uFH2DNW5Xbp8+jVzaeNt94ssEEl4w==. Each installed minimatch.js has SHA256 746849f267c4868a53729225bd85c7dccd387712136fb305fcc0a3eadd4a3d9d and is byte-identical to the versioned upstream source.
In that 3.1.5 source, Minimatch.prototype.make / make() (approximately lines 161–206) performs brace expansion, splits entries on slashes, then maps parse() over the portions. The full source contains neither firstPhasePreProcess, secondPhasePreProcess, nor optimizationLevel. The upstream changelog associates advanced preprocessing with 7.0 and the optimizationLevel option with 7.1. The referenced fix changes those modern preprocessing functions.
As a small corroborating observation, each installed 3.1.5 copy constructs **/../x, **/../**/../x, and **/../**/../**/../x with one globSet entry and identical parsed sets with and without { optimizationLevel: 2 }. This finite sample was run under a 10-second external deadline and 128 MiB JS heap limit; it is not an exhaustive denial-of-service test or the basis for a claim about all pattern behavior.
Our assessment is narrowly that the specific optimizer mechanism described by this advisory appears absent from the inspected 3.1.5 implementation. We are not asserting that minimatch 3 is generally safe, that all versions before 7 are unaffected, or that other brace-expansion/regular-expression/matching risks are absent. We have not dismissed the findings and are keeping them open pending authoritative clarification.
Please confirm whether 3.1.5 should be excluded, explain any different mechanism that makes it affected by this advisory, and determine the correct affected range from the relevant version history. We deliberately have not guessed a new lower bound or changed dependency versions merely to make scanner output disappear.
Activity
fix(deps): TypeScript解析器のminimatchを互換性を保って更新する (#299)
princekotecha commentedon Nov 2, 2026
Adding published-package evidence in support of this request, so the reviewers can check the whole pre-7 range rather than one version. This is a request to verify the range, not a claim that pre-7 releases are unaffected by any other mechanism.
Method. On 2 Nov 2026 we downloaded every published
minimatchtarball in the 3.x–7.x lines from the npm registry (npm pack minimatch@<version>, 75 tarballs). In every file of each tarball we counted the three identifiers the advisory text names:firstPhasePreProcess,secondPhasePreProcessandoptimizationLevel.firstPhasePreProcesssecondPhasePreProcessoptimizationLevelFirst release containing each identifier:
firstPhasePreProcessandsecondPhasePreProcessfirst appear in 7.0.0, andoptimizationLevelin 7.1.0. This matches the changelog note quoted above.None of the 56 published 3.x–6.x releases contains the functions or the option the advisory describes. Could the reviewers and the publisher please verify three things:
optimizationLevelappears;We have not changed any dependency versions to quiet a scanner, and our own findings stay open until you rule.
Per-release counts, with the SHA-1 of each npm tarball
firstPhasePreProcesssecondPhasePreProcessoptimizationLevel5236157a51e4f004c177fb3c527ff7dd78f0ef830f398a7300ea441e9c348c83d98ab8c9dbf9c40a2a4e4090b96b2db06a9d7df01055a62a77c9b7745166e286457f03306064be5497e8dbb0c3d320834da8f1290ee0f0f8e83d60ca69f8f134068604a34a2cab247c5f4cc03b85813ebbde7ae23a6406a2e78aeb8dceccb0d12b57a75872da43bc68e7d7ca5e6a59bd11e2ab0de1cfb843eb2d82e546c321c1f59168d5cba6b6fde15f6a88f557fe7eaf31d8ea879ad447200773912898b46cd516a7abbb5e50b019cd194bfd3e428f049a70817c038d89ab4be35b6a5cba9b31f503887018f579c89f81f61162e62489d910ea3970a77ac8edfd30340ccd038b758079580c88f8d5445f2bd6aa8f3cadefa0de79fbd69ebefe49964c07e98a5eb7c5191be997b2aaffacc86cf9879294e33a259536492d905e31be8420800b88d8172f2e1babcc3e249538b1a46970dfea13003575202103e58aa0065edbe85cbe5354c77135b640d9d511a46bdc4e563c22c3080cde9c0d8299b42d2c05fd94ee370ed49275dcbb9a3d050c342795b4dcece1d674dee104bb0fb833ebb85a78cbbca652479165fc14be25bb563a58662042fba4c5d3effa32115d4418eeaa7d1313a28b146e2a3288747dd3494c85d0cdb69c1a6dfadf2c8be0f890e4d5c5281d8402aaaeed18a9e8406ad99c46a19206c6effb9022f7528125187c92bd9e9b6366be1cf3415b1717b464f4971b144f6aabe8f2d0b8e4511e09c76c9dffcf9927ff2a31e74b5af11adf8b9604b0220939d7d6f0898acbd1508abe534d1929368a8fff10ae385b8cb023b634156a145fb365331b9aee5d4e2d39d872684e97b309a9104251c3f1aa4e9d1ccabd894be2c2091e01fd09211326dfd996ee022d1cfcb8cf5522ea69952cd2af95ae09477f122a969bce540b26998f278d34784a3dd25d96f5054d6d32a16ebcccd6421c674430acb199b8806c68169b1293ef15db0098b394540e8f9f744f9fda8dee4be00d2875b7ae572f9e699e674fdfdab587aa1fdd3b098e1b2e152b325d00be05080a3a4a31b2a53b769d72a5988f266b201676d8c47eb65b76b92ca19859768163dde0e998635f3a89068e96144a51bdcbada37326e86dc19434874a04e29df0ba64cb17e0eafd0a19977f5accebd4b3909a34f6611d428879b77e6296ea6fefa1c83d86c7e667d2d4bb3cb2f09f2db04a72f7a57a3bc42a7d1a22c8c89270daedfdcf136a4a495a31cf427e5344505b3640a5d7f34f10bd5f67d7b1aa0032931f2dac64adb51c8161adaa90e59b29022fd8e326364f0336e4f9282d5384bb324be5b5dae12a567c03d22908febd0ddd42f838160e09c0d72d385d8ae36b4419a77f42845a0ea694ca41342e14561bbec62802b59509f7e4b4035a25d7175e3801e1d75e1f3f4d65c9e537ec36762bb7c69cd5830b432627c9a4f7cb91ce4e802b70fd13294178c69c04dfc05aebdb97a4e79e427768af04c4c9814cbc59764053c6466bc704ab03c0ef00bc252a3eb7aa340f43d5cebcb2ca39aee3f5c78246aa2c546afa4c7e19294e41e5e9b8f02320a8df098715e228c918b2bd81f34d9543767a75346583590577d192cab9b88514f1832b9509d7378d3b0a361b02b4420c89fb2b8295621429c340eaaeb8f7b0fef16531de96e56944b744860976d34a806a43e4366dbfebdcd63a9c59ce9987343a86f81e1f1af99d47b48b7133a641b0748ba039719d5e5b252ebef9931e082549370815afdec3caed0319741ff59370007ebb8faff0a9b20cdb44357803e4cfb7337e7460308e7147c58250fa0dee3da7929cd43ecc64c434fc9622d3fe447db71c7caed8e1a5166705f9417985ba5149f2dbf2fa50c29832913b157e847d79ca671054253b840656720cb733f10f012cbf110a65134bb354ae9773b55256cdb045a2e15a8ab56cc5469eca75a26a1319e5c00900824ae721f2a6faba6846f3b891ccff9966dcf728813e845d6f254d8f4a5e4fd6baf44d5f10c8448365fba27ce8f2b8cb7d662fd416c779504f121173d54a02e0e6de33a98f18922e13aa8a6d0980ffc5302def35412b1b36261b78ef1b2f0db29b759bbcaf5dsquijano0129-oss commentedon Nov 2, 2026
Additional bounded differential evidence for this existing range review, directed to @isaacs as the original advisory publisher.
We acknowledge the maintainer's explanation that pre-11 releases are unsupported and that untrusted patterns carry broader denial-of-service risks. This is not a backport request or a claim of general safety; it asks only whether the mechanism described by this GHSA applies to the published 3.1.5 implementation.
Independent method (2 November 2026). We verified npm SHA512 integrity for unmodified minimatch 3.1.5, 10.2.6 and 11.0.4, with pinned published dependency payloads and no npm lifecycle scripts. We ran 63 isolated constructor cases on Node v24.18.0 / Windows: one child at a time, a 2,500 ms external deadline including startup, and a 256 MiB V8 old-space limit (not a hard RSS limit). Inputs were finite synthetic examples of the globstar/parent-traversal family already described in the advisory: seven depths, 2–14, at most 182 characters; option levels 0/1/2. Modern controls used the Linux platform option. No production or third-party service was tested.
62 cases completed; the only timeout was the 10.2.6 depth-14 level-2 control. Level-0/1 controls retained one globParts entry in every version. Across all 21 cases for 3.1.5, an accessor for the optimizationLevel option recorded zero reads; the modern controls did read it. Timings are observations from one machine, not universal thresholds.
Static review of 3.1.5 source identifies brace expansion, slash splitting and per-segment parsing in make(), but none of firstPhasePreProcess, secondPhasePreProcess or optimizationLevel. Its source SHA256 is
746849f267c4868a53729225bd85c7dccd387712136fb305fcc0a3eadd4a3d9d. In 10.2.6, level 2 enters the cloning/preprocessing and pairwise phases. The official fix bounds that work; 11.0.4 still expands entries in this sample and skips quadratic pairwise work above 1,000. We do not interpret it as zero expansion.Verified npm archive SHA256:
d81817ecf72de3c8c5d3724407752d943c9e1a42af5c437d9cb923be8a72c6485a3d2c8074a28229665727e47b8a1090941856a7962905efe05d20d3760355f8b97c503756b43cf21478a99901ff3e4670274aaeb93b5a432de7c93c1a059b88The narrowly supported conclusion is that the optimizer amplification mechanism described in this advisory is absent from the inspected 3.1.5 implementation and was not reproduced there, while the affected-version control reproduced it under the same finite protocol. This does not exclude other RegExp, brace-expansion or matching denial-of-service mechanisms.
Could the curation team and original publisher confirm whether 3.1.5 is intentionally included because of a different mechanism, or clarify the description/range if this optimizer mechanism is the intended scope? We have neither proposed an unverified lower bound nor suppressed the advisory or forced a major-version override. No exploit code is included, in accordance with this repository's contribution guidance.
dineshnaikj commentedon Nov 3, 2026
Additional evidence for GHSA-g3hv-75wg-m249 — minimatch affected version range
Thanks for investigating the affected version range and for the existing version-by-version evidence.
I independently examined the published npm tarballs, lockfile integrity and installed dependency paths for
minimatch@3.1.5andminimatch@10.2.6.1. Dependency graph and minimatch 3.1.5
The npm audit report contains 16 findings. Tracing each finding through the lockfile gives this breakdown:
Therefore, 14 of the 16 findings depend on the minimatch 3.1.5 copy, eight of them exclusively on that copy.
The installed minimatch 3.1.5 package is identical to the published registry tarball, and its lockfile integrity matches (the SHA-256 values are the same as those posted above).
It contains none of
firstPhasePreProcess,secondPhasePreProcessor the associatedoptimizationLevelimplementation.The 3.1.5 copy is required directly by
eslint,@eslint/config-array,@eslint/eslintrc,eslint-plugin-import,eslint-plugin-jsx-a11yandeslint-plugin-react. Two further findings,@eslint-community/eslint-utilsand@next/eslint-plugin-next, depend on it indirectly througheslint.Because the preprocessing implementation described in this advisory is absent from this release, I would appreciate clarification on whether the specific globparts amplification mechanism applies to the 3.x release line.
2. minimatch 10.2.6
The installed
minimatch@10.2.6package also matches the published registry tarball and its lockfile integrity.Unlike 3.1.5, this release contains the preprocessing implementation described in the advisory.
However, the inspected dependency path through
@typescript-eslint/typescript-estreeuses the defaultoptimizationLevelof 1 and passes only{ dot: true }.Based on this inspected call path, the specific preprocessing functionality associated with the reported vulnerability does not appear to be reached through this consumer configuration.
This is an observation about the inspected dependency usage, not a general assertion that the installed version cannot be exploited through other inputs or code paths.
3. Compatibility considerations
A blanket override to
minimatch@11is not compatible with the existing ESLint dependency tree.Several consumers of the 3.x copy call the minimatch function directly or rely on its older default-export interoperability. Version 11 has a different module export shape.
The
typescript-estreedependency path uses the namedminimatchexport and appears to be independently overrideable, subject to compatibility testing.4. Maintainer response and request for clarification
I acknowledge the maintainer's November 1 response in
isaacs/minimatch#333. I understand that pre-11 releases are considered unsupported and that backports are not planned. I also recognise that older versions may have other denial-of-service weaknesses.My question is specifically about the affected-version range for the vulnerability described in this advisory.
Could the reviewers clarify:
A more precise affected range would help downstream maintainers apply compatible security updates rather than forcing major-version overrides that break existing consumers.
Thank you for reviewing this additional evidence.
Babylon-Lion commentedon Nov 3, 2026
Adding one measurement on the lower-bound question raised above (7.0.0 or 7.1.0), and some dependency context. This asks the curators to verify the range. It does not claim that releases before 7 are free of other matching, brace-expansion or RegExp risks.
Method
--ignore-scripts; npm verified each package's integrity.Minimatchfor a pattern of n repeated**/..segments, the transformation the advisory describes.set.length), then the constructor time.{ optimizationLevel: 2 }.Observations
preprocess()callsfirstPhasePreProcess()andsecondPhasePreProcess()for every pattern, and theoptimizationLeveloption does not exist yet.optimizationLevel2, as the advisory describes.If the mechanism does start in 7.0.0, the affected range would be
>= 7.0.0, < 11.0.1, with 7.0.0 affected even with default options. We are not asserting that range. Could the curators and the publisher please:Why the range matters downstream. These packages require minimatch 3.x, including in their latest releases:
eslint-plugin-reactminimatch ^3.1.2eslint-plugin-importminimatch ^3.1.2eslint-plugin-jsx-a11yminimatch ^3.1.2@eslint/eslintrcminimatch ^3.1.5eslint9.39.xminimatch ^3.1.5eslint-config-next16.4.x depends on the first three. ESLint 10.x requires^10.2.6, which is inside the range and contains the affected code.Forcing a newer major onto the 3.x consumers is not a compatible fix. 3.1.5's CommonJS export is a function, which these packages call directly, while 10.x and 11.x export an object with a named
minimatchfunction. Projects in this position have no upgrade that leaves the published range, so the advisory's accuracy decides whether they can treat the finding as resolved.Thank you for reviewing this.