[GHSA-3ppc-4f35-3m26] minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern

[daniel-mudigital]

Updates

• Affected products

Comments
specific on affected versions and patched versions

[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

[Copilot]

Pull request overview

Updates the GHSA advisory for minimatch ReDoS to more explicitly enumerate affected products/versions and patched versions.

Changes:

• Updated the advisory modified timestamp.
• Added multiple affected entries for the npm package minimatch with different fixed versions.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

These affected entries all start with introduced: \"0\" while only changing the fixed version. In OSV semantics, multiple affected records for the same package are effectively unioned; this makes the overall affected range extend up to the largest fixed version (e.g., 4.2.4, 5.1.7, etc.), which overstates impact if the vulnerability is already fixed in 3.1.3 for that line. Consider representing separate release lines with non-overlapping ranges (e.g., introduced: \"4.0.0\" -> fixed: \"4.2.4\", introduced: \"5.0.0\" -> fixed: \"5.1.7\", etc.) or combining into a single affected entry with multiple ranges/events that accurately reflect when each line became affected.

[isaacs]

Yeah, I gotta agree with the bot on this one. They should be "introduced": "4.0.0", "fixed": "4.2.4" etc.

[Copilot]

These affected entries all start with introduced: \"0\" while only changing the fixed version. In OSV semantics, multiple affected records for the same package are effectively unioned; this makes the overall affected range extend up to the largest fixed version (e.g., 4.2.4, 5.1.7, etc.), which overstates impact if the vulnerability is already fixed in 3.1.3 for that line. Consider representing separate release lines with non-overlapping ranges (e.g., introduced: \"4.0.0\" -> fixed: \"4.2.4\", introduced: \"5.0.0\" -> fixed: \"5.1.7\", etc.) or combining into a single affected entry with multiple ranges/events that accurately reflect when each line became affected.

[Copilot]

These affected entries all start with introduced: \"0\" while only changing the fixed version. In OSV semantics, multiple affected records for the same package are effectively unioned; this makes the overall affected range extend up to the largest fixed version (e.g., 4.2.4, 5.1.7, etc.), which overstates impact if the vulnerability is already fixed in 3.1.3 for that line. Consider representing separate release lines with non-overlapping ranges (e.g., introduced: \"4.0.0\" -> fixed: \"4.2.4\", introduced: \"5.0.0\" -> fixed: \"5.1.7\", etc.) or combining into a single affected entry with multiple ranges/events that accurately reflect when each line became affected.

[Copilot]

The affected array repeats identical package objects for minimatch many times, which is error-prone and hard to audit (and contributed to the overlapping-range issue above). If the schema allows, prefer a single affected entry for the package with multiple ranges (or multiple events sequences) to capture each fixed line, so the version logic is centralized and easier to review.

[Copilot]

The affected array repeats identical package objects for minimatch many times, which is error-prone and hard to audit (and contributed to the overlapping-range issue above). If the schema allows, prefer a single affected entry for the package with multiple ranges (or multiple events sequences) to capture each fixed line, so the version logic is centralized and easier to review.

[Copilot]

The affected array repeats identical package objects for minimatch many times, which is error-prone and hard to audit (and contributed to the overlapping-range issue above). If the schema allows, prefer a single affected entry for the package with multiple ranges (or multiple events sequences) to capture each fixed line, so the version logic is centralized and easier to review.

[isaacs]

Suggested change

	"introduced": "0"
	"introduced": "0.0.0"

[isaacs]

Suggested change

	"introduced": "0"
	"introduced": "4.0.0"

[isaacs]

Suggested change

	"introduced": "0"
	"introduced": "5.0.0"

[isaacs]

Suggested change

	"introduced": "0"
	"introduced": "6.0.0"

[isaacs]

Suggested change

	"introduced": "0"
	"introduced": "7.0.0"

[isaacs]

Suggested change

	"introduced": "0"
	"introduced": "8.0.0"

[isaacs]

Suggested change

	"introduced": "0"
	"introduced": "9.0.0"

[G-Rath]

Note I've already opened #7002 which has the correct ranges

[ljharb]

Duplicate of #7002. Duplicate of #7003.

[daniel-mudigital]

Let's use #7002