Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-21T21:17:06.320Z",
  "pubdate": "2026-08-21T21:17:06.320Z",
  "executiveSummary": "A null pointer dereference vulnerability exists in the kin-openapi Go project, specifically within the openapi3filter.convertParseError function in openapi3filter/validation_error_encoder.go. The flaw affects versions 0.10.0 through 0.141.0.\nThe vulnerability is triggered when processing a multipart/form-data request body containing a malformed non-string scalar field, which produces a nested ParseError with a nil RequestError.Parameter. Applications rendering validation errors via openapi3filter.ConvertErrors or ValidationErrorEncoder will dereference this uninitialized pointer, resulting in an application panic.\nThe primary impact of this vulnerability is a denial of service (DoS) condition if the hosting application lacks a top-level recovery boundary. Unauthenticated remote threat actors can repeatedly transmit specially crafted multipart requests to crash the service. JSON request bodies and implementations avoiding the specified error-rendering helpers remain unaffected.\nRemediation requires upgrading the kin-openapi library to version 0.141.0 or later, where the nil check for e.Parameter has been properly implemented.",
  "technicalDetails": "The vulnerability resides in the error-encoding and conversion logic of the kin-openapi library, specifically inside openapi3filter.convertParseError located in openapi3filter/validation_error_encoder.go. Affected software versions span from 0.10.0 up to, but not including, 0.141.0.\nThe root cause of the issue is an absence of defensive null-pointer validation. When the request validation pipeline processes a multipart/form-data request body containing a malformed non-string scalar field, it generates a nested ParseError structure where the associated RequestError.Parameter field is left nil. Subsequently, when the application attempts to serialize, encode, or render the validation errors using helper functions such as openapi3filter.ConvertErrors or ValidationErrorEncoder, the code unconditionally attempts to access properties on e.Parameter (specifically e.Parameter.In) without confirming its existence.\nThe attack flow proceeds as follows: An unauthenticated remote attacker crafts an HTTP request using the multipart/form-data content-type protocol. Inside this request payload, the attacker includes a malformed non-string scalar field designed to trigger a parsing failure during the OpenAPI validation phase. The kin-openapi engine evaluates the request, encounters the parsing failure, and constructs a nested ParseError possessing a nil RequestError.Parameter pointer. When the receiving application routes this error into openapi3filter.ConvertErrors or ValidationErrorEncoder for diagnostic or response-formatting purposes, the execution context attempts to dereference the nil pointer. Because Go runtime environments panic upon encountering invalid memory address dereferences, any application lacking a robust recovery boundary (such as a deferred recovery middleware) immediately terminates.\nPrerequisites for exploitation include network exposure of an endpoint utilizing kin-openapi for request validation, the use of multipart/form-data parsing mechanisms, and the integration of vulnerable error-rendering helpers. Authentication and elevated privileges are not required, as the vector is accessible to unauthenticated clients. The post-exploitation impact is strictly limited to availability disruption via application crashes, manifesting as a denial of service vector when executed in a continuous, automated loop."
}