high · 7.5CVE-2026-76905Aug 21, 2026

CVE-2026-76905: kin-openapi openapi3filter Nil-Pointer Panic via Malformed multipart/form-data

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

Sending a single HTTP request with a non-numeric value for an integer multipart/form-data field crashes any Go server using kin-openapi's built-in error helpers, letting an unauthenticated attacker…

Packagegithub.com/getkin/kin-openapi
Ecosystemgo
Affected>= 0.10.0, < 0.141.0
Fixed in0.141.0
CVE-2026-76905: kin-openapi openapi3filter Nil-Pointer Panic via Malformed multipart/form-data

The problem

In openapi3filter/validation_error_encoder.go, the function convertParseError dereferences e.Parameter.In without first checking whether e.Parameter is nil.

For body validation errors, *RequestError sets only RequestBody, leaving Parameter nil. The multipart decoder at req_resp_decoder.go:1549 wraps a failed part's *ParseError inside another *ParseError, satisfying the type assertion on line 119 and driving execution straight into the nil dereference on line 120.

The handler goroutine panics, and without a recover() in the middleware chain, the server process crashes the in-flight request. The attack is repeatable with a single unauthenticated HTTP request.

Proof of concept

A working proof-of-concept for CVE-2026-76905 in github.com/getkin/kin-openapi, with the exact payload below.

http
POST /upload HTTP/1.1
Host: target.example.com
Content-Type: multipart/form-data; boundary=----Boundary

------Boundary
Content-Disposition: form-data; name="age"

notanumber
------Boundary--

The root cause is a missing nil guard. The sibling path branch two lines above (line 108) already has the guard e.Parameter != nil, but the query branch on line 120 omits it. When the multipart decoder wraps a *ParseError inside another *ParseError, the type assertion on line 119 succeeds, and execution reaches e.Parameter.In with e.Parameter == nil, triggering the nil dereference (CWE-476).

The patch (commit 1d0a337) adds a single condition to the failing line: ``diff - rootErr.Kind == KindInvalidFormat && e.Parameter.In == "query" { + rootErr.Kind == KindInvalidFormat && e.Parameter != nil && e.Parameter.In == "query" { ` With that guard in place, the nil case falls through to the existing 400 Bad Request` return, and no panic occurs.

Only multipart/form-data endpoints with at least one non-string scalar property (integer, number, or boolean) are reachable; application/json bodies are unaffected because their parse errors carry a non-*ParseError cause, so the type assertion fails before the dereference.

The fix

Upgrade to github.com/getkin/kin-openapi v0.141.0 or later. The fix is a one-line nil guard in convertParseError (commit 1d0a337). As a short-term workaround, wrap your request-handler middleware with a recover() to convert the panic into a handled 500, but note this still prevents correct error rendering.

If you do not use ValidationErrorEncoder or ConvertErrors, you are not affected even on older versions.

Reporter not attributed.

References: [1][2][3][4]

Related research