Public mode

No access to your tenant or devices. Every item links to its source. What this means

Some sources, documents or advisories need attention: 275/275 feeds/APIs · 462/469 docs · 8/9 advisories · checked 10:31 UTC Customize Public modeDiscuss ChangeIntel on Discord

kin-openapi openai3filter: nil-pointer panic in ConvertErrors on malformed multipart/form-data body enables unauthenticated DoS

Collected exploitation and prediction evidence

Risk source coverage

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

cve-program · CVE-2026-76905

Published

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.

Source published
21 Aug 2026 20:43:07 UTC
Source modified
25 Aug 2026 14:21:42 UTC
Observed here
23 Oct 2026 15:48:27 UTC
Source terms
CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

euvd · EUVD-2026-64150

Published

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.

EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.

Original publisher date fields

datePublished: Aug 21, 2026, 8:43:07 PM

dateUpdated: Aug 25, 2026, 2:21:42 PM

4 related source bulletins · separate from aliases

RHSA-2026:82315: Red Hat Security Advisory: Migration Toolkit for Applications

CVE-2026-33818 · CVE-2026-41178 · CVE-2026-56852 · CVE-2026-56853 · CVE-2026-56858 · CVE-2026-56859 · CVE-2026-56860 · CVE-2026-56862 · CVE-2026-73501 · CVE-2026-73502 · CVE-2026-76905 · CVE-2026-77354

RHSA-2026:87410: Red Hat Security Advisory: RHOAI 2.25.12 - Red Hat OpenShift AI

CVE-2024-12224 · CVE-2025-14920 · CVE-2025-14921 · CVE-2025-14924 · CVE-2025-14925 · CVE-2025-14926 · CVE-2025-14927 · CVE-2025-14928 · CVE-2025-14929 · CVE-2025-14930 · CVE-2025-61726 · CVE-2025-61729 · CVE-2026-5241 · CVE-2026-5497 · CVE-2026-6734 · CVE-2026-8643 · CVE-2026-9697 · CVE-2026-11822 · CVE-2026-11824 · CVE-2026-12151 · CVE-2026-12860 · CVE-2026-15143 · CVE-2026-15574 · CVE-2026-15679 · CVE-2026-15925 · CVE-2026-16221 · CVE-2026-18427 · CVE-2026-18446 · CVE-2026-18949 · CVE-2026-19481 · CVE-2026-19484 · CVE-2026-19534 · CVE-2026-25681 · CVE-2026-25960 · CVE-2026-27136 · CVE-2026-28390 · CVE-2026-28684 · CVE-2026-31812 · CVE-2026-32283 · CVE-2026-33186 · CVE-2026-33805 · CVE-2026-33811 · CVE-2026-33814 · CVE-2026-34993 · CVE-2026-39821 · CVE-2026-39852 · CVE-2026-39892 · CVE-2026-40682 · CVE-2026-41178 · CVE-2026-42502 · CVE-2026-42561 · CVE-2026-44431 · CVE-2026-44432 · CVE-2026-44660 · CVE-2026-44705 · CVE-2026-45820 · CVE-2026-47219 · CVE-2026-48526 · CVE-2026-48710 · CVE-2026-48746 · CVE-2026-49114 · CVE-2026-49825 · CVE-2026-49855 · CVE-2026-50559 · CVE-2026-54283 · CVE-2026-54399 · CVE-2026-54428 · CVE-2026-55831 · CVE-2026-55833 · CVE-2026-56121 · CVE-2026-56746 · CVE-2026-56819 · CVE-2026-56853 · CVE-2026-56858 · CVE-2026-56859 · CVE-2026-56860 · CVE-2026-56862 · CVE-2026-58059 · CVE-2026-59296 · CVE-2026-59879 · CVE-2026-59884 · CVE-2026-59885 · CVE-2026-59886 · CVE-2026-59899 · CVE-2026-62243 · CVE-2026-62384 · CVE-2026-63209 · CVE-2026-63374 · CVE-2026-65898 · CVE-2026-65918 · CVE-2026-66007 · CVE-2026-67213 · CVE-2026-67214 · CVE-2026-67312 · CVE-2026-68494 · CVE-2026-68497 · CVE-2026-68770 · CVE-2026-69097 · CVE-2026-69112 · CVE-2026-69152 · CVE-2026-69153 · CVE-2026-69243 · CVE-2026-69244 · CVE-2026-71281 · CVE-2026-73086 · CVE-2026-73088 · CVE-2026-73089 · CVE-2026-73415 · CVE-2026-73417 · CVE-2026-73502 · CVE-2026-73508 · CVE-2026-73620 · CVE-2026-73622 · CVE-2026-73623 · CVE-2026-73624 · CVE-2026-73625 · CVE-2026-73627 · CVE-2026-73646 · CVE-2026-75838 · CVE-2026-75899 · CVE-2026-75931 · CVE-2026-75975 · CVE-2026-76098 · CVE-2026-76169 · CVE-2026-76172 · CVE-2026-76222 · CVE-2026-76905 · CVE-2026-77354 · CVE-2026-77874 · CVE-2026-78676 · CVE-2026-78677 · CVE-2026-78679 · CVE-2026-78682 · CVE-2026-79674 · CVE-2026-79675 · CVE-2026-80205 · CVE-2026-81722 · CVE-2026-81724 · CVE-2026-81727 · CVE-2026-82397 · CVE-2026-82417 · CVE-2026-84292 · CVE-2026-84375 · CVE-2026-84394 · CVE-2026-84428 · CVE-2026-84445 · CVE-2026-84469 · CVE-2026-84504 · CVE-2026-84782 · CVE-2026-84961 · CVE-2026-85124 · CVE-2026-85152 · CVE-2026-85525 · CVE-2026-86049 · CVE-2026-86332 · CVE-2026-87776 · CVE-2026-87817 · CVE-2026-87819 · CVE-2026-88029 · CVE-2026-88031 · CVE-2026-89418 · CVE-2026-89425 · CVE-2026-91777 · CVE-2026-91990 · CVE-2026-92599 · CVE-2026-93599 · CVE-2026-93657 · CVE-2026-93749 · CVE-2026-96749 · CVE-2026-102831 · CVE-2026-102925 · CVE-2026-102930 · CVE-2026-102937 · CVE-2026-102938 · CVE-2026-103262 · CVE-2026-104851 · CVE-2026-105744

RHSA-2026:95517: Red Hat Security Advisory: Multicluster Global Hub 1.7.4 security update

CVE-2026-14199 · CVE-2026-15815 · CVE-2026-17183 · CVE-2026-39834 · CVE-2026-42127 · CVE-2026-63209 · CVE-2026-73501 · CVE-2026-73502 · CVE-2026-76905 · CVE-2026-77354 · CVE-2026-77405 · CVE-2026-77411 · CVE-2026-84445 · CVE-2026-88031 · CVE-2026-92542 · CVE-2026-92543

RHSA-2026:86891: Red Hat Security Advisory: RHOAI 3.5.2 - Red Hat OpenShift AI

CVE-2024-14029 · CVE-2026-13697 · CVE-2026-15679 · CVE-2026-15789 · CVE-2026-18427 · CVE-2026-19534 · CVE-2026-37237 · CVE-2026-49825 · CVE-2026-49855 · CVE-2026-54284 · CVE-2026-56859 · CVE-2026-59296 · CVE-2026-59893 · CVE-2026-62243 · CVE-2026-62384 · CVE-2026-63209 · CVE-2026-63374 · CVE-2026-66007 · CVE-2026-68494 · CVE-2026-68497 · CVE-2026-69097 · CVE-2026-69112 · CVE-2026-69152 · CVE-2026-69243 · CVE-2026-69244 · CVE-2026-71281 · CVE-2026-71491 · CVE-2026-73417 · CVE-2026-73502 · CVE-2026-73508 · CVE-2026-73646 · CVE-2026-75838 · CVE-2026-75899 · CVE-2026-75931 · CVE-2026-75975 · CVE-2026-76098 · CVE-2026-76169 · CVE-2026-76172 · CVE-2026-76222 · CVE-2026-76905 · CVE-2026-77354 · CVE-2026-77874 · CVE-2026-78676 · CVE-2026-78677 · CVE-2026-78679 · CVE-2026-78682 · CVE-2026-79674 · CVE-2026-79675 · CVE-2026-80205 · CVE-2026-81722 · CVE-2026-81724 · CVE-2026-81725 · CVE-2026-81726 · CVE-2026-81727 · CVE-2026-82397 · CVE-2026-82417 · CVE-2026-84292 · CVE-2026-84375 · CVE-2026-84381 · CVE-2026-84382 · CVE-2026-84394 · CVE-2026-84428 · CVE-2026-84445 · CVE-2026-84469 · CVE-2026-84504 · CVE-2026-84782 · CVE-2026-84961 · CVE-2026-85124 · CVE-2026-85152 · CVE-2026-85525 · CVE-2026-86332 · CVE-2026-87776 · CVE-2026-87817 · CVE-2026-87819 · CVE-2026-88029 · CVE-2026-88031 · CVE-2026-89425 · CVE-2026-91990 · CVE-2026-93348 · CVE-2026-93599 · CVE-2026-93657 · CVE-2026-93749 · CVE-2026-96749 · CVE-2026-96775 · CVE-2026-102925 · CVE-2026-102930 · CVE-2026-102937 · CVE-2026-102938 · CVE-2026-102990 · CVE-2026-104851 · CVE-2026-104852 · CVE-2026-104861 · CVE-2026-104873

Source published
Aug 21, 2026, 8:43:07 PM (timezone not stated)
Source modified
Aug 25, 2026, 2:21:42 PM (timezone not stated)
Observed here
9 Nov 2026 15:12:58 UTC
Source terms
ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

nvd · CVE-2026-76905

Published

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.

NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.

Source analysis status: Deferred

Weakness classifications: CWE-476

Original publisher date fields

published: 2026-08-21T21:17:06.320

lastModified: 2026-10-12T16:10:00.220

Source published
21 Aug 2026 21:17:06 UTC
Source modified
12 Oct 2026 16:10:00 UTC
Observed here
25 Oct 2026 16:19:04 UTC
Source terms
NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

osv · GHSA-mmfr-pmjx-hw9w

Published

### Summary A nil-pointer dereference in `openapi3filter.ConvertErrors` lets any unauthenticated client crash a server with a single HTTP request. When an application validates a `multipart/form-data` request body and renders the resulting validation error through the library-provided `ValidationErrorEncoder` / `ConvertErrors` helpers, a malformed scalar form field (e.g. a non-numeric value for an `integer` property) produces an error shape that `convertParseError` dereferences without a nil check. The handler goroutine panics, causing a denial of service. `application/json` request bodies are **not** affected — the bug is specific to `multipart/form-data`. ### Details The panic is in `convertParseError`, at [`openapi3filter/validation_error_encoder.go:119-120`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validation_error_encoder.go#L119) (still present on `master` at the time of writing): ```go } else if innerErr.RootCause() != nil { if rootErr, ok := innerErr.Cause.(*ParseError); ok && rootErr.Kind == KindInvalidFormat && e.Parameter.In == "query" { // ❌ e.Parameter may be nil → panic ``` The comparison `e.Parameter.In == "query"` assumes `e.Parameter` is non-nil. It is reached whenever **both** of the following hold: 1. **`e.Parameter == nil`.** A `*RequestError` carries *either* `Parameter` (parameter errors) *or* `RequestBody` (body errors), never both. `ValidateRequestBody` builds body errors with only `RequestBody` set, leaving `Parameter` nil — see [`validate_request.go:326-332`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validate_request.go#L326). 2. **`innerErr.Cause` is itself a `*ParseError`** (a `ParseError` nested inside a `ParseError`), so the type assertion on line 119 succeeds and execution reaches the `e.Parameter.In` dereference on line 120. The only default code path that satisfies *both* conditions is the **multipart** body decoder, which wraps a failed part's `*ParseError` inside another `*ParseError` at [`req_resp_decoder.go:1549`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L1549) and [`:1558`](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/req_resp_decoder.go#L1558): ```go if v, ok := err.(*ParseError); ok { return nil, &ParseError{path: []any{name}, Cause: v} // v is a *ParseError → nested } ``` Why other paths do **not** reach the dereference: | Body content type | Failure mode | `RequestError.Err` shape | `.Cause` is `*ParseError`? | `e.Parameter` | Panics? | |---|---|---|---|---|---| | **`multipart/form-data`** | scalar part fails primitive parse (`age=notanumber`) | `*ParseError` wrapping a `*ParseError` | **yes** | `nil` | **YES** | | `application/json` | malformed JSON syntax | `*ParseError` whose `.Cause` is an `encoding/json` error | no (assertion fails → safe fallback branch) | `nil` | no | | `application/json` | wrong type / schema violation | `*openapi3.SchemaError` (routed to `convertSchemaError`, never reaches `convertParseError`) | n/a | `nil` | no | | styled `query` / `path` params | invalid format | `*ParseError` wrapping a `*ParseError` | yes | **set (non-nil)** | no (guard/assignment succeeds) | Note that the sibling `"path"` branch two lines above ([line 108](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validation_error_encoder.go#L108)) already guards correctly with `e.Parameter != nil`; the `"query"` branch simply omits the same guard. **Recommended fix.** Add the missing nil guard to the condition: ```diff if rootErr, ok := innerErr.Cause.(*ParseError); ok && - rootErr.Kind == KindInvalidFormat && e.Parameter.In == "query" { + rootErr.Kind == KindInvalidFormat && e.Parameter != nil && e.Parameter.In == "query" { ``` When `e.Parameter == nil` the inner `if` is skipped and control falls through to the existing `return &ValidationError{Status: http.StatusBadRequest, Title: innerErr.Reason}` at [line 127-130](https://github.com/getkin/kin-openapi/blob/master/openapi3filter/validation_error_encoder.go#L127) — a correct `400 Bad Request`. I verified that applying only this one-line guard stops the panic and returns `*ValidationError{Status: 400}`. Minor follow-up worth including in the same change: for the multipart nested `*ParseError`, the *outer* `ParseError.Reason` is empty, so the fallback `Title: innerErr.Reason` yields a `400` with an **empty `Title`**. The descriptive text lives in `innerErr.Error()` (e.g. `"path age: value notanumber: an invalid integer: invalid syntax"`). Prefer a non-empty fallback: ```go title := innerErr.Reason if title == "" { title = innerErr.Error() } return &ValidationError{Status: http.StatusBadRequest, Title: title} ``` ### PoC Verified against revision `98d956447b64eaa10d3570a80b3be1a2849945f1` (also reproducible on current `master`), Go 1.25.0. **1. Spec** — one operation accepting a `multipart/form-data` body with a non-string scalar (`integer`) property: ```yaml openapi: '3.0.3' info: {title: t, version: '1.0.0'} paths: /upload: post: requestBody: required: true content: multipart/form-data: schema: type: object properties: age: {type: integer} responses: '200': {description: ok} ``` **2. Program** — validate a request whose `age` part is non-numeric, then convert the error the way a typical error-rendering middleware does: ```go package main import ( "bytes" "context" "fmt" "mime/multipart" "net/http" "github.com/getkin/kin-openapi/openapi3" "github.com/getkin/kin-openapi/openapi3filter" "github.com/getkin/kin-openapi/routers/gorillamux" ) const spec = ` openapi: '3.0.3' info: {title: t, version: '1.0.0'} paths: /upload: post: requestBody: required: true content: multipart/form-data: schema: type: object properties: age: {type: integer} responses: '200': {description: ok} ` func main() { loader := openapi3.NewLoader() doc, _ := loader.LoadFromData([]byte(spec)) _ = doc.Validate(loader.Context) router, _ := gorillamux.NewRouter(doc) // multipart body: a non-numeric value for the integer property "age" var buf bytes.Buffer w := multipart.NewWriter(&buf) _ = w.WriteField("age", "notanumber") w.Close() r, _ := http.NewRequest(http.MethodPost, "/upload", &buf) r.Header.Set("Content-Type", w.FormDataContentType()) route, pp, _ := router.FindRoute(r) reqErr := openapi3filter.ValidateRequest(context.Background(), &openapi3filter.RequestValidationInput{ Request: r, PathParams: pp, Route: route, Options: &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc}, }) fmt.Printf("ValidateRequest returned: %T\n", reqErr) // *openapi3filter.RequestError // What an application's error-rendering middleware calls: _ = openapi3filter.ConvertErrors(reqErr) // panics fmt.Println("no panic (unexpected)") } ``` **3. Observed output** (`go run .`): ``` ValidateRequest returned: *openapi3filter.RequestError panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x2 addr=0x20 pc=0x...] goroutine 1 [running]: github.com/getkin/kin-openapi/openapi3filter.convertParseError(...) .../openapi3filter/validation_error_encoder.go:120 +0x17c github.com/getkin/kin-openapi/openapi3filter.ConvertErrors(...) .../openapi3filter/validation_error_encoder.go:42 +0xec main.main() ... exit status 2 ``` The panic is at exactly `validation_error_encoder.go:120` — the unguarded `e.Parameter.In` dereference. **Control (confirms JSON is not a vector):** repeating the setup with an `application/json` body and either a malformed body (`{"age": `) or a wrong-type body (`{"age": "notanumber"}`) returns from `ConvertErrors` normally, with no panic. Only the `multipart/form-data` path crashes. In a real HTTP server, `ConvertErrors` / `ValidationErrorEncoder.Encode` runs inside the request handler, so the panic aborts the in-flight request (connection reset / 500) and, without a `recover()` in the middleware chain, is trivially repeatable. ### Impact - **Type:** Nil-pointer dereference → **unauthenticated remote denial of service**. - **Who is impacted:** any application using `github.com/getkin/kin-openapi/openapi3filter` that (1) exposes an endpoint accepting a `multipart/form-data` request body with at least one non-string scalar property (`integer` / `number` / `boolean`), **and** (2) renders validation errors through the library's own `ValidationErrorEncoder` or `ConvertErrors` helpers. These are the library's advertised error-rendering helpers, so this is a realistic default integration. - **Attack:** a single crafted, unauthenticated request (a multipart part whose value doesn't parse to the declared scalar type). No credentials, special privileges, or unusual client capabilities are required, and it is repeatable at will. - **Consequence:** the handling goroutine panics. Absent a `recover()` boundary in the application's middleware, the request is aborted; sustained requests deny service. Confidentiality and integrity are not affected. - **Not affected:** applications that only accept `application/json` bodies (verified above), applications that do not use `ConvertErrors` / `ValidationErrorEncoder` to format errors, or applications that wrap handlers in a `recover()` (which converts the crash into a handled 500 but still prevents normal error rendering).

Source published
21 Aug 2026 20:55:46 UTC
Source modified
10 Sep 2026 03:51:14 UTC
Observed here
24 Oct 2026 13:19:41 UTC
Source terms
GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Publisher rating · HIGH

osv · GO-2026-6274

Published

kin-openapi openai3filter: nil-pointer panic in ConvertErrors on malformed multipart/form-data body enables unauthenticated DoS in github.com/getkin/kin-openapi

Source published
25 Aug 2026 15:00:08 UTC
Source modified
2 Sep 2026 16:10:54 UTC
Observed here
24 Oct 2026 13:19:41 UTC
Source terms
OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.

ChangeIntel

An IT change radar: releases, security, known issues, retirements, documentation changes, and service status from public sources. Every item links to supporting evidence; dates and statuses can change after they are read.

Sources read 10 Nov 10:31 UTC · 275 of 275 readable · 273 fully read · documentation 462/469 current