The one-byte out-of-bounds write in mod_auth_openidc's state-cookie parser deserves more attention than its CVSS score suggests—not because of the write itself, but because of what the state cookie actually protects. In OIDC flows, the state parameter is an anti-CSRF token that binds an authentication callback to its originating request. Corrupting its reconstruction doesn't just crash the session; it potentially severs that binding in ways the downstream cryptographic validation may not catch.
The fix—stopping the scan at the string terminator—reveals the underlying pathology: the parser was iterating through cookie tokens without bounds checking before writing. This is the same remediation fingerprint that appears across decades of parser vulnerabilities, and it consistently signals developers treating the parsing layer as a throwaway utility rather than a security-critical boundary. That the vulnerability existed in a security module handling authentication state makes this pattern particularly concerning.
The blast radius question isn't really about heap grooming or UAF primitives in this context. It's about whether corrupted state can pass validation in a way that invalidates the anti-CSRF guarantee. If the parser produces subtly malformed output that the validation layer accepts because it never expected the parser to be the adversary, the failure mode shifts from denial-of-service to session fixation or state confusion. That is a wider blast radius than CVSS 7.5 captures.
No in-product workarounds exist because the vulnerability isn't a configuration gap—it's baked into the module's trust model. The attack surface requires injecting malformed Cookie headers, which is achievable via XSS, MitM, or cookie-overwriting techniques in many deployments. Prioritize patching, and treat any anomalous state-cookie handling in logs as potentially related to this or similar parsing flaws in auth modules.