--- id: "CVE-2026-100352" page: "https://infrastack.ai/live/CVE-2026-100352" kind: "vulnerability" aliases: ["CVE-2026-100352", "GHSA-rj39-cv6w-8wv7", "GO-2026-6795"] title: "kin-openapi: YAML NaN/Inf Values Bypass Built-in Guards and Panic via OAS 3.1 Validation Path" severity: "high" cvss: 7.5 epss: 0.00595 exploited: false status: "open" category: "package" products: [{"name": "github.com/getkin/kin-openapi", "fixed": ["0.148.0"], "affected": "< 0.148.0", "ecosystem": "go"}] ecosystems: ["go"] tags: ["cwe-754", "go", "kin-openapi", "openapi", "package"] not_affected_if: ["not-oas-3.1", "trusted-input-only"] published_at: "2026-10-15T16:17:31+00:00" first_seen_at: "2026-11-06T00:09:05+00:00" updated_at: "2026-11-06T00:19:08+00:00" sources: [{"source": "govuln", "url": "https://pkg.go.dev/vuln/GO-2026-6795", "first_seen_at": "2026-11-06T00:09:05+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-100352", "first_seen_at": "2026-11-06T00:19:01+00:00"}, {"source": "ghsa", "url": "https://github.com/advisories/GHSA-rj39-cv6w-8wv7", "first_seen_at": "2026-11-06T00:19:08+00:00"}] exploit_sources: [{"type": "epss", "score": 0.00595, "url": "https://api.first.org/data/v1/epss?cve=CVE-2026-100352"}] --- # kin-openapi: YAML NaN/Inf Values Bypass Built-in Guards and Panic via OAS 3.1 Validation Path Link for people: https://infrastack.ai/live/CVE-2026-100352 (this .md is for agents) kin-openapi, a Go library for parsing and validating OpenAPI specs, accepts YAML NaN and Inf values that skip its built-in checks on the OAS 3.1 validation path. Feeding such a spec can cause a panic that crashes the program using the library. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - go:github.com/getkin/kin-openapi affected < 0.148.0 fixed 0.148.0 ## How to check - Run `go list -m github.com/getkin/kin-openapi` in the project to see the version in use. - Check whether the version is below `0.148.0`. ## Fix - `github.com/getkin/kin-openapi` `0.148.0` ## Timeline - 2026-11-06T00:09:05+00:00 govuln https://pkg.go.dev/vuln/GO-2026-6795 - 2026-11-06T00:19:01+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-100352 - 2026-11-06T00:19:08+00:00 ghsa https://github.com/advisories/GHSA-rj39-cv6w-8wv7 ## Documents - [advisory] Vendor advisory: github.com https://github.com/getkin/kin-openapi/security/advisories/GHSA-rj39-cv6w-8wv7 - [advisory] Maintainer's advisory: api.github.com https://api.github.com/repos/getkin/kin-openapi/security-advisories/GHSA-rj39-cv6w-8wv7 - [fix] Patch: github.com https://github.com/getkin/kin-openapi/commit/4487f198ab8be0c37d6ca72c54f5dca4dc25270e - [fix] Release notes: github.com https://github.com/getkin/kin-openapi/releases/tag/v0.148.0 ## From the sources ## Summary kin-openapi guards against `NaN` and `Inf` values in its built-in schema visitor (`visitJSON`) by returning `ErrSchemaInputNaN` / `ErrSchemaInputInf` when a `float64` input violates those constraints. For OAS 3.1 specs, however, `Schema.VisitJSON` routes through `useJSONSchema2020`, which hands the value directly to `santhosh-tekuri/jsonschema/v6` v6.0.2 without applying the same guard. Inside `jsonschema/v6` v6.0.2, `numValidate` builds a `*big.Rat` from the input via `big.Rat.SetString(fmt.Sprintf("%v", v))`. For `NaN`/`Inf` this parse fails silently and returns `nil`. `numValidate` then dereferences the nil `*big.Rat` (in `math/big.(*Rat).Cmp`), producing a Go runtime panic. An attacker delivers this by sending an HTTP request with `Content-Type: application/yaml` (or `application/x-yaml`) and a YAML body containing `.nan`, `.inf`, or `-.inf`. The `YamlBodyDecoder` decodes those tokens into `math.NaN()` / `math.Inf(±1)` (standard YAML 1.2 behavior), and they propagate to the unguarded `useJSONSchema2020` path whenever the schema declares a numeric constraint (`minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, or `multipleOf`). ## Details ### Root Cause The built-in visitor `visitJSON` at `openapi3/schema.go:1968` guards NaN/Inf explicitly: ```go case float64: if math.IsNaN(value) { return ErrSchemaInputNaN } if math.IsInf(value, 0) { return ErrSchemaInputInf } ``` For OAS 3.1 specs, `VisitJSON` dispatches to `useJSONSchema2020` (`openapi3/schema_jsonschema_validator.go:204`), which contains no such guard: ```go func (schema *Schema) useJSONSchema2020(settings *schemaValidationSettings, value any) error { validator, err := newJSONSchemaValidator(schema) if err != nil { return schema.visitJSON(settings, value) } return validator.validate(value) // value handed straight through } ``` `jsonSchemaValidator.validate` calls `jsonschema/v6.Schema.Validate` (line 146), which reaches `numValidate` in v6.0.2. There, `big.Rat.SetString(fmt.Sprintf("%v", v))` returns `(nil, false)` for `NaN`/`Inf`, and the code dereferences the `nil` `*big.Rat` in `Rat.Cmp`, causing the panic. ## Proof of Concept ### Environment - kin-openapi v0.144.0 (tag `v0.144.0`, commit `f0407d5`) - santhosh-tekuri/jsonschema/v6 v6.0.2 (transitive dep) - Go 1.26.7 ### Spec Minimal OAS 3.1 spec (`spec.yaml`) declaring a YAML body with a numeric constraint: ```yaml openapi: '3.1.0' info: { title: Test, version: '1.0' } paths: /test: post: requestBody: required: true content: application/yaml: schema: type: number minimum: 0 responses: '200': { description: OK } ``` ### Trigger A single `POST /test` with `Content-Type: application/yaml` and body `.nan`, `.inf`, or `-.inf`. All three variants panic: ``` === RUN TestNaNInf [nan] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference [inf] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference [neginf] PANIC (confirms vuln): runtime error: invalid memory address or nil pointer dereference ``` ### Panic stack trace (confirms exact chain) ``` panic: runtime error: invalid memory address or nil pointer dereference math/big.(*Rat).Cmp(0x0, ...) <- nil *big.Rat dereferenced C:/Program Files/Go/src/math/big/rat.go:492 github.com/santhosh-tekuri/jsonschema/v6.(*validator).numValidate(...) .../jsonschema/v6@v6.0.2/validator.go:525 github.com/santhosh-tekuri/jsonschema/v6.(*validator).validate(...) .../jsonschema/v6@v6.0.2/validator.go:168 github.com/santhosh-tekuri/jsonschema/v6.(*Schema).validate(...) .../jsonschema/v6@v6.0.2/validator.go:34 github.com/getkin/kin-openapi/openapi3.(*jsonSchemaValidator).validate(...) openapi3/schema_jsonschema_validator.go:146 github.com/getkin/kin-openapi/openapi3.(*Schema).useJSONSchema2020(...) <- MISSING NaN/Inf guard openapi3/schema_jsonschema_validator.go:211 github.com/getkin/kin-openapi/openapi3.(*Schema).VisitJSON(...) openapi3/schema.go:1946 github.com/getkin/kin-openapi/openapi3filter.ValidateRequestBody(...) openapi3filter/validate_request.go:364 github.com/getkin/kin-openapi/openapi3filter.ValidateRequest(...) openapi3filter/validate_request.go:96 ``` ### net/http behavior (severity nuance) Behind a standard `net/http` server, the panic is recovered per-connection. The client sees a dropped connection; the server process continues: ``` Sending POST /test body=.nan against real net/http server... 2026/08/25 http: panic serving 127.0.0.1:40625: runtime error: invalid memory address or nil pointer dereference CLIENT ERROR (connection dropped): Post ".../test": EOF Process still alive after request: true ``` This is a **recoverable panic**, unlike the recursion finding. `recover()` catches it (verified by capturing the panic value in a `defer` in the same goroutine). Non-`net/http` hosts or validation performed in an application-spawned goroutine are not covered by that recovery and would experience a full-process crash. ### Fix verification Upgrading only the transitive dependency to `jsonschema/v6@v6.0.3` (via `go get github.com/santhosh-tekuri/jsonschema/v6@v6.0.3`) eliminates the panic entirely; all three payloads return a clean validation error: ``` [nan] Returned normally, err = request body has an error: doesn't match schema: validation failed due to: at '': invalid jsonType float64 [inf] Returned normally, err = request body has an error: doesn't match schema: validation failed due to: at '': invalid jsonType float64 [neginf] Returned normally, err = request body has an error: doesn't match schema: validation failed due to: at '': invalid jsonType float64 ``` This confirms the upstream `jsonschema/v6` v6.0.3 release treats the NaN/Inf case as a bug and fixes it at the source. It also confirms `useJSONSchema2020` is the reachable path: patching only the transitive dep removes the panic without touching kin-openapi code. ## Why This Is a Vulnerability, Not by Design - The library explicitly refuses NaN/Inf in its own visitor (`ErrSchemaInputNaN` / `ErrSchemaInputInf` at `schema.go:1968`). The stated policy is: these values are not allowed. - The OAS 3.1 dispatch (`useJSONSchema2020`) simply omits the same guard — a coding gap, not a design decision. - Upstream `jsonschema/v6` v6.0.3 fixes the same case as a bug. Two independent code owners agree it should not panic. - The trigger is a single HTTP request body an unauthenticated client can send. There is no legitimate content-authoring reason to submit `.nan` / `.inf` as a numeric field. ## Impact - **Per-request denial of service (net/http hosts).** Every crafted request kills its own connection with zero attacker cost. Sustained flooding degrades service reliability and log noise. - **Full-process denial of service (non-net/http hosts or goroutine-spawned validation).** No `net/http` recovery wrapper is present; the whole process crashes on a single request. - **Attack surface is any OAS 3.1 API that accepts YAML bodies with numeric constraints.** These constraints (`minimum`, `maximum`, `exclusiveMinimum`, `exclusiveMaximum`, `multipleOf`) are common on any numeric field with a range. --- _Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_