CVE-2026-31866
Unrestricted Memory Allocation in flagd Causes Denial of Service
Publication date: 2026-03-11
Last updated on: 2026-03-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openfeature | flagd | to 0.14.2 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-31866 is a vulnerability in flagd, a feature flag daemon, where certain publicly accessible endpoints accept request payloads without any size restrictions. An attacker can send a single HTTP request with an arbitrarily large body, causing flagd to allocate a corresponding amount of memory. This leads to immediate memory exhaustion and process termination, such as an OOMKill in Kubernetes environments.
The endpoints affected include OFREP REST endpoints and gRPC evaluation services. These endpoints do not enforce native authentication or access control, relying on external infrastructure for protection. The vulnerability allows denial of service by exhausting memory resources.
The issue was fixed in flagd version 0.14.2 by introducing configurable limits on the maximum allowed sizes for HTTP request headers and bodies, rejecting requests that exceed these limits with appropriate HTTP status codes.
How can this vulnerability impact me? :
This vulnerability can cause denial of service by exhausting the memory of the flagd process. When an attacker sends a request with an excessively large payload, flagd allocates large amounts of memory, which can lead to immediate process termination.
The impact includes service disruption for all applications depending on flagd until the service is restarted. Repeated exploitation can prevent recovery, causing prolonged downtime.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by monitoring for unusually large HTTP request bodies sent to the flagd evaluation endpoints such as /ofrep/v1/evaluate/ or gRPC evaluation services. Since the vulnerability involves memory exhaustion caused by oversized requests, detection involves identifying requests with abnormally large payloads.'}, {'type': 'paragraph', 'content': 'You can use network monitoring tools or HTTP/gRPC logging to capture request sizes. For example, using curl or similar tools to test the endpoints with large payloads can help verify if the service is vulnerable.'}, {'type': 'list_item', 'content': 'Use curl to send a large HTTP request body to the OFREP endpoint and observe if the service crashes or rejects the request:'}, {'type': 'list_item', 'content': 'curl -X POST http://<flagd-host>/ofrep/v1/evaluate/flags -d @large_payload.json -H "Content-Type: application/json"'}, {'type': 'list_item', 'content': 'Monitor logs or system metrics for OOMKill events or process restarts related to flagd.'}, {'type': 'list_item', 'content': 'Use network packet capture tools like tcpdump or Wireshark to analyze request sizes to the flagd endpoints.'}] [1, 2]
What immediate steps should I take to mitigate this vulnerability?
The immediate mitigation step is to upgrade flagd to version 0.14.2 or later, where this vulnerability is fixed by introducing configurable limits on the maximum allowed sizes for HTTP request headers and bodies.
If upgrading immediately is not possible, you should deploy flagd behind an authenticating reverse proxy or similar infrastructure to restrict access to the evaluation endpoints.
Additionally, configure the new parameters to limit request sizes to prevent memory exhaustion:
- Set `MaxRequestBodyBytes` to a reasonable limit (default is 1,000,000 bytes) to reject requests with excessively large bodies.
- Set `MaxRequestHeaderBytes` to limit the size of HTTP request headers (default is 1,000,000 bytes).
These limits cause the server to reject oversized requests with appropriate HTTP status codes (413, 429, or 431), preventing memory exhaustion.
Avoid disabling these limits or setting them to very high values, as that may allow exploitation.