The vulnerability identified as CVE-2026-31866 affects open-feature's flagd daemon, a feature flag evaluation service designed with a Unix philosophy and exposing HTTP (OFREP) and gRPC endpoints for client applications to evaluate feature flags. Prior to version 0.14.2, these endpoints accept evaluation context data in request payloads without any size restrictions. This lack of input size validation allows an attacker to send a single HTTP or gRPC request containing an arbitrarily large payload. Upon receiving such a request, flagd attempts to read the entire evaluation context into memory, causing uncontrolled memory allocation. This can rapidly exhaust available system memory, triggering process termination mechanisms such as the Linux OOM Killer, especially in containerized environments like Kubernetes. The endpoints themselves do not implement native authentication or access control, relying on operators to deploy flagd behind authenticating reverse proxies or similar infrastructure. This design choice increases the risk of exploitation if external protections are not properly configured. The vulnerability is classified under CWE-770 (Allocation of Resources Without Limits or Throttling). The CVSS v3.1 base score is 7.5 (high), reflecting network attack vector, no required privileges or user interaction, and a high impact on availability. No known exploits have been reported in the wild as of the publication date. The issue is resolved in flagd version 0.14.2, which presumably adds input size validation or resource throttling to prevent memory exhaustion.

The primary impact of CVE-2026-31866 is a denial-of-service (DoS) condition caused by memory exhaustion. Organizations running vulnerable versions of flagd risk service disruption when exposed to maliciously crafted requests with large payloads. In containerized or orchestrated environments like Kubernetes, this can lead to pod termination and potential cascading failures if flagd is a critical component in feature flag evaluation pipelines. The lack of native authentication on the evaluation endpoints means that any unauthenticated attacker with network access to flagd can exploit this vulnerability, increasing the attack surface. This may affect development, testing, and production environments where flagd is deployed without adequate network segmentation or access controls. While confidentiality and integrity are not directly impacted, the availability degradation can affect application behavior and user experience, especially in systems relying on feature flags for dynamic configuration and rollout. The absence of known exploits suggests limited active exploitation currently, but the ease of exploitation and high impact on availability make this a significant risk for organizations using flagd versions prior to 0.14.2.

To mitigate CVE-2026-31866, organizations should immediately upgrade flagd to version 0.14.2 or later, which contains the fix for this vulnerability. Until the upgrade can be performed, operators should implement strict network-level access controls to restrict access to flagd's evaluation endpoints, ensuring only trusted clients can connect. Deploying flagd behind an authenticating reverse proxy or API gateway that enforces authentication and rate limiting is strongly recommended to prevent unauthenticated and abusive requests. Additionally, configuring resource limits and memory quotas at the container or orchestration level (e.g., Kubernetes pod resource limits) can help contain the impact of potential memory exhaustion. Monitoring flagd logs and metrics for unusually large or frequent evaluation requests can provide early detection of exploitation attempts. Finally, reviewing and applying security best practices for feature flag management, including isolating flagd instances from public networks and minimizing exposure, will reduce risk.