[email protected]

[blakeembrey]

Use latest release.

[wesleytodd]

Can we just get an unreleased section on the history file?

[alexporto2200]

path-to-regexp <0.1.10
Severity: high
path-to-regexp outputs backtracking regular expressions - GHSA-9wv6-86v2-598j
fix available via npm audit fix --force
Will install [email protected], which is a breaking change
node_modules/path-to-regexp
express 4.0.0-rc1 - 5.0.0-alpha.6
Depends on vulnerable versions of path-to-regexp
node_modules/express

2 high severity vulnerabilities

[omerlh]

Looking at Snyk https://security.snyk.io/package/npm/path-to-regexp everything bellow version 8 is vulnerable... are there plans to upgrade to latest version?

[corneliusroemer]

@omerlh snyk is wrong. The original advisory is here: GHSA-9wv6-86v2-598j

[lirantal]

@corneliusroemer the Snyk team updated the security advisory with the following note that adds context:

Note: Version 0.1.10 is patched to mitigate this but is also vulnerable if custom regular expressions are used. Due to the existence of this bypass, the Snyk security team have decided to err on the side of caution in considering the very widely-used v0 branch vulnerable, while the 8.0.0 release has completely eliminated the vulnerable functionality.

Is this helpful, or is there anything else you consider important to add?

[corneliusroemer]

I reported the error to them some 10 hours ago 😀 they fixed it afterwards it seems 🙈

Oh you're at snyk, great! I don't know much about this vuln, I just reported wrong snyk info to snyk :)

I missed the full comment, here it is as a quote with line breaks:

Note: Version 0.1.10 is patched to mitigate this but is also vulnerable if custom regular expressions are used. Due to the existence of this bypass, the Snyk security team have decided to err on the side of caution in considering the very widely-used v0 branch vulnerable, while the 8.0.0 release has completely eliminated the vulnerable functionality.

[ctcpip]

@lirantal path-to-regexp is not a sanitization library. Users can provide regular expressions directly, for which they are responsible for not introducing evil regular expressions. This is true when they pass only a regular expression, and it is true when they pass a regular expression as a component/sub-expression of the string. That's not a "bypass". That's the user deliberately providing a regular expression.