Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Within the URI template implementation in Addressable, two classes of URI template generate regular expressions vulnerable to catastrophic backtracking: 1. Templates using the (explode) modifier with any expansion operator (e.g., {foo}, {+var}, {#var}, {/var}, {.var}, {;var}, {?var}, {&var}) generate patterns with nested unbounded quantifiers that are O(2^n) when matched against a maliciously crafted URI. 2. Templates using multiple variables with the + or operators (e.g., {+v1,v2,v3}) generate patterns with O(n^k) complexity due to the comma separator being within the matched character class, causing ambiguous backtracking across k variables. When matched against a maliciously crafted URI, this can result in catastrophic backtracking and uncontrolled resource consumption, leading to denial of service. The first pattern was partially addressed in 2.8.10 for certain operator combinations. Both patterns are fully remediated in 2.9.0. Users of the URI parsing capabilities in…
Recommended action: Upgrade to 2.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Within the URI template implementation in Addressable, a maliciously crafted template may result in uncontrolled resource consumption, leading to denial of service when matched against a URI. In typical usage, templates would not normally be read from untrusted user input, but nonetheless, no previous security advisory for Addressable has cautioned against doing this. Users of the parsing capabilities in Addressable but not the URI template capabilities are unaffected. Patches The vulnerability was introduced in version 2.3.0 (previously yanked) and has been present in all subsequent versions up to, and including, 2.7.0. It is fixed in version 2.8.0. Workarounds The vulnerability can be avoided by only creating Template objects from trusted sources that have been validated not to produce catastrophic backtracking. References - https://owasp.org/www-community/attacks/RegularexpressionDenialofService-ReDoS - https://cwe.mitre.org/data/definitions/1333.html -…
Recommended action: Upgrade to 2.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.