chore(deps): 🔗 update dependency path-to-regexp to v6.3.0 [security]

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
path-to-regexp	6.2.0 -> 6.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 to 8.0.0.

These versions add backtrack protection when a custom regex pattern is not provided:

• 0.1.10
• 1.9.0
• 3.3.0
• 6.3.0

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

• OWASP
• Detailed blog post

---

Release Notes

pillarjs/path-to-regexp (path-to-regexp)

v6.3.0: Fix backtracking in 6.x

Compare Source

Fixed

• Add backtrack protection to 6.x (#​324) f1253b4

v6.2.2: Updated README

Compare Source

No API changes. Documentation only release.

Changed

• Fix readme example c7ec332
• Update shield URL e828000

v6.2.1: Fix matching :name* parameter

Compare Source

Fixed

• Fix invalid matching of :name* parameter (#​261) 762bc6b
• Compare delimiter string over regexp 86baef8

Added

• New example in documentation (#​256) ae9e576
• Update demo link (#​250) 77df638
• Update README encode example b39edd4

---

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: Never, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[kopach]

ref:

• https://github.com/brainly/gene/security/dependabot/5
• https://github.com/brainly/gene/security/dependabot/36
• https://github.com/brainly/gene/security/dependabot/41