CVE-2026-77354 in kin-openapi
Summary
by MITRE • 08/21/2026
kin-openapi is a Go project for handling OpenAPI files. From 0.124.0 until 0.142.0, openapi3filter.sliceMapToSlice in openapi3filter/req_resp_decoder.go converts attacker-controlled sparse indexes from a deepObject query parameter into a dense slice by allocating entries from zero through the largest supplied index, after which buildResObj creates another slice of the same length. This allocation occurs before schema validation, so maxItems does not prevent it. An unauthenticated client can send a small query such as param[items][50000000]=x to an endpoint whose deepObject schema contains an array, forcing multi-gigabyte heap allocation and causing an OOM kill or restart loop. Other request-body encodings and styled parameters that do not produce bracketed integer indexes are not affected. This issue is fixed in version 0.142.0.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/21/2026
The kin-openapi library, a widely used Go project for parsing and handling OpenAPI specification files, contains a critical resource exhaustion vulnerability affecting versions from 0.124.0 through 0.142.0. This flaw resides within the openapi3filter package, specifically in the sliceMapToSlice function located in req_resp_decoder.go. The vulnerability arises during the processing of deepObject query parameters that utilize bracketed integer indexes to represent array elements. When an attacker supplies a sparse index with a significantly large value, such as param[items][50000000]=x, the library interprets this not merely as a request for a single element but as an instruction to allocate memory for every position from zero up to that maximum index. This results in the creation of a dense slice containing hundreds of millions or even billions of nil entries, consuming multi-gigabytes of heap memory before any substantive data validation occurs.
The technical severity of this issue is compounded by the order of operations within the library's request processing pipeline. The massive memory allocation triggered by the sparse index conversion happens prior to schema validation checks. Consequently, constraints defined in the OpenAPI specification, such as maxItems which would normally limit the size of an array, are bypassed entirely because the slice has already been allocated and populated with empty slots before these rules can be evaluated. This design flaw allows a small, seemingly innocuous query parameter string to trigger disproportionate resource consumption on the server side. The vulnerability is specific to deepObject encoding styles that produce bracketed integer indexes; other request-body encodings or styled parameters do not exhibit this behavior, limiting the attack surface but still posing a significant risk for endpoints relying on complex array-based query structures.
From an operational perspective, this vulnerability enables a straightforward denial-of-service attack against any service utilizing kin-openapi to validate incoming requests with deepObject arrays. An unauthenticated attacker can exploit this by sending crafted HTTP requests that force the server's Go runtime to allocate excessive amounts of memory. This rapid consumption leads to out-of-memory conditions, causing application crashes, OOM kills by container orchestrators like Kubernetes, or restart loops that degrade service availability for legitimate users. The impact is particularly severe in cloud-native environments where resource limits are enforced but may still be exceeded before the process can terminate gracefully.
This vulnerability aligns with CWE-400, which describes uncontrolled resource consumption, and specifically relates to improper handling of large inputs leading to memory exhaustion. In terms of offensive security frameworks, this exploit maps to ATT&CK technique T1496, Resource Hijacking, where an attacker consumes resources to disrupt service availability rather than compromising confidentiality or integrity directly. The root cause is a failure in input validation logic that prioritizes structural parsing over constraint enforcement during the initial decoding phase.
The issue has been addressed and fixed in version 0.124.0 of kin-openapi through updates released up to version 0.142.0, which corrects the allocation behavior to respect schema constraints before memory is committed. Organizations utilizing this library should immediately upgrade to a patched version that includes these fixes. For environments where an immediate upgrade is not feasible, mitigation strategies include implementing strict rate limiting on query parameters, deploying web application firewalls with rules designed to detect unusually large integer values in array index positions within deepObject structures, and configuring container resource limits with appropriate memory thresholds to prevent single requests from exhausting the entire node's capacity. Regular auditing of third-party dependencies for similar parsing vulnerabilities is also recommended to maintain robust security postures against automated exploitation attempts.