CVE-2026-100352

## 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 reache