This CVE reveals a contract violation in the error-rendering path that applications are explicitly told to use. The vulnerability lives in openapi3filter.ConvertErrors and ValidationErrorEncoder—these are the helpers meant to render validation errors to users, yet they panic when encountering a nested ParseError carrying a RequestError with a nil Parameter field. The trigger is a malformed non-string scalar in multipart/form-data, which creates a ParseError wrapping another ParseError, with the inner error containing the nil Parameter. When ConvertErrors attempts to render this, it dereferences the nil and crashes.
The critical insight is that the public-facing API surface is unsafe by default while alternative code paths—JSON bodies, or not using these helpers—operate safely. This is not merely a null dereference; it's a design failure where the documented error-handling contract cannot handle all valid internal error states the library itself can produce. The fix in version 0.141.0 addresses the symptom by adding a defensive nil-check in the error encoder, but the upstream question remains: why does the nested ParseError construction produce a RequestError with a nil Parameter in the first place? If that upstream construction wasn't hardened, expect follow-on issues through different code paths.
The CVSS 7.5 rating captures denial-of-service but undersells the real risk. For services processing multipart uploads at volume, a single malformed request per session creates ample opportunity for crash. More concerning is the information leakage vector: panic messages expose internal error structure, enabling reconnaissance about library version and active code paths. The blast radius depends entirely on whether ConvertErrors sits inside a panic recovery boundary—without one, a single request can crash the entire service.
Audit your error-handling middleware: if ConvertErrors or ValidationErrorEncoder are called without surrounding recover() protection, add it immediately. If you handle multipart/form-data uploads, test with malformed non-string scalar values in form fields to confirm your recovery boundaries hold. Consider whether alternative error-handling patterns that bypass these helpers are viable in your codebase.