apply backtrack protection to version 6.x because of @koa/router

[rlsf]

koajs/router#186

[mass8326]

withastro/astro#11956

[paulo9mv]

Also msw: mswjs/msw#2277

[blakeembrey]

I've applied a patch here: https://github.com/pillarjs/path-to-regexp/releases/tag/v6.3.0. I think someone will need to update the public advisory. There's a possibility this breaks expectations in some edge cases, but typical route usage should see minimal changes (excepting the first param now appearing greedy, e.g. /:foo.:bar against /x.y.z changes from x and y.z to x.y and z).

[mschfh]

I think someone will need to update the public advisory.

@blakeembrey Thanks for the fix, the advisory should be editable for repo admins:
https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/editing-a-repository-security-advisory

[samchungy]

I submitted a ticket to address the snyk one.

[blakeembrey]

@mschfh I believe I already follow that workflow, but it only patches the one in the repo and not the global one.

This one I've updated in the repo: GHSA-9wv6-86v2-598j

This is the global one: GHSA-9wv6-86v2-598j

I was under the impression they synced up somehow.

Edit: Thanks for opening github/advisory-database#4791 (comment).

[markmssd]

Interesting, Snyk did update their page (https://security.snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106), but the issue is still present for <8.0.0, with a note stating:

Note: Versions 0.1.10, 1.9.0, 3.3.0, and 6.3.0 are patched to mitigate this but are still vulnerable if custom regular expressions are used. Due to the existence of this attack vector, the Snyk security team have decided to err on the side of caution in considering prior versions vulnerable, while the 8.0.0 release has completely eliminated the vulnerable functionality.

Can something be done to fully fix the issue on those previous versions? 🤞🏼

Edit: Okay Snyk got updated too now: https://security.snyk.io/vuln/SNYK-JS-PATHTOREGEXP-7925106 🎉

How to fix?
Upgrade path-to-regexp to version 0.1.10, 1.9.0, 3.3.0, 6.3.0, 8.0.0 or higher.

[blakeembrey]

Can something be done to fully fix the issue on those previous versions?

It's not really possible, it is true that as long as anyone can specify a regular expression it may be vulnerable if you wrote a bad regular expression. It might be possible to write an regex parser to use a safe subset but that isn't something I have time for right now, and won't implement for older versions.