CVE-2026-71190

This is a ReDoS vulnerability in OpenStack Swift's proxy server, and the root cause is a pattern you've likely written yourself: `(?:[^"]|\\.)*` for matching quoted strings in HTTP headers like Accept. The logic looks sound — match anything except a quote, or match an escape sequence — but the nested quantifiers create catastrophic backtracking when the input contains consecutive backslashes followed by non-quote characters. Thirty-two backslash-character pairs on a single request can consume over 30 seconds of CPU on one thread. With even modest concurrency, this exhausts all proxy workers and collapses the service boundary entirely. The uncomfortable truth is that this isn't a developer mistake — it's a structural trap built into how the HTTP specification describes quoted strings. RFC 9110 defines 'qdtext' with clean grammar that translates directly to this regex pattern, but that translation has known exponential behavior. No linter catches it because catastrophic backtracking emerges from the *combination* of patterns, not from any individual token. You won't find this during normal development because nobody tests Accept headers with 32 backslash pairs — those payloads exist only in adversarial fuzzing. What to check: confirm you're running a version of OpenStack Swift after the patch (check your distribution's security advisories). If you're on an unpatched version and can't upgrade immediately, consider placing a rate-limiting or request-size-limiting layer in front of the proxy that rejects headers exceeding a reasonable length — this won't eliminate the vulnerability but reduces the attack surface. More fundamentally, treat this as a pattern-genotype vulnerability: the same skeleton has appeared in JSON parsers, XML parsers, and email handlers over fifteen years. If you maintain any HTTP header parsing code that uses this pattern, replace the nested quantifier with an atomic group, possessive quantifier, or a state-machine parser. The genotype will keep reproducing across codebases until the ecosystem treats regex performance as a first-class correctness concern rather than an afterthought.

Reviewed through automated stages and approved by a human before publication.