Ring CVE-2026-62864

Exploitation requires the application to route requests through the wrap-nested-params middleware in the ring.middleware.nested-params namespace; this parsing path is enabled by default for Ring-Defaults users, so those deployments are exposed out of the box. Applications that do not include nested-params do not expose this path and are not affected - this is the primary limiting factor. No authentication is required (PR:N) and no user interaction is needed (UI:N); the attacker simply supplies a malicious parameter name (e.g., a long sequence of '[' characters) in the query string or request body. Realistic impact is further bounded by any request-size or parameter-length limits the deployment enforces, since the cost is quadratic in the attacker-controlled input length rather than exponential.

The NVD CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, base 7.5) is internally consistent for a remotely reachable, unauthenticated, availability-only ReDoS, and matches the CWE-1333 classification and the GHSA advisory. However, the practical risk is more moderate than the 7.5 suggests for three reasons. First, the vuln.today decision label is 'this_week', not act_now/emergency, indicating a plan-and-patch priority rather than drop-everything urgency. Second, no CISA KEV listing is present, so exploitation status is 'no public exploit identified at time of analysis' (the fix commit ships a regression test that publicly discloses the triggering input pattern, but that is a test, not packaged exploit code). Third, the flaw is quadratic O(n^2), not exponential catastrophic backtracking, so per-request CPU cost scales with attacker-supplied input size and is bounded by any request/parameter size limits the deployment enforces. EPSS is not provided in the input, so probabilistic exploitation likelihood cannot be weighed here; its absence should not be read as low risk. No SSVC fields were supplied. The one conflicting signal worth flagging: the vector asserts AV:N/PR:N (broadly exploitable) but real exposure is gated on the nested-params middleware actually being in the request path - true by default for Ring-Defaults users, false for apps that omit it. Net: a legitimate availability issue worth patching this week, not a critical RCE-class emergency.

An unauthenticated attacker sends a single HTTP request to a Ring-based web application whose parameter name (in the URL query string or form/body) is a long crafted string such as a large run of '[' characters. The wrap-nested-params middleware feeds that name into a backtracking regular expression that degrades to O(n^2), consuming disproportionate CPU per request and, with repeated or sufficiently large requests, degrading or denying service. No authentication or user interaction is required; the fix commit publishes a regression test demonstrating the triggering input, though no packaged weaponized exploit is cited in the input.