GHSA-VRCC-3CH7-HPPW

Vulnerability from github – Published: 2026-10-15 20:20 – Updated: 2026-10-15 20:20
VLAI
Summary
kin-openapi: Incomplete Fix for GHSA-p6wj-qrr4-pgh5: Three Unpatched nil-Items Panic Paths in openapi3filter
Details

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

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/getkin/kin-openapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.136.0"
            },
            {
              "fixed": "0.149.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-100353"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-476"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-15T20:20:47Z",
    "nvd_published_at": "2026-10-15T17:17:07Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nThe 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`.\n\nThree 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):\n\n1. **Query parameters** with `type: array` and no `items`.\n2. **deepObject** query parameters containing an array property with no `items`.\n3. **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.\n\nEach path is triggerable by an unauthenticated client and produces a deterministic nil-pointer panic during request validation.\n\n## Details\n### Root Cause\n\nThe three paths patched for GHSA-p6wj-qrr4-pgh5 each received a nil-`items` guard:\n\n```go\n// standalone parseArray (line 1143) -- GUARDED\nfunc parseArray(raw []string, schemaRef *openapi3.SchemaRef) ([]any, error) {\n\tif schemaRef.Value.Items == nil || schemaRef.Value.Items.Value == nil { ... }\n\n// UrlencodedBodyDecoder top-level property loop (line 1441) -- GUARDED\nif propSchema.Value.Items == nil || propSchema.Value.Items.Value == nil { ... }\n\n// MultipartBodyDecoder (line 1587) -- GUARDED\nif valueSchema.Value.Items == nil { ... }\n```\n\nBut `urlValuesDecoder.parseArray` (line 576), which handles query-parameter and urlencoded-body array decoding, has **no** such guard:\n\n```go\nfunc (d *urlValuesDecoder) parseArray(raw []string, schemaRef *openapi3.SchemaRef) ([]any, error) {\n\tvar value []any\n\tfor i, v := range raw {\n\t\titem, err := d.parseValue(v, schemaRef.Value.Items) // Items is nil -\u003e panic in parseValue\n```\n\n`parseValue` immediately dereferences the schema it is handed:\n\n```go\nfunc (d *urlValuesDecoder) parseValue(v string, schema *openapi3.SchemaRef) (any, error) {\n\tif len(schema.Value.AllOf) \u003e 0 {   // schema == nil here -\u003e nil pointer dereference\n```\n\nFor 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:\n\n```go\ncase schema.Value.Type.Is(\"array\"):\n\t// ...\n\tfor i := range arr {\n\t\tr, err := buildResObj(params, mapKeys, strconv.Itoa(i), schema.Value.Items) // nil Items\n```\n\nFor 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`.\n\n## Proof of Concept\n\n### Environment\n\n- kin-openapi v0.144.0 (cloned at tag `v0.144.0`, commit `f0407d5`)\n- Go 1.26.7\n- Each PoC calls `doc.Validate()` first to prove the spec is legal, then drives `openapi3filter.ValidateRequest` directly\n\n### Path 1: Query parameter array without items\n\nSpec (query param `ids` is `type: array`, no `items`), request `GET /test?ids=1\u0026ids=2`:\n\n```\nValidate() ACCEPTED the spec (type: array with no items is legal under OAS 3.1)\nCalling ValidateRequest directly (no net/http recover)...\npanic: runtime error: invalid memory address or nil pointer dereference\n[signal 0xc0000005 code=0x0 addr=0x20 ...]\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseValue(...)\n\treq_resp_decoder.go:605\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseArray(...)\n\treq_resp_decoder.go:580\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).DecodeArray(...)\n\treq_resp_decoder.go:569\n...\ngithub.com/getkin/kin-openapi/openapi3filter.ValidateRequest(...)\n\tvalidate_request.go:83\nexit status 2\n```\n\n### Path 2: deepObject nested array without items\n\nSpec (deepObject param `filter` with array property `tags`, no `items`), request `GET /test?filter[tags][0]=a`:\n\n```\nValidate() ACCEPTED the spec\nCalling ValidateRequest directly...\npanic: runtime error: invalid memory address or nil pointer dereference\ngithub.com/getkin/kin-openapi/openapi3filter.buildResObj(...)\n\treq_resp_decoder.go:1012\ngithub.com/getkin/kin-openapi/openapi3filter.buildResObj(...)   \u003c- recursive call with nil Items\n\treq_resp_decoder.go:1028\ngithub.com/getkin/kin-openapi/openapi3filter.makeObject(...)\n\treq_resp_decoder.go:947\n...\nexit status 2\n```\n\n### Path 3: URL-encoded body with array inside allOf (bypasses the existing fix)\n\nSpec (urlencoded body, `allOf` sub-schema with array property `tags`, no `items`), request `POST /submit` body `tags=a\u0026tags=b`:\n\n```\nValidate() ACCEPTED the spec\nCalling ValidateRequest directly...\npanic: runtime error: invalid memory address or nil pointer dereference\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseValue(...)\n\treq_resp_decoder.go:605\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).parseArray(...)\n\treq_resp_decoder.go:580\ngithub.com/getkin/kin-openapi/openapi3filter.(*urlValuesDecoder).DecodeArray(...)\n\treq_resp_decoder.go:569\n...\ngithub.com/getkin/kin-openapi/openapi3filter.decodeProperty(...)   \u003c- reached via decodeSchemaConstructs (allOf walker)\n\treq_resp_decoder.go:1519\nexit status 2\n```\n\nThe `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.\n\n### Fix verification\n\nAdding a single nil-`items` guard to `urlValuesDecoder.parseArray` (plus one to the `buildResObj` array branch) turns all three panics into clean validation errors:\n\n```\npoc1: Returned normally, err = parameter \"ids\" in query has an error: array items schema is required for decoding\npoc2: Returned normally, err = parameter \"filter\" in query has an error: path tags: array items schema is required\npoc3: Returned normally, err = \u003cnil\u003e   (no panic; the allOf property is skipped by the decoder)\n```\n\nThis confirms `urlValuesDecoder.parseArray` is the shared root cause for Paths 1 and 3, and `buildResObj` for Path 2.\n\n## Impact\n\nAn 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`.\n\nThe severity depends on the host:\n\n| Deployment | Behavior | Availability impact |\n|------------|----------|---------------------|\n| 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) |\n| 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) |\n\nThis 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`.",
  "id": "GHSA-vrcc-3ch7-hppw",
  "modified": "2026-10-15T20:20:47Z",
  "published": "2026-10-15T20:20:47Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/security/advisories/GHSA-vrcc-3ch7-hppw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100353"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/commit/9814d1f2b212f3508bf52296aa9e248b2122a5a9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getkin/kin-openapi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkin/kin-openapi/releases/tag/v0.149.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kin-openapi: Incomplete Fix for GHSA-p6wj-qrr4-pgh5: Three Unpatched nil-Items Panic Paths in openapi3filter"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON
Events included in the timeline

Loading timeline…


    Loading…

    Loading…

    Loading…

    Related by attack behaviour

    Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.