CVE-2026-100353 in kin-openapi
Summary
by MITRE • 10/15/2026
kin-openapi is a Go project for handling OpenAPI files. From 0.136.0 until 0.149.0, three openapi3filter decoder paths that were missed by the fix for GHSA-p6wj-qrr4-pgh5 lack a nil-items guard for legal OpenAPI 3.1 array schemas. An unauthenticated remote client can trigger a deterministic nil-pointer panic through an array query parameter, a deepObject query parameter containing an array property, or an application/x-www-form-urlencoded request body whose array property appears inside an allOf, anyOf, or oneOf subschema. The query and composed-body paths reach urlValuesDecoder.parseArray, while the deepObject path reaches buildResObj, and all pass a nil items schema into code that dereferences it. This issue is fixed in version 0.149.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The kin-openapi library serves as a critical component for Go-based applications requiring robust handling of OpenAPI specifications, facilitating the parsing and validation of API definitions against their schemas. Within versions ranging from 0.136.0 to 0.149.0, a significant security flaw exists in three specific decoder paths responsible for processing input data. These vulnerabilities stem from an incomplete remediation effort related to previous issues identified under GHSA-p6wj-qrr4-pgh5. The core technical deficiency involves the absence of nil-items guards when parsing legal OpenAPI 3.1 array schemas, which allows unauthenticated remote clients to trigger deterministic nil-pointer panics through specifically crafted inputs.
The vulnerability manifests in three distinct operational scenarios involving different input formats and parameter types. First, an attacker can exploit a standard array query parameter by supplying malformed data that forces the decoder into a state where it attempts to access properties of a nil schema object. Second, deepObject style query parameters containing nested array structures present another attack vector, as these require complex recursive parsing logic that fails when encountering undefined item schemas. Third, application/x-www-form-urlencoded request bodies become vulnerable when an array property is embedded within composed schemas such as allOf, anyOf, or oneOf subschemas. In the first two cases involving query parameters and form data, the execution flow reaches the urlValuesDecoder.parseArray function, while the deepObject path triggers buildResObj. All three paths ultimately pass a nil items schema into code segments that blindly dereference this pointer without prior validation, resulting in a runtime panic.
From an operational impact perspective, these vulnerabilities constitute denial of service conditions for any application relying on kin-openapi to validate incoming requests against OpenAPI specifications. Because the trigger is deterministic and requires no authentication, remote attackers can easily disrupt service availability by sending specific HTTP requests that cause the server process to crash or restart repeatedly. This not only affects system stability but also potentially masks other malicious activities if logging mechanisms are disrupted during the panic event. The issue aligns with CWE-476, which describes a nil pointer dereference error, and can be mapped to ATT&CK technique T1499, specifically endpoint denial of service via application layer attacks that exploit software flaws to degrade or destroy system availability.
The resolution for this vulnerability was implemented in version 0.149.0 by introducing proper null checks before accessing schema properties within the affected decoder functions. To mitigate risks associated with earlier versions, organizations must upgrade kin-openapi to at least version 0.149.0 immediately. For environments where upgrading is not feasible due to dependency constraints, implementing a reverse proxy or Web Application Firewall rule that inspects query parameters and form bodies for patterns indicative of deep nested arrays within composed schemas can provide temporary protection by blocking the malformed requests before they reach the vulnerable application logic. Regular auditing of third-party dependencies against known vulnerability databases remains essential to maintain secure API gateways.