Advisories for Golang/Github.com/Getkin/Kin-Openapi package

2026

kin-openapi openapi3filter: nil-pointer panic in ValidateResponse on a response header declared with content

ValidateResponse panics on a nil pointer when a spec declares a response header with content instead of schema. doc.Validate() accepts that document, so the crash comes from a spec the library just called valid. Same class as GHSA-jpcw-4wr7-c3vq, which covered the request-parameter case in v0.144.0; this is the response-header path. Affects github.com/getkin/kin-openapi <= v0.145.0. Reproduced on master 947498e5a6bd, Go 1.26.

kin-openapi: YAML NaN/Inf Values Bypass Built-in Guards and Panic via OAS 3.1 Validation Path

kin-openapi guards against NaN and Inf values in its built-in schema visitor (visitJSON) by returning ErrSchemaInputNaN / ErrSchemaInputInf when a float64 input violates those constraints. For OAS 3.1 specs, however, Schema.VisitJSON routes through useJSONSchema2020, which hands the value directly to santhosh-tekuri/jsonschema/v6 v6.0.2 without applying the same guard. Inside jsonschema/v6 v6.0.2, numValidate builds a *big.Rat from the input via big.Rat.SetString(fmt.Sprintf("%v", v)). For NaN/Inf this parse fails silently and returns nil. numValidate …

kin-openapi: ValidationHandler security-requirement bypass via encoded-path operation confusion

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, …

kin-openapi: Uncontrolled Recursion on Circular allOf/anyOf/oneOf Schemas Causes Fatal Process Crash

kin-openapi's spec loader and spec-time validator both handle circular schema references safely: the loader resolves circular $refs on purpose (to support recursive data structures), and Schema.validate() uses stack-based cycle detection. Validate() therefore accepts a schema whose allOf / anyOf / oneOf chain refers back to itself, returning no error. The runtime validators do not have that protection. When such a schema is used for request or response validation, the recursion …

kin-openapi: Unauthenticated panic (DoS) in openapi3filter legacy router via non-canonical/unsupported HTTP method on a static path

The openapi3filter.ValidationHandler (the exported, documented request-validation middleware) hard-wires the legacy router (routers/legacy). That router matches the incoming request method verbatim against a trie built exclusively from upper-cased canonical HTTP methods. A request carrying a method token that is not one of the 9 standard methods — a legitimate-but-unsupported token such as PROPFIND, or a non-canonical case variant such as lowercase get — misses the trie, leaves route == nil, and …

kin-openapi: Nil-pointer dereference panic in openapi3filter for OpenAPI 3.1 array schemas missing items

A nil-pointer dereference in openapi3filter lets any unauthenticated client crash a request handler with a single HTTP request against an OpenAPI 3.1 operation that declares type: array without items. OpenAPI 3.1 (JSON Schema 2020-12) permits omitting items, and doc.Validate() accepts such schemas with Schema.Items == nil. Request/response decoders then dereference Items with no nil check. The panic is deterministic (100%) on every request to the affected operation. There is no …

kin-openapi: Incomplete Fix for GHSA-p6wj-qrr4-pgh5: Three Unpatched nil-Items Panic Paths in openapi3filter

The fix for GHSA-p6wj-qrr4-pgh5 addressed a nil-pointer dereference that occurs when an OpenAPI 3.1 array schema omits the items keyword (which is legal under JSON Schema 2020-12). That fix patched three decoder paths: the standalone parseArray function, the top-level array check in UrlencodedBodyDecoder, and MultipartBodyDecoder. Three additional crash paths were missed. All of them reach the unguarded urlValuesDecoder.parseArray method (openapi3filter/req_resp_decoder.go:576) or the unguarded array branch in buildResObj (line 1015): Query …

kin-openapi spec loader panics on a self-referential additionalProperties $ref (nil-pointer DoS)

The defect Confirmed at HEAD (f0407d5, v0.144.0). openapi3/loader.go, inside resolveComponent's drill closure (around line 455), the case *SchemaRef branch for pathPart == "additionalProperties" dereferences c.Value.AdditionalProperties with no nil-check on c.Value: case *SchemaRef: if pathPart == "additionalProperties" { if ap := c.Value.AdditionalProperties.Has; ap != nil { // c.Value can be nil here cursor = *ap } else { cursor = c.Value.AdditionalProperties.Schema } attempted = true } When a $ref fragment drills …

kin-openapi deepObject query decoding repeatedly compiles an invariant regular expression

openapi3filter decodes deepObject-style query parameters by looping over every key in the request's query string. Inside that loop it recompiles a loop-invariant regular expression on every iteration. The pattern depends only on the spec-defined parameter name, not on the loop variable, so it is compiled N times for N query keys instead of once. Because the number of query keys is attacker-controlled and unbounded, a single request with many junk …

kin-openapi openai3filter: nil-pointer panic in ConvertErrors on malformed multipart/form-data body enables unauthenticated DoS

A nil-pointer dereference in openapi3filter.ConvertErrors lets any unauthenticated client crash a server with a single HTTP request. When an application validates a multipart/form-data request body and renders the resulting validation error through the library-provided ValidationErrorEncoder / ConvertErrors helpers, a malformed scalar form field (e.g. a non-numeric value for an integer property) produces an error shape that convertParseError dereferences without a nil check. The handler goroutine panics, causing a denial of …

kin-openapi has uncontrolled resource consumption in openapi3filter deepObject query parameter decoding

An uncontrolled resource consumption vulnerability in openapi3filter lets any unauthenticated client force multi-gigabyte heap allocation with a single, tiny HTTP request. When a spec declares a deepObject-style query parameter whose schema contains an array (a normal, documented pattern), the decoder reconstructs the array by reading the largest attacker-supplied index and allocating one slot for every position from 0 up to that index — before schema validation (including maxItems) ever runs. …

kin-openapi: ValidationHandler.Load() Fail-Open Authentication Bypass via NoopAuthenticationFunc Default

ValidationHandler.Load() in getkin/kin-openapi silently replaces a nil AuthenticationFunc with NoopAuthenticationFunc, which always returns nil without performing any credential check. Because this substitution happens unconditionally when the caller omits the field, every OpenAPI security requirement declared in the spec is silently satisfied for unauthenticated requests. An unauthenticated remote attacker can reach handlers for routes whose OpenAPI operation requires an API key, OAuth token, or any other security scheme if the application …

kin-openapi openapi3filter: unauthenticated nil-pointer panic when validating a request against a `content` parameter whose media type has no schema

openapi3filter.ValidateRequest contains a NULL-pointer-dereference denial of service: any unauthenticated client can crash the request-validation path with a single HTTP request. When an operation declares a content parameter (as opposed to a schema parameter) whose media type object has no schema, request validation dereferences that missing schema and panics. The document is legal under the OpenAPI Specification — kin-openapi's own doc.Validate() accepts it — and the defect affects both OpenAPI 3.0.x …

2025