CVE-2026-76905 in kin-openapi
Summary
by MITRE • 08/22/2026
kin-openapi is a Go project for handling OpenAPI files. From 0.10.0 until 0.141.0, openapi3filter.convertParseError in openapi3filter/validation_error_encoder.go dereferences e.Parameter.In without checking whether e.Parameter is nil. A malformed non-string scalar field in a multipart/form-data request body produces a nested ParseError with a nil RequestError.Parameter, and applications that render the validation error through openapi3filter.ConvertErrors or ValidationErrorEncoder panic. An unauthenticated client can repeatedly send such requests to deny service when the application lacks a recovery boundary. JSON request bodies and applications that do not use these error-rendering helpers are not affected. This issue is fixed in version 0.141.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/23/2026
The kin-openapi library, widely used in Go-based web services for parsing and validating OpenAPI specifications, contains a critical nil pointer dereference vulnerability within its request validation logic. Specifically located in the convertParseError function of the openapi3filter/validation_error_encoder.go file, this flaw affects versions ranging from 0.10.0 through 0.141.0. The core technical issue arises when the library attempts to process malformed requests that include non-string scalar fields within a multipart/form-data request body. During the validation phase, such malformed input triggers a nested ParseError structure where the inner RequestError's Parameter field is left as nil rather than being properly initialized or handled.
When an application utilizes standard error rendering helpers provided by the kin-openapi library, such as openapi3filter.ConvertErrors or ValidationErrorEncoder, these functions attempt to access properties of the e.Parameter object without first verifying its existence. Because the parameter reference is null in this specific edge case involving malformed multipart data, the Go runtime triggers a panic due to nil pointer dereference. This results in an immediate termination of the HTTP handler goroutine processing that request. Consequently, if the surrounding application framework or middleware does not implement robust recovery mechanisms to catch panics and gracefully handle them, the service may become unstable or completely unresponsive for subsequent requests depending on how the server manages worker threads and connection states.
The operational impact of this vulnerability is primarily a Denial of Service (DoS). An unauthenticated attacker can exploit this flaw by repeatedly sending crafted HTTP POST requests with multipart/form-data bodies containing specific malformed scalar fields that trigger the nil pointer condition. Each successful exploitation attempt causes the application to panic, potentially crashing the server process or exhausting available resources if recovery mechanisms are absent but not fully effective. It is important to note that this vulnerability does not affect JSON request bodies, as the code path leading to the error is specific to multipart/form-data parsing logic. Furthermore, applications that do not rely on the kin-openapi library's built-in validation and error encoding helpers for rendering responses are also immune to this specific crash vector, although they may still be vulnerable if they implement similar unchecked nil dereferences in their own custom validation code.
From a classification perspective, this vulnerability aligns with CWE-476: Nil Pointer Dereference, which describes the risk associated with using an object reference that points to no valid memory address. In terms of attack patterns, it falls under MITRE ATT&CK technique T1499: Endpoint Denial of Service, specifically involving resource exhaustion through application crashes or instability. The vulnerability highlights a common oversight in defensive programming where error handling paths assume the presence of certain data structures that may not exist during malformed input processing.
To mitigate this risk, organizations using kin-openapi must upgrade to version 0.141.0 or later, which includes the necessary null checks before dereferencing the Parameter field. For applications unable to immediately update their dependencies, implementing panic recovery middleware at the HTTP server level can provide a temporary buffer against service disruption. This involves wrapping request handlers with functions that defer recover() calls to catch panics and return appropriate error responses instead of crashing. Additionally, developers should review any custom validation logic for similar patterns where nested structs are accessed without nil checks, particularly when processing untrusted input like multipart form data. Ensuring robust error handling boundaries is essential to maintaining service availability against such exploitation attempts.