Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
14 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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. Details A content-typed response header has headerRef.Value.Schema == nil. validateresponse.go:181 passes it straight through: and reqrespdecoder.go:273 is where it lands: Two things I checked rather than assumed. The response does not need to carry the header; declaring it is enough, and then every call for that operation panics. And the body path is fine, :114 returns early on a nil schema, so this is headers only. The PoC keeps the body case as a control. PoC Drop into openapi3filter/ and run: Output: The FAIL is the point: control passes, the header…
Recommended action: Upgrade to 0.146.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getkin/kin-openapi >= 0.136.0, < 0.149.0
Fixed in
0.149.0· Vendor fix available
Issue
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/reqrespdecoder.go:576) or the unguarded array branch in buildResObj (line 1015): 1. Query parameters with type: array and no items. 2. deepObject query parameters containing an array property with no items. 3. URL-encoded request bodies where the array lives inside an allOf / anyOf / oneOf sub-schema. This path bypasses the guard added by the GHSA-p6wj-qrr4-pgh5 fix, because that guard only inspects top-level properties. Each path is triggerable by an unauthenticated client and produces a deterministic nil-pointer panic during…
Recommended action: Upgrade to 0.149.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 through the combinator chain is unbounded. In Go this produces a fatal stack overflow (runtime: goroutine stack exceeds ... limit / fatal error: stack overflow), which is not a recoverable panic. recover() cannot catch it, so net/http's per-connection recovery does not help. The entire process is terminated, including all goroutines serving unrelated clients. Two independent unguarded recursion sites were confirmed: 1. openapi3/schema.go — visitJSON / visitXOFOperations (reached by VisitJSON, i.e.…
Recommended action: Upgrade to 0.149.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 then dereferences the nil big.Rat (in math/big.(Rat).Cmp), producing a Go runtime panic. An attacker delivers this by sending an HTTP request with Content-Type: application/yaml (or application/x-yaml) and a YAML body containing .nan, .inf, or -.inf. The YamlBodyDecoder decodes those tokens into math.NaN() / math.Inf(±1) (standard YAML 1.2 behavior), and they propagate to the unguarded useJSONSchema2020 path whenever the schema…
Recommended action: Upgrade to 0.148.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getkin/kin-openapi >= 0.144.0, < 0.147.0
Fixed in
0.147.0· Vendor fix available
Issue
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…
Recommended action: Upgrade to 0.147.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getkin/kin-openapi >= 0.145.0, < 0.146.0
Fixed in
0.146.0· Vendor fix available
Issue
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 query keys forces a proportional number of regexp.MustCompile calls, consuming CPU. A handful of concurrent requests can saturate all cores — an uncontrolled-resource-consumption denial of service. This is not ReDoS: the pattern is fixed (^<param\) and matches in linear time. The cost is the repeated compilation of an invariant regexp, once per attacker-supplied query key. Details In openapi3filter/reqrespdecoder.go, the deepObject branch of urlValuesDecoder.DecodeObject builds a per-parameter property map by iterating over all…
Recommended action: Upgrade to 0.146.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 through .../additionalProperties of a schema whose Value is still nil (a pure, not-yet-resolved $ref, or a self-reference resolved before its own Value is set), c.Value is nil and the .AdditionalProperties access panics. Input and attacker ------------------- A tiny crafted OpenAPI document, one schema, no external refs, no network: openapi: 3.0.3 info: {title: t, version: "1.0.0"} paths: {} components: schemas: A: $ref:…
Recommended action: Upgrade to 0.145.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 for an existing static path falls through to PathItem.GetOperation(method), whose default: case calls panic(...). The panic fires inside route resolution, before any authentication runs. This is an unauthenticated, remotely triggerable denial of service (recovered per-connection panic + unbounded error-log growth). Root Cause - openapi3filter/validationhandler.go:39 — ValidationHandler.Load() always constructs legacyrouter.NewRouter(doc); there is no alternative router option on this…
Recommended action: Upgrade to 0.145.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getkin/kin-openapi >= 0.136.0, < 0.143.0
Fixed in
0.143.0· Vendor fix available
Issue
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 recover() in openapi3filter; under handlers without per-request recover the process can exit. Details Spec-validation asymmetry. OpenAPI 3.0 rejects array schemas that omit items (openapi3/schema.go around the TypeArray / newSchemaItemsRequired branch). For OpenAPI 3.1, T.Validate enables jsonSchema2020ValidationEnabled, so that check is skipped and Schema.Items remains nil after a clean doc.Validate(). Vulnerable decoder. The primary request-side crash is in UrlencodedBodyDecoder (still present on…
Recommended action: Upgrade to 0.143.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getkin/kin-openapi >= 0.124.0, < 0.142.0
Fixed in
0.142.0· Vendor fix available
Issue
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. A request as small as 24 bytes (?param[items][50000000]=x) drives heap allocation to ~6.1 GiB, reliably triggering an OOM kill / restart loop on memory-constrained services. Details The OpenAPI style: deepObject serialization lets clients express arrays in the query string using bracket notation, e.g. param[items][0]=a¶m[items][1]=b. The decoder first collects these into an intermediate map[string]any keyed by the string of the index, then converts that sparse map into a real []any…
Recommended action: Upgrade to 0.142.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/getkin/kin-openapi >= 0.10.0, < 0.141.0
Fixed in
0.141.0· Vendor fix available
Issue
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 service. application/json request bodies are not affected — the bug is specific to multipart/form-data. Details The panic is in convertParseError, at openapi3filter/validationerrorencoder.go:119-120 (still present on master at the time of writing): The comparison e.Parameter.In == "query" assumes e.Parameter is non-nil. It is reached whenever both of the following hold: 1. e.Parameter == nil. A RequestError carries either Parameter (parameter errors) or…
Recommended action: Upgrade to 0.141.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 relies on ValidationHandler as its enforcement middleware. Details ValidationHandler is an HTTP middleware exported by openapi3filter that validates incoming requests and responses against a loaded OpenAPI specification. Its Load() method initialises default fields before the handler begins serving: NoopAuthenticationFunc is defined as: It always returns nil, meaning every security scheme check it handles is automatically approved. When a…
Recommended action: Upgrade to 0.144.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
| Field | Value | |---|---| | Ecosystem | Go | | Package | github.com/getkin/kin-openapi | | Affected versions | <= 0.143.0 (introduced in v0.2.0, PR #90, 2019-05-07; reproduced on HEAD 30e2923) | | Patched versions | 0.144.0 | --- Summary 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 and 3.1.x. Depending on how the library is wired into the server (see Impact), this ranges from a per-request abort with unbounded panic-log growth to a full remote process crash. Details The decoder used for content parameters when no custom…
Recommended action: Upgrade to 0.144.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When validating a request with a multipart/form-data schema, if the OpenAPI schema allows it, an attacker can upload a crafted ZIP file (e.g., a ZIP bomb), causing the server to consume all available system memory. Details The root cause comes from the ZipFileBodyDecoder, which is registered automatically by the module (contrary to what the documentation says. PoC To reproduce the vulnerability, you can use the following OpenAPI schema: And this code to validate the request (nothing fancy, it basically only calls the openapi3filter.ValidateRequest function): We also need to create a zip bomb. This command will create a 4.7GB file and compress it to to 4.7MB zip archive: Run the PoC provided, and upload the zip bomb with curl localhost:8080/ -F file="@/tmp/bomb.zip;type=application/zip" -v. Observe the memory consumption of the test server during and after the upload (it jumped to a bit over 22GB in my testing, with only a 4.7MB input file, you can reduce the size of the…
Recommended action: Upgrade to 0.131.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.