kin-openapi CVE-2026-100351

Exploitation requires a precise stack: kin-openapi from 0.144.0 up to (not including) 0.147.0, openapi3filter.ValidationHandler wired as authentication middleware, AND a downstream gorilla/mux router configured with UseEncodedPath, AND a public exact route plus a protected parameterized route that use the same HTTP method and overlap after URL-decoding (e.g. GET /public/status vs GET /{id}). The attacker triggers it with an encoded path separator (%2F) so the decoded path matches the public operation while the raw encoded path routes to the protected handler. Limiting factors that reduce real-world risk: the reachable path parameter is constrained to an encoded representation that decodes to the public literal route (so arbitrary protected resources are not freely addressable), and any upstream proxy that canonicalizes/normalizes the URI before forwarding neutralizes the mismatch entirely.

Signals are mixed and point to a real-but-constrained issue rather than a drop-everything emergency. The CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N, base 7.4 High) shows a network-reachable, unauthenticated flaw (PR:N) with high confidentiality and integrity impact, but AC:H explicitly encodes that exploitation is not straightforward - it depends on a specific routing topology. No EPSS score, no CISA KEV listing, and no SSVC decision data were provided, so automatable/exploitation-maturity cannot be assessed from the input. No standalone public exploit is referenced, though the fix commit itself ships a regression test (TestEncodedPathAuthorizationBypass) that fully demonstrates the bypass, meaning a working technique is effectively public even if not packaged as a weapon. The decisive limiter is in the description: the reachable path parameter is constrained to an encoded value that decodes to the public literal route (the test shows the protected handler receiving an empty id), so an attacker cannot freely address arbitrary protected resources - this materially narrows real-world impact below what C:H/I:H alone suggests. Net: a legitimate authentication-bypass bug worth patching for anyone running the affected kin-openapi versions behind gorilla/mux with UseEncodedPath, but absent KEV/EPSS evidence and given AC:H plus the parameter constraint, it reads as a targeted/conditional issue rather than a mass-exploitation threat.

An application uses kin-openapi 0.144.0-0.146.x openapi3filter.ValidationHandler (with AuthenticationFunc) as auth middleware in front of a gorilla/mux router configured with UseEncodedPath, exposing a public GET /public/status and a protected parameterized GET /{id}. An unauthenticated attacker sends GET /public%2Fstatus; the validator decodes the path, matches the public operation and skips AuthenticationFunc, while mux dispatches the raw encoded path to the protected /{id} handler. No standalone public exploit is referenced, but the vendor's fix commit includes a regression test that reproduces the bypass end to end; AC:H reflects that the target must use this specific overlapping-route configuration.