100351: High-Severity Auth Bypass in Go OpenAPI Library Exposes Protected Handlers
A high-severity flaw in kin-openapi allows unauthenticated users to bypass security checks by manipulating URL encoding, affecting versions prior to the recent patch.

Key points
- CVE-2026-100351 affects kin-openapi versions 0.144.0 through 0.146.0.
- The vulnerability allows bypassing authentication callbacks via encoded path manipulation.
- Version 0.147.0 patches the issue for Go applications using the library.
A high-severity authentication bypass in the Go library kin-openapi allows unauthenticated remote requesters to access protected handlers. The flaw, tracked as CVE-2026-100351, impacts versions 0.144.0, 0.145.0, and 0.146.0. Applications using the `ValidationHandler.Middleware` with specific downstream routers are exposed to this risk. The vulnerability stems from a mismatch in how URL paths are processed during validation versus dispatch.
How does the authentication bypass work?
The vulnerability occurs when an application uses `openapi3filter.ValidationHandler.Middleware` as its security gate. This middleware validates requests using kin-openapi’s legacy router, which selects an OpenAPI operation based on the decoded `URL.Path`. However, if the downstream router, such as gorilla/mux configured with `UseEncodedPath()`, selects its handler from the encoded `URL.RawPath`, a discrepancy arises. This difference allows an attacker to manipulate the path encoding to bypass security checks.
An unauthenticated request like `/public%2Fstatus` can be validated as an intentionally public operation (`/public/status`). Despite this validation, the downstream router dispatches the request to a protected operation, such as `/{id}`. Because the validation passed against the public path, the configured `AuthenticationFunc` that rejects missing credentials is never invoked. Consequently, the protected downstream handler runs without proper authentication, granting unauthorized access.
Which versions are affected and patched?
The confirmed affected releases are v0.144.0, v0.145.0, and v0.146.0. The reporter attested that each listed release was checked out separately, and a single-file test copied into `openapi3filter/` passed for each. This confirms the vulnerability is reproducible in these specific versions. The confirmed affected development revision is `d33e44e67734dcde81b576582185e1343fb3985d`. Earlier releases were not tested, so the introduction boundary remains unknown.
Version v0.143.0 also reproduces this mechanism, but it is already covered by a simpler bypass under GHSA-r277-6w6q-xmqw. The distinct post-fix claim for this specific encoding issue starts at v0.144.0. The patched version is 0.147.0. Applications using versions greater than or equal to 0.144.0 and less than 0.147.0 are vulnerable. Users should verify their dependency versions to ensure they are not within this affected range.
What are the conditions for exploitation?
An unauthenticated remote requester can reach a handler whose OpenAPI operation requires authentication only when specific conditions are met. First, the application must use `ValidationHandler.Middleware` as its security gate. Second, the downstream router must preserve and interpret an encoded path. For example, gorilla/mux with `UseEncodedPath()` exhibits this behavior. If these conditions are not present, the vulnerability may not be exploitable.
This issue is distinct from GHSA-r277-6w6q-xmqw. The behavior here uses an explicit authentication callback that rejects missing credentials. It remains reproducible after the v0.144.0 fix for the unsafe default callback. This means that even if teams addressed the previous issue, they may still be vulnerable to this new encoding-based bypass. Understanding this distinction is crucial for accurate risk assessment and remediation efforts.
What should teams do next?
Teams should immediately check their Go projects for dependencies on kin-openapi. If the version is between 0.144.0 and 0.146.0, they are vulnerable. Updating to version 0.147.0 or later resolves the issue. For teams unable to update immediately, they should review their router configurations. Disabling `UseEncodedPath()` in gorilla/mux or similar routers may mitigate the risk by aligning path interpretation between validation and dispatch. Monitoring logs for unusual access patterns to protected endpoints is also advisable.
Detection notes
Teams usually detect this type of path-based bypass by reviewing access logs for successful requests to protected endpoints that lack valid authentication tokens. Look for requests with URL-encoded characters like `%2F` in the path segment that map to public operations in the OpenAPI spec but hit private handlers. Check web application firewall logs for anomalies in path normalization. Initial containment involves blocking suspicious encoded paths at the network edge or temporarily disabling the affected middleware if possible.
What to do and how to stay safe: kin-openapi
- Audit your Go dependencies to identify if kin-openapi version 0.144.0, 0.145.0, or 0.146.0 is in use.
- Update kin-openapi to version 0.147.0 or later to apply the vendor-provided patch.
- Review router configurations to ensure path encoding does not bypass authentication middleware.
- Monitor server logs for unauthorized access attempts to protected endpoints using encoded paths.
Step-by-step guide: Patch Management Checklist: Secure Systems Without Breaking Them
General security guidance from the Firewall Scoop newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Is this vulnerability being actively exploited in the wild?
The source material does not state whether the vulnerability is currently being exploited in the wild.
Does this affect versions older than 0.144.0?
Earlier releases were not tested, so the introduction boundary is unknown, though v0.143.0 has a related issue.
How is this different from GHSA-r277-6w6q-xmqw?
This vulnerability uses an explicit authentication callback and works after the v0.144.0 fix for the previous issue.



