fix(deps): update dependency path-to-regexp to v3.3.0 [security] #3071
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
3.2.0
->3.3.0
GitHub Vulnerability Alerts
CVE-2024-45296
Impact
A bad regular expression is generated any time you have two parameters within a single segment, separated by something that is not a period (
.
). For example,/:a-:b
.Patches
For users of 0.1, upgrade to
0.1.10
. All other users should upgrade to8.0.0
.These versions add backtrack protection when a custom regex pattern is not provided:
They do not protect against vulnerable user supplied capture groups. Protecting against explicit user patterns is out of scope for old versions and not considered a vulnerability.
Version 7.1.0 can enable
strict: true
and get an error when the regular expression might be bad.Version 8.0.0 removes the features that can cause a ReDoS.
Workarounds
All versions can be patched by providing a custom regular expression for parameters after the first in a single segment. As long as the custom regular expression does not match the text before the parameter, you will be safe. For example, change
/:a-:b
to/:a-:b([^-/]+)
.If paths cannot be rewritten and versions cannot be upgraded, another alternative is to limit the URL length. For example, halving the attack string improves performance by 4x faster.
Details
Using
/:a-:b
will produce the regular expression/^\/([^\/]+?)-([^\/]+?)\/?$/
. This can be exploited by a path such as/a${'-a'.repeat(8_000)}/a
. OWASP has a good example of why this occurs, but the TL;DR is the/a
at the end ensures this route would never match but due to naive backtracking it will still attempt every combination of the:a-:b
on the repeated 8,000-a
.Because JavaScript is single threaded and regex matching runs on the main thread, poor performance will block the event loop and can lead to a DoS. In local benchmarks, exploiting the unsafe regex will result in performance that is over 1000x worse than the safe regex. In a more realistic environment using Express v4 and 10 concurrent connections, this translated to average latency of ~600ms vs 1ms.
References
Release Notes
pillarjs/path-to-regexp (path-to-regexp)
v3.3.0
: Add backtracking protectionCompare Source
Fixed
d31670a
Configuration
📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.