renovate[bot]
commented
2 months ago ⚠️ 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.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21609
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.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21609:11)
at async fetchAsJson (/opt/containerbase/tools/corepack/0.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21623:20)
... 4 lines matching cause stack trace ...
at async Object.runMain (/opt/containerbase/tools/corepack/0.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:23096:5) {
[cause]: TypeError: globalThis.fetch is not a function
at fetch (/opt/containerbase/tools/corepack/0.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21603:33)
at async fetchAsJson (/opt/containerbase/tools/corepack/0.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21623:20)
at async fetchLatestStableVersion (/opt/containerbase/tools/corepack/0.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21550:20)
at async fetchLatestStableVersion2 (/opt/containerbase/tools/corepack/0.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:21672:14)
at async Engine.getDefaultVersion (/opt/containerbase/tools/corepack/0.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:22292:23)
at async Engine.executePackageManagerRequest (/opt/containerbase/tools/corepack/0.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:22390:47)
at async Object.runMain (/opt/containerbase/tools/corepack/0.29.4/16.20.2/node_modules/corepack/dist/lib/corepack.cjs:23096:5)
}
vercel[bot]
changeset-bot[bot]
This PR contains the following updates:
6.2.1->6.3.0GitHub 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: trueand 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-:bto/: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-:bwill 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/aat the end ensures this route would never match but due to naive backtracking it will still attempt every combination of the:a-:bon 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)
### [`v6.3.0`](https://redirect.github.com/pillarjs/path-to-regexp/releases/tag/v6.3.0): Fix backtracking in 6.x [Compare Source](https://redirect.github.com/pillarjs/path-to-regexp/compare/v6.2.2...v6.3.0) **Fixed** - Add backtrack protection to 6.x ([#324](https://redirect.github.com/pillarjs/path-to-regexp/issues/324)) [`f1253b4`](https://redirect.github.com/pillarjs/path-to-regexp/commit/f1253b4) ### [`v6.2.2`](https://redirect.github.com/pillarjs/path-to-regexp/releases/tag/v6.2.2): Updated README [Compare Source](https://redirect.github.com/pillarjs/path-to-regexp/compare/v6.2.1...v6.2.2) No API changes. Documentation only release. **Changed** - Fix readme example [`c7ec332`](https://redirect.github.com/pillarjs/path-to-regexp/commit/c7ec332) - Update shield URL [`e828000`](https://redirect.github.com/pillarjs/path-to-regexp/commit/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.
This PR was generated by Mend Renovate. View the repository job log.