Executive brief
The OpenFeature Operator, a tool used to manage feature flags in Kubernetes environments, contains a design flaw that allows users in one project (namespace) to access configuration details from another project. In multi-tenant environments where different teams share the same infrastructure, a malicious user could trick the system into revealing sensitive information like API tokens, environment variables, and internal connection strings belonging to other teams. This could lead to unauthorized access to external services or exposure of internal architectural details.
Technical details
The vulnerability is classified as CWE-668 (Exposure of Resource to Wrong Sphere) and stems from the operator's intentional but insecure support for cross-namespace resource resolution via the 'openfeature.dev/featureflagsource' annotation using '{NAMESPACE}/{NAME}' syntax. In multi-tenant Kubernetes clusters where namespaces serve as trust boundaries, an authenticated user with permissions to create workload controllers (e.g., Deployments, Jobs) in their own namespace can force the operator to materialize the spec contents of a FeatureFlagSource or InProcessConfiguration from a victim's namespace into their own workload. The disclosure surface includes inline 'spec.envVars', 'spec.httpSyncBearerToken', and sync URIs. While 'secretKeyRef' and 'configMapKeyRef' remain protected by Kubelet's local resolution, any data stored directly in the CRD spec is exposed. No patch is currently available; the vendor plans to introduce cluster-scoped CRDs to address this in a future breaking change.
Affected products
- OpenFeature open-feature-operator <= 0.9.2
Timeline
- 2026-06-04: disclosed: Initial disclosure to vendor
- 2026-07-15: advisory: GitHub Advisory published