path-to-regexp@0.1.10

[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 express@3.21.2, 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.

[lirantal]

@ctcpip I don't completely disagree. There's a subtlety and nuances matter. A related analogy might be vm2 which allows code execution sandbox but failed multiple times to properly isolate it from code injection payloads. It ultimately comes down to the scope of responsibility the path-to-regexp library claims. If the library says "I just provide the functionality, you provide the regex, which could result in denial of service and it is the you (consumer) responsibility to safeguard it" then my personal opinion (not Snyk) is that I agree there's no viable CVE.

@blakeembrey Regardless, on the approach and CVE or not, it is probably a good practice to put a security disclaimer in the README if you feel there are some "gotchas" or security related insights you want to let consumers know about.

[wesleytodd]

It ultimately comes down to the scope of responsibility the path-to-regexp library claims. If the library says "I just provide the functionality, you provide the regex, which could result in denial of service and it is the you (consumer) responsibility to safeguard it" then my personal opinion (not Snyk) is that I agree there's no viable CVE.

This is what we are saying. We do not consider a user writing an unsafe regular expression in their application code and passing it into express or path-to-regexp to be part of our threat model. I agree adding more warning language is a great next step.

If we do this, would Snyk be willing to change their versions to match the ones we list in the CVE?

[lirantal]

I've shared the context of the thread here with the Snyk analysts team so it's for them to triage and follow-up.

p.s. Wes, while the thread here is on expressjs/express, the actual package in question is path-to-regexp which is maintained by Blake, or are you part of that project too? asking as it would help the Snyk team to figure out how/who to include in a discussion for this if this is brought up.

[wesleytodd]

p.s. Wes, while the thread here is on expressjs/express, the actual package in question is path-to-regexp which is maintained by Blake, or are you part of that project too? asking as it would help the Snyk team to figure out how/who to include in a discussion for this if this is brought up.

The Express project has governance over the packages in three GH orgs: expressjs, pillarjs, & jshttp. So yes, @blakeembrey is the author, Project Captain, and primary owner of path-to-regexp, but we also have a security triage and working group as well as some level of input from the @expressjs/express-tc members when it helps or directly effects the experience which users of express would have.

I will leave it up to @blakeembrey for how we would like to proceed, but from my side I would be happy if we included at least a few folks like @ctcpip & @UlisesGascon (and myself if I would add value) who have been helping drive our security initiatives.

[lirantal]

Ok, that's excellent. I've shared the thread with the team so when/how they follow-up they get the info. Appreciate the context Wes ❤️