CVE-2026-31866: flagd Feature Flag Daemon DoS Vulnerability

CVE-2026-31866 Overview

CVE-2026-31866 is a resource exhaustion vulnerability (CWE-770) in flagd, an open-source feature flag daemon designed with a Unix philosophy. The vulnerability allows unauthenticated attackers to cause immediate memory exhaustion and service termination by sending requests with arbitrarily large bodies to the evaluation endpoints.

flagd exposes OFREP (/ofrep/v1/evaluate/...) and gRPC (evaluation.v1, evaluation.v2) endpoints for feature flag evaluation. These endpoints are designed to be publicly accessible by client applications. Prior to version 0.14.2, the evaluation context included in request payloads was read into memory without any size restriction, creating a critical denial of service vector.

Critical Impact

A single malicious HTTP request with an oversized body can cause flagd to allocate unbounded memory, leading to immediate process termination via OOMKill in Kubernetes environments and complete service disruption.

Affected Products

• flagd versions prior to 0.14.2
• OpenFeature flagd deployments without authenticating reverse proxy
• Kubernetes-based flagd deployments exposed to untrusted networks

Discovery Timeline

• 2026-03-11 - CVE CVE-2026-31866 published to NVD
• 2026-03-12 - Last updated in NVD database

Technical Details for CVE-2026-31866

Vulnerability Analysis

This vulnerability represents a classic resource exhaustion attack vector where an application fails to impose limits on resource allocation based on untrusted input. The flagd daemon accepts evaluation requests containing context data that can be of arbitrary size. When processing these requests, the service reads the entire request body into memory without validating or limiting its size.

The lack of authentication on evaluation endpoints exacerbates the issue. While flagd can be deployed behind an authenticating reverse proxy, the endpoints themselves impose no access control by default, allowing any network-accessible attacker to exploit this vulnerability without credentials.

In containerized environments, particularly Kubernetes, the memory exhaustion triggers the Out-Of-Memory Killer (OOMKill), which terminates the flagd process. This not only disrupts feature flag evaluation but can cause cascading failures in applications dependent on flagd for feature decisions.

Root Cause

The root cause is the absence of configurable limits on request header and body sizes in the flagd service configuration. The service trusted all incoming request payloads regardless of size, directly allocating memory proportional to the request body without bounds checking. This is classified under CWE-770: Allocation of Resources Without Limits or Throttling.

Attack Vector

The attack can be executed remotely over the network without authentication. An attacker sends an HTTP request to the OFREP endpoint (/ofrep/v1/evaluate/...) or a gRPC request to the evaluation service with an extremely large body payload. The flagd service attempts to read and allocate memory for the entire payload, causing memory exhaustion.

The attack is particularly effective because:

• No authentication is required by default
• A single request is sufficient to exhaust available memory
• The attack leaves minimal forensic traces beyond memory allocation patterns

// Security patch adding configurable size limits to service configuration
// Source: https://github.com/open-feature/flagd/commit/25c5fd7e80c26eb2c00b20317b2456fe6f927ea3

 	ContextValues              map[string]any
 	HeaderToContextKeyMappings map[string]string
 	StreamDeadline             time.Duration
+	MaxRequestHeaderBytes      int64
+	MaxRequestBodyBytes        int64
 }

Source: GitHub Commit

Detection Methods for CVE-2026-31866

Indicators of Compromise

• Sudden memory spikes in flagd containers or processes
• OOMKill events in Kubernetes pod logs or system journals
• Abnormally large HTTP requests to /ofrep/v1/evaluate/ endpoints
• gRPC requests to evaluation.v1 or evaluation.v2 services with oversized payloads
• Repeated flagd process restarts or crashloops

Detection Strategies

• Monitor for HTTP requests with Content-Length headers exceeding expected thresholds (typical evaluation requests should be under 10KB)
• Configure alerting on container memory utilization approaching limits
• Implement log analysis rules to detect OOMKill events targeting flagd processes
• Use network monitoring to identify unusually large request payloads to flagd endpoints

Monitoring Recommendations

• Set up memory usage alerts for flagd containers at 70-80% threshold to detect exploitation attempts before service termination
• Enable request logging at the reverse proxy or load balancer level to capture request sizes
• Monitor Kubernetes events for OOMKilled containers in namespaces running flagd
• Implement rate limiting metrics to identify anomalous request patterns

How to Mitigate CVE-2026-31866

Immediate Actions Required

• Upgrade flagd to version 0.14.2 or later immediately
• Deploy flagd behind an authenticating reverse proxy if not already configured
• Implement network policies to restrict access to flagd endpoints from trusted sources only
• Configure resource limits on flagd containers to prevent broader infrastructure impact

Patch Information

The vulnerability is fixed in flagd version 0.14.2. The patch introduces configurable limits for maximum request header and body sizes, with secure defaults that prevent unbounded memory allocation. The fix adds two new configuration options: --max-request-body and --max-request-header.

Review the GitHub Security Advisory GHSA-rmrf-g9r3-73pm for detailed patch information.

Workarounds

• Deploy an authenticating reverse proxy (such as nginx, Envoy, or Traefik) in front of flagd with request body size limits configured
• Implement network segmentation to prevent untrusted clients from reaching flagd endpoints directly
• Configure Kubernetes NetworkPolicies to allow only authorized pods to communicate with flagd
• Use a Web Application Firewall (WAF) to enforce request size limits at the network edge

# Example nginx configuration to limit request body size
# Add to nginx.conf or server block configuration

client_max_body_size 64k;
client_body_buffer_size 64k;
client_header_buffer_size 1k;
large_client_header_buffers 4 8k;