OFFLINE
Awaiting data
Security intelligence
MajorCritical vulnerability

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

GitHub Advisories · officialPublished Oct 15, 2026Risk 37/100

## Summary 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): 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 request validation. ## Details ### Root Cause The three paths patched for GHSA-p6wj-qrr4-pgh5 each received a nil-`items` guard: ```go // standalone parseArray (line 1143) -- GUARDED func parseArray(raw []string, schemaRef *openapi3.SchemaRef) ([]any, error) { if schemaRef.Value.Items == nil || schemaRef.Value.Items.Value == nil { ... } // UrlencodedBodyDecoder top-level property loop (line 1441) -- GUARDED if propSchema.Value.Items == nil || propSchema.Value.Items.Value == nil { ... } // MultipartBodyDecoder (line 1587) -- GUARDED if valueSchema.Value.Items == nil { ... } ``` But `urlValuesDecoder.parseArray` (line 576), which handles query-parameter and urlencoded-body array decoding, has **no** such guard: ```go func (d *urlValuesDecoder) parseArray(raw []string, schemaRef *openapi3.SchemaRef) ([]any, error) { var value []any for i, v := range raw { item, err := d.parseValue(v, schemaRef.Value.Items) // Items is nil -> panic in parseValue ``` `parseValue` immediately dereferences the schema it is handed: ```go func (d *urlValuesDecoder) parseValue(v string, schema *openapi3.SchemaRef) (any, error) { if len(schema.Value.AllOf) > 0 { // schema == nil here -> nil pointer dereference ``` For the deepObject path, `buildResObj` (line 1015) has the same gap. Its array branch recurses with `schema.Value.Items` (line 1028), which can be nil, and the recursive call dereferences it at line 1015: ```go case schema.Value.Type.Is("array"): // ... for i := range arr { r, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items) // nil Items ``` For the allOf body path, `UrlencodedBodyDecoder` validates only top-level `schema.Value.Properties` (line 1429-1449). But `decodeSchemaConstructs` (line 1474) recursively walks `AllOf` / `AnyOf` / `OneOf` sub-schemas and calls `decodeProperty` on their properties, which never pass through the top-level guard and reach `urlValuesDecoder.parseArray`. ## Proof of Concept ### Environment - kin-openapi v0.144.0 (cloned at tag `v0.144.0`, commit `f0407d5`) - Go 1.26.7 - Each PoC calls `doc.Validate()` first to prove the spec is legal, then drives `openapi3filter.ValidateRequest` directly ### Path 1: Query parameter array without items Spec (query param `ids` is `type: array`, no `items`), request `GET /test?ids=1&ids=2`: ``` Validate() ACCEPTED the spec (type: array with no items is legal under OAS 3.1) Calling ValidateRequest directly (no net/http recover)... panic: runtime error: invalid memory address or nil pointer dereference [signal 0xc0000005 code=0x0 addr=0x20 ...] github.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseValue(...) req_resp_decoder.go:605 github.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseArray(...) req_resp_decoder.go:580 github.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).DecodeArray(...) req_resp_decoder.go:569 ... github.com/getkin/kin-openapi/openapi3filter.ValidateRequest(...) validate_request.go:83 exit status 2 ``` ### Path 2: deepObject nested array without items Spec (deepObject param `filter` with array property `tags`, no `items`), request `GET /test?filter[tags][0]=a`: ``` Validate() ACCEPTED the spec Calling ValidateRequest directly... panic: runtime error: invalid memory address or nil pointer dereference github.com/getkin/kin-openapi/openapi3filter.buildResObj(...) req_resp_decoder.go:1012 github.com/getkin/kin-openapi/openapi3filter.buildResObj(...) <- recursive call with nil Items req_resp_decoder.go:1028 github.com/getkin/kin-openapi/openapi3filter.makeObject(...) req_resp_decoder.go:947 ... exit status 2 ``` ### Path 3: URL-encoded body with array inside allOf (bypasses the existing fix) Spec (urlencoded body, `allOf` sub-schema with array property `tags`, no `items`), request `POST /submit` body `tags=a&tags=b`: ``` Validate() ACCEPTED the spec Calling ValidateRequest directly... panic: runtime error: invalid memory address or nil pointer dereference github.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseValue(...) req_resp_decoder.go:605 github.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseArray(...) req_resp_decoder.go:580 github.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).DecodeArray(...) req_resp_decoder.go:569 ... github.com/getkin/kin-openapi/openapi3filter.decodeProperty(...) <- reached via decodeSchemaConstructs (allOf walker) req_resp_decoder.go:1519 exit status 2 ``` The `decodeProperty` frame confirms the array was reached by walking the `allOf` sub-schema, bypassing the top-level guard that the GHSA-p6wj-qrr4-pgh5 fix added. ### Fix verification Adding a single nil-`items` guard to `urlValuesDecoder.parseArray` (plus one to the `buildResObj` array branch) turns all three panics into clean validation errors: ``` poc1: Returned normally, err = parameter "ids" in query has an error: array items schema is required for decoding poc2: Returned normally, err = parameter "filter" in query has an error: path tags: array items schema is required poc3: Returned normally, err = <nil> (no panic; the allOf property is skipped by the decoder) ``` This confirms `urlValuesDecoder.parseArray` is the shared root cause for Paths 1 and 3, and `buildResObj` for Path 2. ## Impact An unauthenticated client can trigger a deterministic nil-pointer panic in request validation with a single crafted request, against any application that validates OAS 3.1 requests with `openapi3filter` where a spec declares an array without `items`. The severity depends on the host: | Deployment | Behavior | Availability impact | |------------|----------|---------------------| | Standard `net/http` server (validation runs in the handler goroutine) | `net/http` recovers the panic per-connection; the connection is dropped and the process survives | Per-request denial of service (A:L) | | Non-`net/http` hosts (e.g. fasthttp/connect adapters) or validation performed in an application-spawned goroutine | The panic is not recovered; the process crashes | Full-process denial of service (A:H) | This was verified in both configurations: under a live `net/http` server the process survived (the panic was logged as `http: panic serving ...` and the process exited 0 at end of test), while the direct-call PoCs above crashed the process with `exit status 2`.

Upgrade affected packages to a patched version: github.com/getkin/kin-openapi 0.149.0.

Vendor
Not specified
Product
github.com/getkin/kin-openapi
Exploitation
none known
Evidence
official
CVSS
7.5

This record is attributed to GitHub Advisories. Exploitation status and remediation guidance are kept separate from the vulnerability's technical severity.

Open primary source