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

• Go github.com/getkin/kin-openapi: >= 0.136.0, < 0.149.0 → fixed in 0.149.0

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(...) (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`.