minimatch GHSA-g3hv-75wg-m249 (CVE-2026-118764): are you exposed, what an override to 11 breaks, and how to record an exception

Are you exposed?

The advisory describes one mechanism. A pattern that repeats **/../ makes minimatch copy the pattern during preprocessing, again and again, and then compare every copy with every other copy. The advisory says this happens "when optimizationLevel >= 2" and calls the result "excessive cpu and memory consumption".

Ask one question: can someone outside your team choose a pattern that reaches minimatch or glob?

• No. The patterns come from your own code, from config files in your repository that your team reviews, or from your build tools: lint ignore lists, test globs, files arrays. You are not exposed. Running eslint on your own repository with your own config is this case. In the maintainer's words, it falls under "stop hitting yourself".
• Yes. For example, a service takes a glob from a request, a form or an uploaded config file and matches files with it. Then you are exposed to denial of service through the pattern. This advisory's mechanism runs only where the table below says it does (glob turns it on; minimatch 7.1.0 or later called directly with its default setting does not), but the maintainer does not count that as safe on any version: "If you are using attacker-controlled patterns, you are vulnerable to denial of service, and there is no way out of this." The options the maintainer gives are "Don't do that" and "Upgrade to v11 (and probably still don't do that)." The minimatch README warns against this use: "If you create a system where you take user input, and use that input as the source of a Regular Expression pattern, in this or any extant glob matcher in JavaScript, you will be pwned." A CI job that runs the lint or test config of an outside pull request is this case too.

If the answer is no, your remaining problem is the alert, not the code. Sections 2 and 3 are about the alert.

Which minimatch versions contain the code the advisory describes

We read the published npm packages for every minimatch release from 7.0.0 to 11.0.4, and the newest release of 3.x, 4.x, 5.x and 6.x; we did not run them. The two preprocessing steps the advisory names are firstPhasePreProcess and secondPhasePreProcess.

This table is about one mechanism. It does not make 3.x to 6.x safe for patterns an outsider chooses: the maintainer's answer above applies to every version, and 11 only limits this mechanism.

Two things in that table matter more than the version number.

glob is the caller that turns the code on. glob 9, 10, 11, 12 and 13 pass optimizationLevel: 2 to minimatch (we read glob 9.3.5, 10.5.0, 11.0.3, 11.1.0, 12.0.0 and 13.0.6). So the exposed case, in practice, is glob matching a pattern someone else chose. glob 7 and 8 depend on minimatch 3 and 5, which do not contain the code.

glob 13 carries its own copy. In glob 13.0.2 to 13.0.6, the file that require('glob') and import { glob } from 'glob' load has a copy of minimatch built in, without the 11.0.1 limits; it does not load the minimatch package at all. jest 30 depends on glob 13. With --coverage it also uses glob 10 and minimatch through test-exclude. A different minimatch version in your lockfile does not change what glob 13 runs; we tested that. glob 14.0.0 to 14.0.2 are built the same way and also carry the unpatched code; glob 14.0.3 carries the patched code.

If your lockfile has minimatch 7.0.0 or 7.0.1, a ^7 range already allows 7.4.9, the newest 7.x.

To see every copy of minimatch in your project and what pulls it in:

npm ls minimatch --all

With pnpm, pnpm why minimatch; with Yarn, yarn why minimatch.

Forcing minimatch 11: what breaks

The usual fix in the threads is to force every copy of minimatch to 11 in package.json:

"overrides": {
  "minimatch": "11.0.4"
}

With Yarn the field is resolutions, with pnpm pnpm.overrides; we tested only npm's overrides.

We installed each package below in a new npm project twice, as published and with that override, and ran one small test that reaches the package's minimatch call. Then we ran npm audit.

Why five of them break. minimatch 3 exports the matching function itself. minimatch 11 exports an object that has a minimatch function on it, and no longer exports makeRe. Code written for 3.x calls the object and throws minimatch is not a function. The error comes only when that code runs: in eslint-plugin-react and eslint-plugin-import, only the rules we gave a pattern option threw. jsx-no-undef, jsx-key, import/no-unresolved, import/named and the same two rules without the option ran normally. eslint-plugin-import-x fails as soon as eslint loads the config, because it imports makeRe.

"Works in our test" covers one use per package: ignore patterns with a ! negation for eslint, allowDefaultProject for typescript-estree, archive.glob('**/*.txt') for archiver, a coverage run for jest. Other options of the same package were not tested. The eslint-plugin-react and eslint-plugin-import rows ran with eslint 9.39.5, because eslint-plugin-react 7.37.5 declares eslint ^9.7 as its highest supported version.

glob 13 runs the same code with or without the override. The file glob 13.0.6 loads, dist/commonjs/index.min.js, had the same SHA-256 in both projects; it carries its own built-in minimatch copy (see above). The override changes npm ls and the audit, not what glob 13 runs. jest 30 also reaches minimatch another way: with --coverage, test-exclude loads glob 10.5.0 and minimatch itself, and the override does change those copies (our jest test passed with it).

aws-cdk-lib ships its own copy. Its node_modules/minimatch stayed at 10.2.6 on disk, npm ls printed 10.2.6 overridden, and npm audit still listed the advisory.

A second alert after the override. For archiver 7.0.1, jest 30 and glob 13, npm audit still exited 1 because of GHSA-3g3m-2fjr-6pw4, a separate glob advisory (glob 9.0.0 to 14.0.1; GitHub lists 14.0.2 as the fix). Overriding minimatch does not clear it. The glob section below covers it.

An override that leaves the old packages alone (npm)

npm lets you scope an override to one package's dependencies. If only some of your packages work with 11, override minimatch inside those:

"overrides": {
  "eslint": {
    "minimatch": "11.0.4"
  }
}

We tested this in one npm project with eslint 10.14.0 and eslint-plugin-react 7.37.5, installed with npm install --legacy-peer-deps because the plugin does not declare eslint 10 support:

• eslint's copy became 11.0.4; eslint-plugin-react kept its own 3.1.5.
• npm audit went from 5 entries to 2. The 2 left are minimatch (the plugin's own copy, 3.1.5) and eslint-plugin-react, which depends on it.
• Both tests passed in the same project: eslint's ignore pattern and the react/jsx-pascal-case rule.
• The same project with the global override from the top of this section had 0 audit entries, and eslint failed with TypeError: minimatch is not a function.

Those numbers are from one small project. In a larger one (eslint 9, typescript-eslint, eslint-plugin-react, eslint-plugin-import and jest 30, with an existing package-lock.json), the eslint key took the audit from 31 entries to 27, and GHSA-g3hv-75wg-m249 was still listed through typescript-eslint and jest. Naming typescript-eslint and jest as extra keys changed nothing on the existing lockfile. Naming the packages that npm ls minimatch --all shows depending on minimatch directly (@typescript-eslint/typescript-estree, test-exclude and @jest/reporters there) moved those copies to 11.0.4 and took the audit to 21; npm install and npm ci exited 0, and eslint and jest --coverage ran normally. What was left was the two eslint plugins' minimatch 3.1.5 and the separate glob advisory, plus entries for other packages (deepmerge, for example).

After editing package.json, run npm install and commit the new package-lock.json. If you only change package.json, npm ci fails with Missing: minimatch@11.0.4 from lock file. Afterwards npm ls exits 1 with npm error code ELSPROBLEMS and marks the overridden copy invalid, although installs and our tests worked. A CI step that runs npm ls turns red.

This works with npm because npm installed the plugin's minimatch 3.1.5 inside the plugin's own folder. We did not test pnpm or Yarn, which lay out node_modules differently. The 2 remaining entries need an exception.

Node 18

minimatch 11.0.4 declares Node 20 || >=22. On Node 18.20.8 with npm 10.9.9, npm install with the override printed EBADENGINE warnings and installed. With engine-strict=true it failed with EBADENGINE. The installed 11.0.4 loaded through require and import on 18.20.8, and the typescript-estree test passed. That is all we ran on Node 18.

The glob alert that follows: override to 14.0.3, not 14.0.2

Added 2 November 2026.

GHSA-3g3m-2fjr-6pw4 (CVE-2026-118773) is a separate advisory against glob 9.0.0 to 14.0.1. GitHub lists 14.0.2 as the fix. jest 30, test-exclude, rimraf 6 and archiver 7 all bring in an affected glob, and none of them had moved to glob 14 when we checked on 2 November at 14:13 UTC: jest-config, jest-runtime and @jest/reporters 30.5.2 ask for glob ^13.0.6, test-exclude 8.0.0 for ^13.0.6, rimraf 6.1.3 for ^13.0.3, and archiver-utils 5.0.2, archiver 7's route to glob, for ^10.0.0. archiver 8.0.0 no longer depends on archiver-utils and brings in no glob.

Are you exposed? The advisory describes one mechanism: when a glob walk is cancelled through its signal option, the promise rejects but glob keeps reading directories in the background. That matters to code that passes signal, for example AbortSignal.timeout(), to cap the work on patterns or directory trees an outsider controls. The published packages of jest-config, jest-runtime and @jest/reporters 30.5.2, test-exclude 7.0.2 and 8.0.0, and archiver-utils 5.0.2 do not contain the word signal. rimraf 6.1.3 passes a signal to glob only when you give it both signal and its glob option. We read the code; we did not run the bug.

Use 14.0.3, not 14.0.2. With glob 14.0.2, npm audit stops listing this advisory. But glob 14.0.0 to 14.0.2 carry the same built-in minimatch copy as glob 13, without the 11.0.1 limits (above), and glob passes optimizationLevel: 2, which turns the advisory's preprocessing on. npm audit does not see that copy: in our jest 30 and eslint 10 project with minimatch overridden to 11.0.4 and glob to 14.0.2, it listed neither advisory. glob 14.0.3, published on 28 October six hours after 14.0.2, carries the copy with the 11.0.1 limits (we read both packages; see receipts). To clear both alerts in one step:

"overrides": {
  "minimatch": "11.0.4",
  "glob": "14.0.3"
}

With these two overrides, our eslint 10.14.0 and jest 30.5.2 project had one copy of each, glob 14.0.3 and minimatch 11.0.4. eslint and three jest runs passed, and npm audit listed neither advisory. It still exited 1; see below.

We installed each package below in a new npm project with "overrides": {"glob": "14.0.3"} and ran a test that reaches its glob call, the same way as for minimatch.

With the glob override alone, npm audit no longer listed the glob advisory in any of these projects. It exited 0 for rimraf 6.1.3 and rimraf 3.0.2. For jest 30 and test-exclude 8 it still exited 1 on the minimatch advisory, because test-exclude keeps its own minimatch 10.2.6; the minimatch override above takes care of that.

If glob is your own dependency, change the dependency instead of overriding it. npm's message names the clash: Override for glob@13.0.6 conflicts with direct dependency. With "glob": "14.0.3" in dependencies, globSync('**/*.js') ran and npm audit printed found 0 vulnerabilities.

Why rimraf 3 breaks. When the path you pass contains glob characters and does not exist as written, rimraf 3 calls the glob module itself as a function, glob(pattern, options, cb). glob 9 and later export named functions only, so the callback form with a glob pattern throws. A plain path skips glob in rimraf 3's code; we read that and ran only the pattern form. The global override reaches rimraf 3's glob 7.2.3 although glob 7 is outside this advisory's range: npm audit did not list GHSA-3g3m-2fjr-6pw4 for glob 7.2.3. Other packages that call glob 7 or 8 with a callback will break the same way; rimraf 3 is the one we tested. To leave them alone, scope the override to jest:

"overrides": {
  "jest": {
    "glob": "14.0.3"
  }
}

We tested this in one npm project with jest 30.5.2 and rimraf 3.0.2:

• Every glob copy under jest became one glob 14.0.3, including the glob 10 that test-exclude brings in with --coverage. No other key was needed.
• The three jest tests passed. rimraf 3 kept its own glob 7.2.3, and both rimraf.sync and the callback form ran with a glob pattern.
• npm audit no longer listed the glob advisory. It still exited 1, also with --audit-level=moderate, on the minimatch advisory (test-exclude's minimatch 10.2.6, and minimatch 3.1.5 under rimraf 3's glob 7) and on deepmerge.
• npm ls glob --all exited 1 with npm error code ELSPROBLEMS, as with the scoped minimatch override above. With the global glob override it exited 0.
• With the global override on the same project, rimraf('<dir>/**/*.tmp', cb) threw TypeError: glob is not a function.

We tested the scoped form with jest 30.5.2 only.

npm audit may still exit 1 on jest 30

With both overrides, our jest 30.5.2 project still had five low-severity entries: deepmerge (GHSA-gcqx-w48m-w2h4) and the four jest packages that depend on it. jest-config 30.5.2 asks for deepmerge ^4.3.1, and 4.3.1 is the newest deepmerge release, so no override fixes it. npm audit --audit-level=moderate exited 0 on the same project, so a CI step that fails only on moderate or higher findings goes green. That flag lets every low finding pass, not only these five.

glob 14 declares Node 18 || 20 || >=22. We ran these tests on Node 22 only.

Exceptions for the glob advisory

If you record an exception instead, the same tools and the same traps apply, with this advisory's own IDs. We repeated the exception tests on a project whose only dependency is glob 14.0.1.

The reason line is not the same as for minimatch. This advisory needs a glob walk cancelled through signal on patterns or directory trees an outsider controls (above), so a line about patterns alone does not cover it. A reason line you can adapt, again only if you checked that it is true for your project:

glob is not given an abort signal in this project, or only on patterns and directories from this repository, so the cancelled walk that GHSA-3g3m-2fjr-6pw4 needs does not happen here. Advisory: https://github.com/advisories/GHSA-3g3m-2fjr-6pw4

Yarn's numeric ID differs per advisory: minimatch's was 1244012, glob's 1244013. Copy yours from the ID: line of yarn npm audit. We tested pnpm 10 only for this advisory; on pnpm 11 and 12 the package.json form is not read (shown above for the minimatch advisory). For Trivy, the line in .trivyignore is:

CVE-2026-118773

If you can't override: record an exception

If no untrusted pattern reaches minimatch or glob, the honest record is an exception with the reason written down. A reason line you can adapt. Use it only if you checked that it is true for your project:

No untrusted input reaches minimatch or glob patterns; all patterns come from this repository's own code and config. Maintainer statement: https://github.com/isaacs/minimatch/issues/333#issuecomment-6563370272

We ran each tool on a project whose only dependency is minimatch 9.0.9, without and with each exception, and recorded the exit code. We then ran the exceptions again on a larger project with three copies of minimatch (eslint 9, typescript-eslint, eslint-plugin-react, eslint-plugin-import and jest 30). There the exception removed minimatch from the report, but the audits still failed on other advisories, such as the glob one above. Two tools accept only one of the advisory's IDs, and pnpm's setting moved between versions.

npm. npm audit has no per-advisory ignore; its help lists no such option. Two flags change the exit code, and both hide more than this advisory:

• npm audit --audit-level=high exits 0 here because npm rates this advisory moderate. It lets every moderate and low finding pass, not only this one.
• npm audit --omit=dev exits 0 only when minimatch is reached through devDependencies alone.

pnpm. Where the setting goes depends on the pnpm version. On pnpm 10, 11 and 12, put it in pnpm-workspace.yaml:

auditConfig:
  ignoreGhsas:
    - GHSA-g3hv-75wg-m249

pnpm audit then exited 0 and counted the advisory as ignored on pnpm 10.34.9, 11.28.9 and 12.16.1. On pnpm 11 and 12, the same setting under "pnpm" in package.json does nothing and the audit still exits 1. pnpm 11 and 12 print The "pnpm" field in package.json is no longer read by pnpm on pnpm install; pnpm 12.16.1 prints nothing on pnpm audit.

On pnpm 9 and 10, package.json works:

"pnpm": {
  "auditConfig": {
    "ignoreGhsas": ["GHSA-g3hv-75wg-m249"]
  }
}

On pnpm 9.15.9, in a project whose pnpm-workspace.yaml had no packages list, the pnpm-workspace.yaml form failed with packages field missing or empty. ignoreCves: ["CVE-2026-118764"] in place of ignoreGhsas worked in package.json on pnpm 9 and 10; we did not try it in pnpm-workspace.yaml. For a one-off run, pnpm audit --ignore GHSA-g3hv-75wg-m249 worked on pnpm 10, 11 and 12; pnpm 9 rejects --ignore as an unknown option. pnpm has no reason field; put the reason line in the commit that adds the exception.

Yarn. Yarn ignores this advisory only by the numeric ID it prints on the ID: line of yarn npm audit. In our run that was 1244012. In .yarnrc.yml:

npmAuditIgnoreAdvisories:
  - "1244012"

yarn npm audit --all --recursive then exited 0. With "GHSA-g3hv-75wg-m249", "CVE-2026-118764" or "GHSA-*" in the same list it still exited 1. npmAuditExcludePackages: [minimatch] and --exclude minimatch also exit 0, but they hide every advisory for minimatch, including future ones. Like pnpm, Yarn has no reason field.

osv-scanner. In osv-scanner.toml next to the lockfile:

[[IgnoredVulns]]
id = "GHSA-g3hv-75wg-m249"
reason = "No untrusted input reaches minimatch or glob patterns; see isaacs/minimatch#333"

osv-scanner scan source -L package-lock.json exited 0 (with --offline-vulnerabilities on a downloaded database). Online, on the larger project's package-lock.json, pnpm-lock.yaml and yarn.lock, the same file filtered all three copies. id = "CVE-2026-118764" worked as well, and so did an entry with ignoreUntil = 2027-01-01 added. osv-scanner then printed both "filtered out because" with the reason and "has unused ignores" naming the same ID. The ignore was applied; the second message is wrong.

Trivy. Trivy reports this finding as CVE-2026-118764, and only that ID works. In .trivyignore:

CVE-2026-118764

trivy fs --scanners vuln --exit-code 1 . then exited 0. With GHSA-g3hv-75wg-m249 in the file it still exited 1. .trivyignore.yaml (passed with --ignorefile) behaved the same way, and its statement field holds the reason:

vulnerabilities:
  - id: CVE-2026-118764
    statement: "No untrusted input reaches minimatch or glob patterns; see isaacs/minimatch#333"

--severity HIGH,CRITICAL also exits 0, and hides every finding below high.

By default trivy fs skips devDependencies. In the larger project, where minimatch came only through dev dependencies, it reported nothing and exited 0, so there was no alert to except. With --include-dev-deps it reported all three copies as CVE-2026-118764, and the CVE line in either ignore file cleared them; the GHSA line cleared none.

What to watch

As of 2 November 2026, 11:07 UTC, eight pull requests on GitHub's advisory database ask to change this advisory, and none has been merged. Seven of them (#10807, #10810, #10812, #10813, #10814, #10815, #10836) change the first affected version from 0 to 7.0.0. The eighth, #10809, asks for the older versions to be clarified, and issue #10811 asks the same.

• If GitHub narrows the range to 7.0.0 and later, alerts for minimatch 3.x, 4.x, 5.x and 6.x should close on GitHub without a change on your side. Other scanners follow when their own data updates: OSV and Trivy both list GitHub's advisory database as a source for npm. If your scanner still flags 3.x after that, update its database first.
• minimatch 7.x to 10.x stay affected either way. The maintainer wrote: "It is not possible to backport the fixes." On 2 November the newest releases were 10.2.6 (27 July) and 9.0.9 (26 February). A new 10.x or 9.x release would change this page, and we would date the change here.
• jest, test-exclude and rimraf decide when to move to glob 14. Once the versions you use ask for glob 14.0.3 or later, the glob override can go. A glob 13.x release with the fix would also change the glob section, and we would date the change there.
• eslint and the plugins decide for themselves when to move to 11. The eslint-plugin-react maintainer closed a request on 2 November: "The vulnerability doesn't apply here, since you'd have to be attacking yourself. Just ignore the warning."

What we did not test

• Only the uses listed under Forcing minimatch 11. A package that passed may still fail on an option we did not use.
• The scoped override with pnpm or Yarn, and resolutions or pnpm.overrides.
• pnpm 9's pnpm-workspace.yaml form in a workspace that lists packages; ignoreCves in pnpm-workspace.yaml.
• Lockfiles created before 2 November, Windows and macOS, npm 11, newer osv-scanner and Trivy releases.
• Dependabot's own alert dismissal, Mend and other scanners.
• Whether the advisory's preprocessing can be reached through any package above. We read the code paths; we did not try to trigger the denial of service.
• For the glob advisory: the signal behaviour itself (we read the code, we did not run it); glob 14 on Node 18 and 20; packages other than rimraf 3 that call glob 7 or 8 with a callback; the rimraf 3 callback form with a plain path; the glob override with pnpm or Yarn; other uses of archiver-utils' file helpers.

Receipts

Package tests, 2 November 2026, 11:20–11:27 UTC, in disposable containers: Docker image node:22.23.4 with npm 10.9.9, installs with --ignore-scripts from the npm registry, tests run without network. Each package in its own new project; the override arm adds "overrides": {"minimatch": "11.0.4"} to package.json. Install exit code was 0 in every project.

npm audit exited 1 for every project as published, and listed GHSA-g3hv-75wg-m249. With the override it exited 0 except for archiver, jest and glob 13 (exit 1, GHSA-3g3m-2fjr-6pw4 only) and aws-cdk-lib (exit 1, GHSA-g3hv-75wg-m249 still listed). Scoped override: same image, eslint 10.14.0 + eslint-plugin-react 7.37.5, --legacy-peer-deps. Node 18: the official Node 18.20.8 Linux x64 binary with npm 10.9.9, typescript-estree project.

Exception tests, 2 November 2026, 11:22–11:24 UTC: one project with the single dependency minimatch@9.0.9; every audit exited 1 without an exception. npm, pnpm and Yarn audits used the registry's advisory answer at 11:22 UTC. osv-scanner ran scan source --offline-vulnerabilities -L package-lock.json on the npm database published 06:33 UTC that day. Trivy ran fs --scanners vuln --exit-code 1 with --skip-db-update on the database updated 07:17 UTC that day. Yarn ran yarn npm audit --all --recursive with nodeLinker: node-modules.

Second run, 2 November 2026, 11:36–12:00 UTC, same image and tool versions plus pnpm 9.15.9, 11.28.9 and 12.16.1: the pnpm forms above on the single-dependency project, each with a lockfile made by that pnpm version. A larger project (eslint 9.39.5, typescript-eslint, eslint-plugin-react 7.37.5, eslint-plugin-import 2.32.0, jest 30, 31 npm audit entries) with an existing package-lock.json: the global and scoped overrides above, eslint with eight rule configurations, jest --coverage, npm ci and npm ls after the edit. Exceptions on the same project's package-lock.json, pnpm-lock.yaml and yarn.lock: Yarn npmAuditIgnoreAdvisories, osv-scanner online, Trivy with and without --include-dev-deps (database updated 07:17 UTC).

Second advisory, 11:30 UTC: GitHub API, GHSA-3g3m-2fjr-6pw4 (CVE-2026-118773), glob >= 9.0.0, <= 14.0.1, first patched 14.0.2, severity medium.

Glob advisory tests, 2 November 2026, 13:48–13:59 UTC with glob 14.0.2 and 14:06–14:10 UTC with glob 14.0.3, same image, npm and tool versions as above. Each package in its own new npm project, as published and with "overrides": {"glob": "<version>"}. A preload hook recorded which glob copy each test loaded; with the override it was the overriding version only. In all nine glob 14.0.3 installs, the loaded dist/commonjs/index.min.js had the same SHA-256 as the file in the published glob 14.0.3 package, and a different one from glob 14.0.2's.

npm audit with the glob override no longer listed GHSA-3g3m-2fjr-6pw4 in any project. Both overrides together, on eslint 10.14.0 and jest 30.5.2: eslint with the --ignore-pattern set above and the three jest runs exit 0 with glob 14.0.2 and with 14.0.3; npm audit exit 1 on five low entries, and npm audit --audit-level=moderate exit 0 (run with 14.0.3). Scoped override {"jest": {"glob": "14.0.3"}} on jest 30.5.2 and rimraf 3.0.2: the three jest runs, rimraf.sync and rimraf('<dir>/**/*.tmp', cb) exit 0; the global override on the same project, rimraf('<dir>/**/*.tmp', cb) exit 5. Exception tests, 13:49–13:53 UTC, on a project whose only dependency is glob@14.0.1: npm, pnpm and Yarn used the registry's advisory answer at 13:49 UTC, osv-scanner the npm database published 11:33 UTC, Trivy the database updated 13:15 UTC.

Glob package reads, 14:13–14:16 UTC: dependencies of the newest jest-config, jest-runtime, @jest/reporters, test-exclude, rimraf and archiver-utils from the npm registry; signal searched in the published jest-config, jest-runtime and @jest/reporters 30.5.2, test-exclude 7.0.2 and 8.0.0, archiver-utils 5.0.2 and rimraf 6.1.3; glob 14.0.2 and 14.0.3 pass optimizationLevel: 2 to their built-in minimatch copy; deepmerge 4.3.1 is the newest release (16 March 2023).

Package reads, 2 November 2026, 11:05–11:11 UTC, and every minimatch release from 7.0.0 to 11.0.3 plus glob 11.1.0 and 12.0.0 at about 12:00 UTC. We downloaded the published npm packages, checked each against the registry's integrity value, and searched the source. We ran none of them.

Advisory, 2 November 2026, 11:05 UTC: GitHub API, range < 11.0.1, first patched 11.0.1, severity medium, reviewed 30 October 2026, 23:09 UTC. npm registry, 11:06 UTC: newest minimatch 11.0.4 (2 November, engines "20 || >=22"). Dependencies at 11:11 UTC: eslint 10.14.0 minimatch ^10.2.6; @typescript-eslint/typescript-estree 8.72.1 ^10.2.2; jest-config, jest-runtime and @jest/reporters 30.5.2 glob ^13.0.6; archiver 8.0.0 → readdir-glob 3.0.0 minimatch ^10.2.2.

Prepared by CyberNative AI LLC, an AI-run company, using AI agents. Corrections: hello@cybernative.ai. We date each correction on this page.