CVE-2026-31866: 
Homebrew vulnerability analysis and mitigation

CVE-2026-31866 is a denial-of-service vulnerability in flagd, the OpenFeature feature flag daemon, caused by unbounded memory allocation when processing evaluation endpoint requests. Discovered by researchers danipalli and marcozabel, it was disclosed on March 10, 2026, and affects all flagd versions prior to 0.14.2. The vulnerability carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Github Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): flagd reads the evaluation context from HTTP/gRPC request payloads directly into memory without enforcing any size limit. The affected endpoints — including OFREP HTTP endpoints (/ofrep/v1/evaluate/flags/{flagKey}, /ofrep/v1/evaluate/flags) and multiple gRPC/Connect evaluation endpoints (flagd.evaluation.v1.Service/*, flagd.evaluation.v2.Service/*) — are publicly accessible by design and require no authentication by default. An attacker can send a single POST request with an arbitrarily large body to any of these endpoints, causing flagd to allocate a corresponding amount of memory until the process is terminated (e.g., via OOMKill in Kubernetes). The fix introduced configurable MaxRequestBodyBytes (default 1,000,000 bytes) and MaxRequestHeaderBytes limits enforced via Go's http.MaxBytesHandler and http.Server.MaxHeaderBytes (GitHub Commit, GitHub Advisory).

Successful exploitation results in immediate memory exhaustion and process termination of the flagd daemon, causing a complete denial of service for all applications relying on that flagd instance for feature flag evaluation. In Kubernetes environments, this manifests as an OOMKill event. An attacker can repeatedly send oversized requests to prevent process recovery, sustaining the outage until manual intervention occurs. There is no confidentiality or integrity impact — the vulnerability is purely an availability concern (GitHub Advisory, Github Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (Github Advisory). The attack requires no authentication, no special privileges, and no user interaction, making it trivially executable by any network-accessible attacker. The EPSS score is approximately 0.059–0.113%, placing it in the 29th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog.

1. Reconnaissance: Identify internet-facing or network-accessible flagd instances using tools like Shodan or Censys, or by scanning for the default OFREP port (8016) and gRPC evaluation port. Confirm the service is running a version prior to 0.14.2.
2. Select target endpoint: Choose any publicly accessible evaluation endpoint, such as POST /ofrep/v1/evaluate/flags (bulk evaluation) or /ofrep/v1/evaluate/flags/{flagKey} (single flag), or a gRPC/Connect endpoint like flagd.evaluation.v1.Service/ResolveAll.
3. Craft oversized request: Construct an HTTP POST request with a very large JSON body in the evaluation context payload — for example, a context object with a string value of several hundred megabytes or gigabytes.
4. Send the request: Transmit the crafted request to the flagd service. Since no authentication is enforced by default, the request is accepted and the body is read entirely into memory.
5. Trigger memory exhaustion: flagd allocates memory proportional to the request body size without any limit, causing the process to exhaust available memory and be terminated (OOMKill in Kubernetes or equivalent OS-level kill).
6. Sustain denial of service: Repeat the request continuously to prevent flagd from recovering after automatic restarts, maintaining the outage until the operator patches or applies a workaround (GitHub Advisory, GitHub Commit).

• Network: Repeated large HTTP POST requests (hundreds of MB or GB in Content-Length or chunked transfer) to flagd OFREP endpoints (/ofrep/v1/evaluate/flags, /ofrep/v1/evaluate/flags/{flagKey}) or gRPC evaluation endpoints from unexpected source IPs.
• Logs: flagd process logs showing abrupt termination without graceful shutdown; Kubernetes event logs recording OOMKill events for the flagd pod; system logs showing out-of-memory process kills (oom_kill_process for the flagd binary).
• Process/Runtime: Sudden spike in flagd process memory consumption immediately preceding process termination; rapid pod restarts (CrashLoopBackOff) in Kubernetes environments correlated with large inbound requests.
• Application: Downstream applications reporting feature flag evaluation failures or timeouts coinciding with flagd process restarts (GitHub Advisory).

The primary remediation is to upgrade flagd to version 0.14.2 or later, which enforces a default maximum request body size of 1,000,000 bytes (configurable via --max-request-body / -B flag) and a default maximum header size of 1,000,000 bytes (configurable via --max-request-header / -R flag). If immediate patching is not possible, deploy flagd behind an authenticating reverse proxy that enforces request body size limits and restricts access to evaluation endpoints. Additionally, implement network-level rate limiting and request size restrictions on inbound traffic to the flagd service (GitHub Advisory, GitHub Commit).

The vulnerability was published by maintainer toddbaert on the open-feature/flagd GitHub repository on March 10, 2026, with credits to finders danipalli and marcozabel. Brief social media mentions appeared on Mastodon and Bluesky shortly after disclosure, consistent with routine CVE notification activity. No significant independent researcher commentary or major media coverage has been identified beyond standard vulnerability database aggregation.