[GHSA-3ppc-4f35-3m26] minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern#7024
Conversation
|
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 |
github-actions
bot
changed the base branch from
main
to
jacobwilliams-psycle/advisory-improvement-7024
There was a problem hiding this comment.
Pull request overview
Updates the GHSA advisory metadata for minimatch to reflect patched versions across legacy major branches.
Changes:
- Expanded the
affectedentries to list additional fixed versions (3.x–9.x). - Updated the advisory
modifiedtimestamp.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| { | ||
| "introduced": "0" | ||
| }, | ||
| { | ||
| "fixed": "9.0.6" | ||
| } | ||
| ] |
There was a problem hiding this comment.
Using "introduced": "0" for each major-line fix range makes the ranges overlap and produces incorrect semantics (e.g., if the vulnerability is “introduced at 0 and fixed in 3.1.3”, then later versions like 9.0.0 would already be considered fixed, contradicting the additional “fixed in 9.0.6” range). Model each maintained major line as a non-overlapping introduced→fixed interval (e.g., introduced 3.0.0 fixed 3.1.3, introduced 4.0.0 fixed 4.2.4, etc.), or otherwise encode explicit re-introductions if that’s truly the case.
| { | ||
| "introduced": "0" | ||
| }, | ||
| { | ||
| "fixed": "8.0.5" | ||
| } | ||
| ] |
There was a problem hiding this comment.
Using "introduced": "0" for each major-line fix range makes the ranges overlap and produces incorrect semantics (e.g., if the vulnerability is “introduced at 0 and fixed in 3.1.3”, then later versions like 9.0.0 would already be considered fixed, contradicting the additional “fixed in 9.0.6” range). Model each maintained major line as a non-overlapping introduced→fixed interval (e.g., introduced 3.0.0 fixed 3.1.3, introduced 4.0.0 fixed 4.2.4, etc.), or otherwise encode explicit re-introductions if that’s truly the case.
| { | ||
| "introduced": "0" | ||
| }, | ||
| { | ||
| "fixed": "7.4.7" | ||
| } | ||
| ] |
There was a problem hiding this comment.
Using "introduced": "0" for each major-line fix range makes the ranges overlap and produces incorrect semantics (e.g., if the vulnerability is “introduced at 0 and fixed in 3.1.3”, then later versions like 9.0.0 would already be considered fixed, contradicting the additional “fixed in 9.0.6” range). Model each maintained major line as a non-overlapping introduced→fixed interval (e.g., introduced 3.0.0 fixed 3.1.3, introduced 4.0.0 fixed 4.2.4, etc.), or otherwise encode explicit re-introductions if that’s truly the case.
| }, | ||
| { | ||
| "package": { | ||
| "ecosystem": "npm", | ||
| "name": "minimatch" | ||
| }, | ||
| "ranges": [ | ||
| { | ||
| "type": "ECOSYSTEM", | ||
| "events": [ |
There was a problem hiding this comment.
The affected array now contains multiple separate objects for the same package (npm/minimatch) with identical structure. Consider consolidating these into a single affected entry with multiple ranges to reduce duplication and make future edits less error-prone (especially since the ranges are tightly related and should be kept consistent).
|
Duplicate of #7002 (nope there is no way to see the list of open PRs when suggesting an improvement...) |
Indeed, RIP my inbox 🫠 
|
|
(To be clear, I love that everyone wants to help out, but like... OMG lol) |
4 participants
Updates
Comments
As seen in the commits for each of the legacy version, this has been patched for versions 3-9 as well as for the main version of 10.
e.g. the v5 branch contains the following commit - isaacs/minimatch@febe85d