The open-feature-operator supports referencing namespaced FeatureFlagSource or InProcessConfiguration resources across namespaces using the documented {NAMESPACE}/{NAME} annotation syntax. The operator resolves these references cluster-wide and injects their spec contents (including env vars, flagd sidecar arguments like httpSyncBearerToken, sync URIs, and supporting ConfigMaps) into workloads. In multi-tenant clusters that use namespaces as trust boundaries, a tenant with permission to deploy controller-owned workloads in their namespace can cause the operator to read and disclose another tenant's FeatureFlagSource or InProcessConfiguration spec contents. This includes inline environment variable values and bearer tokens placed directly in the CR spec. The operator's cluster-wide RBAC scope and cross-namespace resolution are intentional and documented; namespace trust boundaries are not part of its current security model. The vulnerability does not allow cross-namespace disclosure of secretKeyRef or configMapKeyRef values, as those are resolved locally by the kubelet. The prerequisite for exploitation is create permission on workload controllers in the attacker's namespace, not on FeatureFlagSource resources. The advisory recommends treating FeatureFlagSource and InProcessConfiguration spec contents as readable by anyone with read access and avoiding plaintext secrets in these specs. A future breaking change will introduce explicit cluster-scoped CRDs and remove implicit cross-namespace resolution to address this architectural issue.

On multi-tenant Kubernetes clusters that treat namespaces as trust boundaries, this vulnerability allows a tenant to disclose sensitive data from another tenant's FeatureFlagSource or InProcessConfiguration resource specs. This includes inline environment variable values, httpSyncBearerToken, and sync URIs embedded in the CR spec. Single-tenant clusters are not impacted. The vulnerability does not affect secretKeyRef or configMapKeyRef cross-namespace disclosure. There is no impact on integrity or availability, only confidentiality of spec data is affected.

No official patch or fix is currently available. Users should treat FeatureFlagSource and InProcessConfiguration spec contents as readable by anyone with read access and avoid placing plaintext secrets in these spec fields. Use valueFrom.secretKeyRef for sensitive environment variables instead of inline values, as kubelet enforces same-namespace resolution for secrets. Restrict create permissions on featureflagsources and inprocessconfigurations via RBAC where feasible, especially in multi-tenant environments that treat namespaces as trust boundaries. Monitor the project's roadmap for upcoming breaking changes introducing cluster-scoped CRDs that will remove implicit cross-namespace resolution.