CVE-2026-100353

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.

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.

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:

// 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:

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:

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:

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

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.

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.

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:

// 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:

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:

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:

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