[GHSA-3ppc-4f35-3m26] minimatch has a ReDoS via repeated wildcards with non-matching literal in pattern#7044
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 |
| } | ||
| ], | ||
| "database_specific": { | ||
| "last_known_affected_version_range": "< 3.1.2" |
There was a problem hiding this comment.
...I have no idea why this is only here for the 3.* line but there is no similar thing for any of the other lines. I would guess the other lines need an equivalent of this, and maybe the Github wizard I was manipulating didn't work right when I filed the bug? 🤷
|
Never mind, found #7002 |
Updates
Comments
I should preface this all by saying I am an only slightly interested downstream consumer of these and not a modulo aficionado so take these suggestions as at least somewhat uncertain!
The 10.* line has a fix in it, but this seems to still treat prior major-version lines' fixes as inadequate to the day. I am entirely unsure whether the backported fixes are solving the entire problem, or only part of it. But if we presume the backported fixes are "enough" of a solution -- I stress again that I do not entirely know whether this is the case! -- then the newer releases within those lines ought be permitted to resolve a dependabot security alert.
minimatch 1.0.1:
minimatch 2.0.11:
minimatch 3.1.3:
minimatch 4.2.4:
minimatch 5.1.7:
minimatch 6.2.1:
minimatch 7.4.7:
minimatch 8.0.5:
minimatch 9.0.6: