The vulnerability identified as CVE-2026-31866 affects open-feature's flagd, a feature flag daemon used to evaluate feature flags via HTTP and gRPC endpoints. Prior to version 0.14.2, the evaluation endpoints (/ofrep/v1/evaluate/... and gRPC evaluation.v1, evaluation.v2) accept evaluation context data from client requests without imposing any size restrictions. This lack of input size validation allows an attacker to craft a single HTTP request with an arbitrarily large payload. When flagd processes this request, it attempts to allocate memory proportional to the payload size, leading to uncontrolled resource consumption. This can cause immediate memory exhaustion, resulting in the termination of the flagd process, often through an out-of-memory kill (OOMKill) mechanism, especially in containerized environments like Kubernetes. Notably, flagd does not natively enforce authentication or access control on these endpoints, meaning that unless operators deploy flagd behind an authenticating reverse proxy or similar infrastructure, the endpoints are publicly accessible and vulnerable to exploitation. The vulnerability is categorized under CWE-770 (Allocation of Resources Without Limits or Throttling). The CVSS v3.1 base score is 7.5 (high severity), reflecting network attack vector, no required privileges or user interaction, and a high impact on availability. No known exploits are currently reported in the wild. The issue is resolved in flagd version 0.14.2, which introduces protections against oversized payloads and presumably improved access controls.

This vulnerability can lead to denial of service (DoS) by causing the flagd process to crash due to memory exhaustion. In environments where flagd is critical for feature flag evaluation, such as microservices architectures or continuous deployment pipelines, this can disrupt application behavior, degrade user experience, and potentially halt deployment workflows. In Kubernetes or other container orchestration platforms, OOMKills triggered by this vulnerability can cause pod restarts, increasing instability and resource consumption. Since flagd endpoints are often publicly accessible by design, attackers can exploit this remotely without authentication, amplifying the risk of widespread disruption. Organizations relying on flagd for feature management may face operational outages, increased incident response costs, and potential cascading failures in dependent systems. The absence of authentication by default further exacerbates exposure, especially if proper network segmentation or reverse proxies are not in place.

The primary mitigation is to upgrade all deployments of flagd to version 0.14.2 or later, where this vulnerability is fixed. Until upgrades can be applied, organizations should implement strict network-level access controls to restrict access to flagd evaluation endpoints, such as placing flagd behind an authenticating reverse proxy or firewall rules limiting inbound traffic to trusted clients. Rate limiting and payload size restrictions should be enforced at the proxy or API gateway level to prevent oversized requests from reaching flagd. Monitoring memory usage and setting resource limits on containers running flagd can help detect and mitigate impact from attempted exploitation. Additionally, auditing deployment configurations to ensure flagd is not exposed directly to untrusted networks is critical. Security teams should also review logs for anomalous large requests to these endpoints and prepare incident response plans for potential DoS attacks. Finally, consider implementing application-layer authentication mechanisms if not already in place to reduce unauthorized access risk.