fix(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.1 -> 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

---

Configuration

📅 Schedule: Branch creation - "" (UTC), Automerge - At any time (no schedule defined).

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, 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.

[renovate]

⚠️ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: yarn.lock

/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21616
    throw new Error(
          ^

Error: Error when performing the request to https://registry.npmjs.org/yarn/latest; for troubleshooting help, see https://github.com/nodejs/corepack#troubleshooting
    at fetch (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21616:11)
    at async fetchAsJson (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21630:20)
    ... 4 lines matching cause stack trace ...
    at async Object.runMain (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:23110:7) {
  [cause]: TypeError: globalThis.fetch is not a function
      at fetch (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21610:33)
      at async fetchAsJson (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21630:20)
      at async fetchLatestStableVersion (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21557:20)
      at async fetchLatestStableVersion2 (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21679:14)
      at async Engine.getDefaultVersion (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:22305:23)
      at async Engine.executePackageManagerRequest (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:22403:47)
      at async Object.runMain (/opt/containerbase/tools/corepack/0.31.0/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:23110:7)
}

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-hackernews	❌ Failed (Inspect)			Sep 11, 2024 6:19pm

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8833969

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR