kin-openapi CVE-2026-100353

Exploitation requires that the target application (1) uses kin-openapi version 0.136.0 through 0.148.x with openapi3filter request validation enabled, and (2) serves an OpenAPI 3.1 spec that declares an array schema WITHOUT an items definition in one of three specific locations: an array-typed query parameter, a deepObject query parameter whose object contains an array property, or an application/x-www-form-urlencoded request body whose array property sits inside an allOf, anyOf, or oneOf subschema. If none of the application's routes expose such a nil-items array schema, the vulnerable parseArray/buildResObj paths are never reached and the service is not exploitable. No authentication or user interaction is needed once a qualifying endpoint exists (PR:N/UI:N), but the victim-side spec shape is the key limiting factor that narrows real-world exposure well below what the 7.5 score implies.

This is a genuine but bounded availability-only issue. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, 7.5) accurately reflects a remotely reachable, unauthenticated, low-complexity denial of service with no confidentiality or integrity impact - the A:H is the sole driver of the HIGH score. Exploitation status is 'no public exploit identified at time of analysis': the commit ships regression tests that demonstrate the panic, but these are maintainer fix-verification tests, not a weaponized public exploit, and must NOT be conflated with a POC or active exploitation. No EPSS score was provided in the input and the CVE is not on CISA KEV, so there is no signal of in-the-wild use; this reads as a classic high-CVSS-but-DoS-only library bug rather than a top-tier emergency. The one important nuance is that reachability is conditional on the victim application's own OpenAPI spec containing a nil-items array schema in specific locations (see exploitation_conditions) - the CVSS AC:L captures attacker effort but understates this victim-side precondition, so real-world exposure is narrower than the 7.5 alone suggests. No conflicting signals in the data, but EPSS and POC status are simply absent rather than confirmed negative.

A service built on kin-openapi uses openapi3filter to validate incoming requests against an OpenAPI 3.1 spec that defines an array (query parameter, deepObject array property, or urlencoded body array inside allOf/anyOf/oneOf) without an items schema. An unauthenticated remote attacker sends a single crafted request hitting that parameter, causing parseArray or buildResObj to dereference a nil items schema and panic, crashing the request handler or process. The panic is deterministic, so repeating it keeps the service down; no authentication or user interaction is required and no POC is publicly published.