kin-openapi CVE-2026-100349

Requires an OpenAPI 3.x document whose response defines a header using a 'content' media-type object instead of a 'schema' (e.g. headers: X-Thing: content: application/json: {}), AND the application must call openapi3filter.ValidateResponse for that operation. The panic fires on every response validation for the affected operation, even when the response omits the declared header. Remote availability impact is LIMITED to applications that ingest untrusted/third-party specifications; applications using only trusted local specs are affected solely as a self-inflicted crash when the affected operation is exercised. Limiting factors: the specific header-with-content declaration must exist, response validation must be enabled/used, and attacker-driven remote triggering presupposes the app accepts externally-supplied specs. Fixed in kin-openapi 0.146.0.

The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) signals a network-reachable, unauthenticated flaw, but the AT:P (attack requirements present) flag is the decisive qualifier: exploitation only matters when an application actually ingests an untrusted/attacker-controlled OpenAPI specification that declares a response header with 'content' instead of 'schema'. Impact is availability-only (VC:N/VI:N/VA:H, CWE-476 nil-pointer panic) - there is no confidentiality or integrity exposure. The 8.2/HIGH score reflects the worst-case untrusted-spec ingestion model; for the far more common deployment where applications validate against trusted local specs, this degrades to a reliability crash triggered whenever the affected operation is exercised, not a remotely-triggerable DoS. No EPSS score was provided in the input, so exploitation probability cannot be quantified. There is no CISA KEV listing and no evidence of active exploitation; however, the fix commit publicly includes a working reproducer specification (specHeader) that deterministically triggers the panic, so a public proof-of-concept effectively exists. Net assessment: a legitimate priority for API gateways/proxies/tools that parse third-party OpenAPI documents, but a lower-urgency robustness bug for services that only load their own vetted specs. The AT:P requirement and availability-only impact argue against mass, indiscriminate exploitation.

An application (e.g., an API gateway or validation tool) ingests an untrusted OpenAPI specification that declares a 200-response header such as X-Thing using 'content' rather than 'schema'. The document passes doc.Validate, but when openapi3filter.ValidateResponse is invoked for that operation, kin-openapi passes a nil header schema to decodeValue and dereferences it, panicking and crashing the service even if the actual response never contains that header. A public reproducer (the regression-test spec) ships in the fix commit, though no weaponized exploit or active exploitation is confirmed.