chore(deps): update dependency path-to-regexp to v1 [security]

[thomhurst]

This PR contains the following updates:

Package	Type	Update	Change
path-to-regexp	resolutions	major	0.2.5 → 1.9.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)

v1.9.0: Fix backtracking in 1.x

Compare Source

Fixed

• Add backtrack protection to 1.x release (#​320) 925ac8e
• Fix re.exec(&#​39;/test/route&#​39;) result (#​267) 32a14b0

v1.8.0: Backport token to function options

Compare Source

Added

• Backport TokensToFunctionOptions

v1.7.0

Compare Source

• Allow a delimiter option to be passed in with tokensToRegExp which will be used for "non-ending" token match situations

v1.6.0

Compare Source

• Populate RegExp.keys when using the tokensToRegExp method (making it consistent with the main export)
• Allow a delimiter option to be passed in with parse
• Updated TypeScript definition with Keys and Options updated

v1.5.3

Compare Source

• Add \\ to the ignore character group to avoid backtracking on mismatched parens

v1.5.2

Compare Source

• Escape \\ in string segments of regexp

v1.5.1

Compare Source

• Add index.d.ts to NPM package

v1.5.0

Compare Source

• Handle partial token segments (better)
• Allow compile to handle asterisk token segments

v1.4.0

Compare Source

• Handle RegExp unions in path matching groups

v1.3.0

Compare Source

• Clarify README language and named parameter token support
• Support advanced Closure Compiler with type annotations
• Add pretty paths options to compiled function output
• Add TypeScript definition to project
• Improved prefix handling with non-complete segment parameters (E.g. /:foo?-bar)

v1.2.1

Compare Source

• Encode values before validation with path compilation function
• More examples of using compilation in README

v1.2.0

Compare Source

• Add support for matching an asterisk (*) as an unnamed match everything group ((.*))

v1.1.1

Compare Source

• Expose methods for working with path tokens

v1.1.0

Compare Source

• Expose the parser implementation to consumers
• Implement a compiler function to generate valid strings
• Huge refactor of tests to be more DRY and cover new parse and compile functions
• Use chai in tests
• Add .editorconfig

v1.0.3

Compare Source

• Optimised function runtime
• Added files to package.json

v1.0.2

Compare Source

• Use Array.isArray shim
• Remove ES5 incompatible code
• Fixed repository path
• Added new readme badges

v1.0.1

Compare Source

• Ensure installation works correctly on 0.8

v1.0.0

Compare Source

• No more API changes

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • ""
• 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 has been generated by Renovate Bot.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{TIP This summary will be updated as you push new changes. Give us feedback}

[claude]

Code Review: Dependency Security Update — path-to-regexp 0.2.5 → 1.9.0

This is a Renovate-generated security PR updating the express/path-to-regexp resolution in docs/package.json to address CVE-2024-45296 (ReDoS vulnerability).

What the change does

Pins the scoped Yarn resolution express/path-to-regexp from 0.2.5 to 1.9.0. The 1.9.0 release adds backtrack protection that prevents the catastrophic backtracking regex case (e.g. /:a-:b pattern with a crafted long input).

Assessment: Safe to merge ✓

The lockfile diff is correct and internally consistent. The deduplication of the ^1.7.0 and pinned 1.9.0 entries into a single lockfile entry is expected Yarn behaviour. The 0.1.13 entry (used by other packages) remains unchanged and is already patched.

Minor observations (non-blocking)

1. Scoped resolution may not be active — The key express/path-to-regexp only overrides path-to-regexp when Express itself is a dependent. In a Docusaurus docs site that doesn't directly depend on Express, this resolution may be a no-op. It's harmless, but if Express is not in the actual dependency tree, a future cleanup could remove the key entirely.

2. Major version jump — 0.2.x → 1.9.0 is a major bump with some API differences (key population, strict/end option behaviour). In the context of a Yarn resolution override (the consuming code lives inside Express/other packages), this is low risk, but worth confirming the docs build still passes CI.

3. CVE advisory recommends 8.0.0 — The advisory's preferred long-term path is 8.x, which removes the vulnerable feature entirely. 1.9.0 applies a backtrack guard but doesn't remove the problematic capture-group feature. For a static docs site this residual risk is negligible, and staying on 1.x avoids breaking downstream API consumers — a pragmatic tradeoff.

Bottom line

This is a correct, low-risk security remediation appropriate for a documentation site. No application logic is affected. Good to merge.

[claude]

Security Dependency Update Review

This PR updates the resolution in from to to address CVE-2024-45296 (ReDoS vulnerability).

Summary

The change is correct and appropriate. The vulnerability allows a crafted URL path to trigger catastrophic backtracking in generated regular expressions when two parameters appear in a single path segment (e.g., /:a-:b), potentially causing a Denial of Service in JavaScript-based routing.

What looks good

• The fix targets the right package and bumps to a patched version (1.9.0 is listed as a safe version for the 1.x series).
• The yarn.lock consolidation is clean: the separate path-to-regexp@0.2.5 entry is removed and the ^1.7.0 range and 1.9.0 pin are merged into a single resolved entry, reducing lock file duplication.
• The path-to-regexp@3.3.0 entry (used by other dependents) is left untouched since it was already a separately patched version.

One observation worth noting

The security advisory recommends upgrading to 8.0.0 as the most complete fix (it removes the problematic features entirely), while 1.9.0 adds backtrack protection but still retains legacy behavior. However, since this dependency lives under docs/ (the documentation site, not the core .NET test framework), the attack surface is limited to the docs build/serve tooling rather than production runtime code. Jumping to a major version like 8.x would require API migration work and is likely not worth the effort for a docs-only dependency. The 1.9.0 choice is pragmatic and appropriate for this context.

Verdict

Good to merge. The fix addresses the CVE without introducing unnecessary churn.

[claude]

Security Dependency Update Review

This PR updates the path-to-regexp resolution in docs/package.json from 0.2.5 to 1.9.0 to address CVE-2024-45296 (ReDoS vulnerability).

Summary

The change is correct and appropriate. The vulnerability allows a crafted URL path to trigger catastrophic backtracking in generated regular expressions when two parameters appear in a single path segment (e.g., /:a-:b), potentially causing a Denial of Service in JavaScript-based routing.

What looks good

• The fix targets the right package and bumps to a patched version (1.9.0 is listed as a safe version for the 1.x series).
• The yarn.lock consolidation is clean: the separate path-to-regexp@0.2.5 entry is removed and the ^1.7.0 range and 1.9.0 pin are merged into a single resolved entry, reducing lock file duplication.
• The path-to-regexp@3.3.0 entry (used by other dependents) is left untouched since it was already a separately patched version.

One observation worth noting

The security advisory recommends upgrading to 8.0.0 as the most complete fix (it removes the problematic features entirely), while 1.9.0 adds backtrack protection but still retains legacy behavior. However, since this dependency lives under docs/ (the documentation site, not the core .NET test framework), the attack surface is limited to the docs build/serve tooling rather than production runtime code. Jumping to a major version like 8.x would require API migration work and is likely not worth the effort for a docs-only dependency. The 1.9.0 choice is pragmatic and appropriate for this context.

Verdict

Good to merge. The fix addresses the CVE without introducing unnecessary churn.

[claude]

Security Dependency Update Review

This PR updates the path-to-regexp resolution in docs/package.json from 0.2.5 to 1.9.0 to address CVE-2024-45296 (ReDoS vulnerability).

Summary

The change is correct and appropriate. The vulnerability allows a crafted URL path to trigger catastrophic backtracking in generated regular expressions when two parameters appear in a single path segment (e.g., /:a-:b), potentially causing a Denial of Service in JavaScript-based routing.

What looks good

• The fix targets the right package and bumps to a patched version (1.9.0 is listed as a safe version for the 1.x series).
• The yarn.lock consolidation is clean: the separate path-to-regexp@0.2.5 entry is removed and the ^1.7.0 range and 1.9.0 pin are merged into a single resolved entry, reducing lock file duplication.
• The path-to-regexp@3.3.0 entry (used by other dependents) is left untouched since it was already a separately patched version.

One observation worth noting

The security advisory recommends upgrading to 8.0.0 as the most complete fix (it removes the problematic features entirely), while 1.9.0 adds backtrack protection but still retains legacy behavior. However, since this dependency lives under docs/ (the documentation site, not the core .NET test framework), the attack surface is limited to the docs build/serve tooling rather than production runtime code. Jumping to a major version like 8.x would require API migration work and is likely not worth the effort for a docs-only dependency. The 1.9.0 choice is pragmatic and appropriate for this context.

Verdict

Good to merge. The fix addresses the CVE without introducing unnecessary churn.

[claude]

Code Review

This is a security patch PR generated by Renovate Bot, upgrading path-to-regexp from 0.2.5 to 1.9.0 to address CVE-2024-45296 (ReDoS vulnerability).

Summary

The change is limited to the docs/ directory tooling — it does not touch the core .NET TUnit library at all. The risk surface here is low (would require malicious requests to the docs server), but patching known CVEs is still good hygiene.

Changes Look Correct

• docs/package.json: The resolutions override for express/path-to-regexp is bumped from 0.2.5 → 1.9.0. Using a Yarn resolution override is the right approach here since express itself depends on this transitively.
• docs/yarn.lock: The old path-to-regexp@0.2.5 entry is removed and path-to-regexp@^1.7.0 now resolves to 1.9.0 (which includes the backtrack protection fix). The path-to-regexp@3.3.0 entry is retained unchanged — just reordered alphabetically, which is expected lockfile churn.

One Minor Note

The CVE advisory recommends upgrading to 8.0.0 for the most complete fix (version 8.x removes the problematic features entirely), while 1.9.0 adds backtrack protection as a patch to the 1.x line. For a resolutions override of a transitive express dependency, jumping to 8.0.0 could cause breaking API changes if express actually calls path-to-regexp APIs that were removed in v8. 1.9.0 is the appropriate conservative choice here — it resolves the vulnerability without risking runtime breakage in the docs toolchain.

Verdict

The change is correct, minimal, and addresses the reported vulnerability appropriately. Looks good to merge.

[claude]

Security patch for CVE-2024-45296 (ReDoS in path-to-regexp). Change is correct, scoped to docs tooling only, and uses an appropriate conservative version bump. Looks good to merge.

[claude]

Code Review (follow-up)

This PR has already received thorough reviews and an approval from prior runs. No new changes have been introduced since the last review. The previous analysis stands:

• The resolution bump from → correctly addresses CVE-2024-45296 (ReDoS).
• The yarn.lock changes are clean and internally consistent.
• Scope is limited to tooling — no impact on the core .NET TUnit library.
• is the appropriate conservative choice for a transitive dependency resolution override (avoids API breakage that could introduce).

No new issues found. Good to merge.