CVE-2026-77354: Uncontrolled Resource Consumption (OOM) via Sparse Array Indexes in kin-openapi

The Go package kin-openapi is widely used within the Go ecosystem for handling, parsing, and validating OpenAPI v3 specifications. Within this package, the openapi3filter sub-module plays a critical role by acting as request and response validation middleware. It intercepts incoming HTTP traffic, maps parameters to their respective OpenAPI schema definitions, and evaluates them to ensure compliance before routing requests to core application logic.

A critical vulnerability exists within the query parameter parsing logic of openapi3filter, specifically affecting parameters styled as deepObject that contain arrays. When processing such parameters, the decoding engine converts HTTP query strings into nested Go map representations before transforming them into slices. If a remote, unauthenticated attacker supplies a highly sparse array index inside a query parameter, the internal conversion routine experiences uncontrolled memory allocation.

This vulnerability is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-789 (Memory Allocation with Excessive Size Value). Because the resource allocation occurs during the decoding phase, it bypasses downstream schema-defined constraints such as maxItems or length validations. Consequently, the affected process attempts to satisfy massive memory demands instantly, resulting in an immediate Out-of-Memory (OOM) abort.

The vulnerability was introduced in kin-openapi version 0.124.0 in commit 78bb273e5892da3b0c8fc31857499449adfaba6c. This commit added capabilities for handling complicated deepObject types, including arrays of nested objects and multi-dimensional arrays. When query parameter strings are parsed, standard arrays are typically received in index-value format, which the library translates into an intermediate string-keyed map, such as map[string]any with keys representing indexes (e.g. "0", "1").

To construct a contiguous Go slice from this intermediate map, openapi3filter invokes the helper function sliceMapToSlice within openapi3filter/req_resp_decoder.go. The logic converts the map's string keys into integer slice indices, determines the maximum index value (max), and then executes an allocation loop to build the final slice. However, the upper boundary of this loop is set directly to the max value extracted from client-controlled input, without verifying the total number of elements actually present in the map.

When a client transmits a request containing a single extremely high index (e.g., 50000000), the max variable is evaluated as 50000000. The function then loops from index 0 up to 50000000, filling non-existent intermediate elements with nil pointers via iterative append() operations. This behavior forces the Go runtime to iteratively grow and copy the slice within the heap, consuming substantial CPU cycles and physical RAM.

This mechanism results in severe memory amplification. While the physical HTTP payload sent by the attacker may be less than 50 bytes, the corresponding memory allocation in the application runtime climbs to several hundred megabytes or gigabytes. Furthermore, because this processing is performed during the initial request-decoding layer, any schema-level protections such as parameter constraints are completely inactive, rendering validation mechanisms ineffective.

To understand the structural failure, we can examine the vulnerable implementation of the sliceMapToSlice function in openapi3filter/req_resp_decoder.go prior to version 0.142.0:

func sliceMapToSlice(m map[string]interface{}) ([]interface{}, error) {
	var result []interface||
 
	keys := make([]int, 0, len(m))
	for k := range m {
		key, err := strconv.Atoi(k)
		if err != nil {
			return nil, fmt.Errorf("array indexes must be integers: %w", err)
		}
		keys = append(keys, key)
	}
	max := -1
	for _, k := range keys {
		if k > max {
			max = k
		}
	}
	for i := 0; i <= max; i++ {
		val, ok := m[strconv.Itoa(i)]
		if !ok {
			result = append(result, nil)
			continue
		}
		result = append(result, val)
	}
	return result, nil
}

In this version, the loop for i := 0; i <= max; i++ is completely unbounded. Each iteration where ok is false results in result = append(result, nil). This forces the runtime to dynamically reallocate and copy the underlying backing array of the slice, introducing significant memory overhead.

This allocation is followed by a secondary copy inside the buildResObj calling function. This function instantiates a secondary duplicate slice using resultArr := make([]interface{}, len(arr)) where arr is the slice returned by sliceMapToSlice. This operation duplicates the massive memory requirement, instantly doubling the heap allocation size.

To resolve this vulnerability, the maintainers implemented a density check in commit 1223a0f215d2cf9beb2d9eb9ea2649d001c21388 by capping the maximum permitted gap between the theoretical slice size and the actual number of elements provided by the client:

// maxSliceMapToSliceGap bounds how many synthesized nil holes sliceMapToSlice
// will fill in for a sparse array before rejecting the input.
const maxSliceMapToSliceGap = 10000
 
func sliceMapToSlice(m map[string]any) ([]any, error) {
	var result []any
	keys := make([]int, 0, len(m))
	for k := range m {
		key, err := strconv.Atoi(k)
		if err != nil {
			return nil, fmt.Errorf("array indexes must be integers: %w", err)
		}
		if key < 0 {
			return nil, fmt.Errorf("array indexes must not be negative: %d", key)
		}
		keys = append(keys, key)
	}
	max := -1
	for _, k := range keys {
		if k > max {
			max = k
		}
	}
	// Evaluate the gap size
	if gap := max + 1 - len(m); gap > maxSliceMapToSliceGap {
		return nil, fmt.Errorf("array index %d is too sparse relative to the %d supplied items", max, len(m))
	}
	// Array generation proceeds if gap is within limits

The introduction of maxSliceMapToSliceGap successfully limits the gap size to a maximum of 10000. By checking if gap := max + 1 - len(m); gap > maxSliceMapToSliceGap, the software rejects requests with sparse indices before entering the allocation loop. This effectively forces attackers to transmit actual payloads proportional to the requested allocation size, which is mitigated by standard HTTP server payload limits.

An attack targeting this vulnerability is easily executed, requiring no authentication, low bandwidth, and zero pre-existing session state. The target must expose an endpoint validated by openapi3filter that expects a query parameter configured with the deepObject serialization style and containing an array schema. An example OpenAPI parameter definition is shown below:

parameters:
  - name: filter
    in: query
    style: deepObject
    explode: true
    schema:
      type: object
      properties:
        items:
          type: array
          items:
            type: string

To exploit this configuration, an attacker transmits an HTTP GET request containing a parameter with a highly sparse array index, as shown in this payload:

GET /search?filter[items][50000000]=x HTTP/1.1
Host: vulnerable-service.local
Connection: close

When the application processes this request, the parameter decoder translates the key into a map: map[string]any{"50000000": "x"}. The sliceMapToSlice function reads this key, identifies 50000000 as the maximum index, and attempts to initialize a slice with 50,000,001 entries. On a 64-bit architecture, each interface slot consumes 16 bytes. The initial backing slice requires 800 megabytes. When accounting for Go runtime memory overhead, iterative slice resizing, and the secondary allocation within buildResObj, the heap immediately expands by several gigabytes, triggering the kernel's Out-Of-Memory (OOM) killer to terminate the service process.

The vulnerability poses a severe risk to service availability. Because the parsing logic is executed early in the HTTP request processing pipeline, any validation steps, authorization checks, or rate-limiting layers that operate post-decoding cannot mitigate the threat. The vulnerability can be exploited by an unauthenticated, remote attacker with minimal network footprint.

In modern containerized microservice architectures (such as Kubernetes or ECS), an OOM crash of a single pod can propagate failure throughout the cluster. If the service is behind an automated load balancer, the termination of one replica will cause the load balancer to route pending requests to the remaining healthy replicas. An attacker can continuously transmit the sparse index payload, systematically knocking out each newly spawned container and achieving a complete, sustained Denial of Service.

While this vulnerability does not lead to remote code execution or data exposure (confidentiality and integrity remain unaffected), the availability impact is severe. This is reflected in the CVSS v4.0 vector string CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N, highlighting network-based, low-complexity exploitation with high availability consequences.

To address this vulnerability, administrators and developers must upgrade github.com/getkin/kin-openapi to version 0.142.0 or higher. This release contains the patch that limits sparse array index mapping via the maxSliceMapToSliceGap safety threshold.

If immediate upgrading is not feasible, organizations can implement detection and blocking rules at the Web Application Firewall (WAF) layer. Since the exploit relies on sending extremely large integer indices inside brackets, a custom regular expression rule can inspect the query string. The following rule detects any array bracket indices containing large numerical values (10,000 or greater):

(?i)\\b\\w+\\[\\w+\\]\\[(?:[1-9]\\d{4,})\\]=

Additionally, operations teams can configure resource limit constraints on containers. While this does not prevent the target process from crashing, it prevents a single vulnerable service from consuming the host node's entire physical memory, minimizing the impact on co-located services.