kin-openapi is a Go project for handling OpenAPI files. From 0.136.0 until 0.149.0, three openapi3filter decoder paths that were missed by the fix for GHSA-p6wj-qrr4-pgh5 lack a nil-items guard for legal OpenAPI 3.1 array schemas. An unauthenticated remote client can trigger a deterministic nil-pointer panic through an array query parameter, a deepObject query parameter containing an array property, or an application/x-www-form-urlencoded request body whose array property appears inside an allOf, anyOf, or oneOf subschema. The query and composed-body paths reach urlValuesDecoder.parseArray, while the deepObject path reaches buildResObj, and all pass a nil items schema into code that dereferences it. This issue is fixed in version 0.149.0.

Affected: Go: github.com/getkin/kin-openapi

## 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 || p…

github.com/getkin/kin-openapi: kin-openapi: Denial of Service via nil-pointer dereference in openapi3filter github.com/getkin/kin-openapi: kin-openapi: Denial of Service via unsupported HTTP methods on static paths github.com/getkin/kin-openapi: kin-openapi: Denial of Service via nil pointer dereference in response validation github.com/getkin/kin-openapi: kin-openapi: Denial of Service via redundant regular expression compilation in query parameter decoding github.com/getkin/kin-openapi: kin-openapi: Authentication bypass via URL path decoding discrepancy github.com/getkin/kin-openapi: kin-openapi: Denial of Service via improper handling of non-finite numeric values github.com/getkin/kin-openapi: kin-openapi: Denial of Service via nil-pointer dereference in request decoding github.com/getkin/kin-openapi: kin-openapi: Denial of Service via unbounded recursion during schema validation

Affected: Ubuntu:22.04:LTS: golang-github-getkin-kin-openapi, Ubuntu:24.04:LTS: golang-github-getkin-kin-openapi, Ubuntu:26.10: golang-github-getkin-kin-openapi, Ubuntu:26.04:LTS: golang-github-getkin-kin-openapi

kin-openapi is a Go project for handling OpenAPI files. From 0.136.0 until 0.149.0, three openapi3filter decoder paths that were missed by the fix for GHSA-p6wj-qrr4-pgh5 lack a nil-items guard for legal OpenAPI 3.1 array schemas. An unauthenticated remote client can trigger a deterministic nil-pointer panic through an array query parameter, a deepObject query parameter containing an array property, or an application/x-www-form-urlencoded request body whose array property appears inside an allOf, anyOf, or oneOf subschema. The query and composed-body paths reach urlValuesDecoder.parseArray, while the deepObject path reaches buildResObj, and all pass a nil items schema into code that dereferences it. This issue is fixed in version 0.149.0.