Threats Tagged 'ghsa-23vg-4cjm-66q5'

## Summary `openapi3filter.ValidationHandler.Middleware` validates requests with kin-openapi's legacy router, which selects an OpenAPI operation from the decoded `URL.Path`. The method is documented as implementing `gorilla/mux.MiddlewareFunc`, but a downstream gorilla/mux router configured with `UseEncodedPath()` selects its handler from the encoded representation (`URL.RawPath`). An unauthenticated request such as `/public%2Fstatus` can therefore be validated as an intentionally public operation (`/public/status`) and then dispatched to a protected operation (`/{id}`). The configured, rejecting `AuthenticationFunc` is never invoked, and the protected downstream handler runs. This is distinct from GHSA-r277-6w6q-xmqw. The behavior below uses an explicit authentication callback that rejects missing credentials and remains reproducible after the v0.144.0 fix for the unsafe default callback. ## Affected products - Product: `github.com/getkin/kin-openapi` - Component: `openapi3filter.ValidationHandler.Middleware` - Confirmed post-GHSA affected releases: v0.144.0, v0.145.0, and v0.146.0 - Reporter attestation: each listed release was checked out separately, the attached single-file test was copied into `openapi3filter/`, and that test passed; maintainers should independently confirm the version range - Confirmed affected development revision: `d33e44e67734dcde81b576582185e1343fb3985d` - v0.143.0 also reproduces this mechanism, but GHSA-r277-6w6q-xmqw already provides a simpler bypass on that release; the distinct post-fix claim starts at v0.144.0 - Earlier releases: not tested; please treat the introduction boundary as unknown ## Security impact An unauthenticated remote requester can reach a handler whose OpenAPI operation requires authentication when all of the following are true: 1. the application uses `ValidationHandler.Middleware` as the security gate; 2. the downstream router preserves and interprets an encoded path, such as gorilla/mux with `UseEncodedPath()`; 3. a public exact route and a protected parameterized route overlap after decoding; 4. the public and protected operations expose the same HTTP method; 5. the protected handler relies on the validation layer's security decision. The protected operation's path-parameter value is constrained: it is an encoded representation that decodes to a public literal path (`public%2Fstatus` in this PoC), not an arbitrary attacker-selected identifier. A protected operation without a compatible parameterized path is not reachable through this specific mechanism. - Primitive: the security decision is made for a different OpenAPI operation than the operation dispatched by the application router. - Demonstrated impact: a protected handler executes while the explicitly rejecting `AuthenticationFunc` is never invoked. - Impact ceiling: confidentiality or integrity loss when the reachable protected handler has that authority; the PoC does not demonstrate data disclosure or state modification. - Availability impact: not demonstrated. ## Root cause At the confirmed development revision: - `openapi3filter/validation_handler.go`: `ValidationHandler.Load` constructs `routers/legacy.NewRouter` unconditionally. - `routers/legacy/router.go`: route selection uses the decoded request path. - `routers/gorillamux/router.go`: the kin-openapi gorilla router constructs a gorilla/mux router with `UseEncodedPath()`. - `ValidationHandler.Middleware` forwards the unchanged request after validation. The component making the authentication decision and the component dispatching the handler can therefore disagree about the selected operation. ## Reproduction The attached PoC uses a real `net/http` server, an explicit API-key callback that rejects missing credentials, and a downstream gorilla/mux router with `UseEncodedPath()`. From a kin-openapi checkout, copy the self-contained attachment `encoded_path_route_confusion_test.go.txt` into `openapi3filter/` as `encoded_path_route_confusion_test.go`, then run: ```sh go test -v ./openapi3filter -run '^TestEncodedPathAuthorizationBypass$' -count=1 ``` Expected attack observation: ```text status=202 downstream_route=/{id} protected_id=public%2Fstatus authentication_calls=0 wiring=Router.Use status=202 downstream_route=/{id} protected_id=public%2Fstatus authentication_calls=0 ``` Controls included in the test show that: - `/ordinary` selects the protected operation, invokes authentication once, and is rejected with HTTP 401; - `/public/status` reaches only the intentionally public handler; - the encoded request reaches the protected `/{id}` handler with HTTP 202 while the authentication callback remains uncalled; - both external wrapping and the documented `router.Use(validationHandler.Middleware)` wiring reproduce the same result. ## Reverse-proxy reachability The same request was reproduced through Nginx 1.31.3 using the official `nginx:alpine` image digest `sha256:4a73073bd557c65b759505da037898