Cross-namespace FeatureFlagSource and InProcessConfiguration resolution exposes spec contents on multi-tenant clusters

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

The OpenFeature Operator allows users to expose feature flags to applications. In version 0.9.2 and earlier, a tenant who can create a controller-owned workload can use the openfeature.dev/featureflagsource annotation with NAMESPACE/NAME syntax to reference a FeatureFlagSource or InProcessConfiguration in another namespace. On multi-tenant clusters that use namespaces as trust boundaries, the cluster-scoped operator reads that resource and materializes spec.envVars literal values, spec.httpSyncBearerToken, sync URIs, and supporting ConfigMaps into the tenant's workload. Single-tenant clusters are not impacted, secretKeyRef and configMapKeyRef values remain namespace-local, and creating a FeatureFlagSource is not required.

Source published

17 Sep 2026 19:44:13 UTC

Source modified

18 Sep 2026 14:43:51 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 4.3 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

The OpenFeature Operator allows users to expose feature flags to applications. In version 0.9.2 and earlier, a tenant who can create a controller-owned workload can use the openfeature.dev/featureflagsource annotation with NAMESPACE/NAME syntax to reference a FeatureFlagSource or InProcessConfiguration in another namespace. On multi-tenant clusters that use namespaces as trust boundaries, the cluster-scoped operator reads that resource and materializes spec.envVars literal values, spec.httpSyncBearerToken, sync URIs, and supporting ConfigMaps into the tenant's workload. Single-tenant clusters are not impacted, secretKeyRef and configMapKeyRef values remain namespace-local, and creating a FeatureFlagSource is not required.

Source published

Sep 17, 2026, 7:44:13 PM (timezone not stated)

Source modified

Sep 18, 2026, 2:43:51 PM (timezone not stated)

Observed here

11 Nov 2026 14:00:25 UTC

Source terms

ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 3.1 · 4.3 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

The OpenFeature Operator allows users to expose feature flags to applications. In version 0.9.2 and earlier, a tenant who can create a controller-owned workload can use the openfeature.dev/featureflagsource annotation with NAMESPACE/NAME syntax to reference a FeatureFlagSource or InProcessConfiguration in another namespace. On multi-tenant clusters that use namespaces as trust boundaries, the cluster-scoped operator reads that resource and materializes spec.envVars literal values, spec.httpSyncBearerToken, sync URIs, and supporting ConfigMaps into the tenant's workload. Single-tenant clusters are not impacted, secretKeyRef and configMapKeyRef values remain namespace-local, and creating a FeatureFlagSource is not required.

Source published

17 Sep 2026 20:16:50 UTC

Source modified

24 Sep 2026 21:20:08 UTC

Observed here

25 Oct 2026 13:17:28 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 4.3 CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

## Summary A namespaced `FeatureFlagSource` or `InProcessConfiguration` resource can be referenced cross-namespace via the `openfeature.dev/featureflagsource` annotation using the documented `{NAMESPACE}/{NAME}` syntax. The operator resolves the referenced resource cluster-wide and materializes its contents (env vars, flagd sidecar arguments including `httpSyncBearerToken`, sync URIs, supporting ConfigMaps) into the referencing workload. On multi-tenant clusters that treat namespaces as trust boundaries, a tenant who can deploy a controller-owned workload in their own namespace can cause the operator to read another tenant's `FeatureFlagSource` / `InProcessConfiguration` spec contents. ## Impact - **Single-tenant clusters**: not impacted. - **Multi-tenant clusters using namespaces as trust boundaries**: tenant-to-tenant disclosure of any data placed inline in `FeatureFlagSource` / `InProcessConfiguration` spec, including `spec.envVars` literal values, `spec.httpSyncBearerToken`, and sync URIs. ## Behavior is documented The cross-namespace `{NAMESPACE}/{NAME}` annotation syntax is intentional and documented in [`docs/annotations.md`](https://github.com/open-feature/open-feature-operator/blob/main/docs/annotations.md) and [`docs/feature_flag_source.md`](https://github.com/open-feature/open-feature-operator/blob/main/docs/feature_flag_source.md). The operator's cluster-wide RBAC scope is intentional. Namespace-as-trust-boundary is not part of the operator's current stated security model. This advisory makes the tenancy assumption explicit and tracks the architectural change that will eliminate the implicit cross-namespace pattern. ## Corrections to the original report Two technical points in the original report require correction: 1. **`secretKeyRef` / `configMapKeyRef` cross-namespace disclosure is not possible via this path.** Kubelet resolves these as `LocalObjectReference` against the pod's own namespace; the operator does not bypass that. The actual disclosure surface is `FeatureFlagSource` / `InProcessConfiguration` spec contents the operator itself materializes (inline `envVars` values, `httpSyncBearerToken`, sync URIs). 2. **`create featureflagsources` is not a prerequisite.** The webhook rejects pods without OwnerReferences ([`pod_webhook.go:75-77`](https://github.com/open-feature/open-feature-operator/blob/main/internal/webhook/pod_webhook.go#L75)), so the prerequisite is `create` on a workload controller (`deployments`, `statefulsets`, `daemonsets`, `jobs`, `cronjobs`, `replicasets`) in a namespace the attacker controls. `FeatureFlagSource` create in any namespace is not required. ## Mitigations As with any Kubernetes CRD, treat the spec content of `FeatureFlagSource` and `InProcessConfiguration` as readable by anyone with read access to the resource, and don't place plaintext secrets in CR spec fields. Fields most likely to bite users: - `spec.sources[].source`, when the URI embeds credentials (e.g. `https://user:pass@host/repo`) - `spec.sources[].certPath`, if the path itself is sensitive - inline `spec.envVars[].value` (use `valueFrom.secretKeyRef` instead; kubelet enforces same-namespace resolution and the secret value is not stored in the CR) If developers treat namespaces as trust boundaries: - restrict `create` on `featureflagsources` / `inprocessconfigurations` via RBAC where feasible, ## Roadmap A future release will introduce explicit cluster-scoped CRDs (`ClusterFeatureFlagSource`, `ClusterInProcessConfiguration`) and remove implicit cross-namespace resolution. This is a breaking change tracked in [#847](https://github.com/open-feature/open-feature-operator/issues/847). ## Precedent This class of issue (authenticated namespace tenant abuses an unenforced cluster-wide surface that crosses an assumed namespace boundary) has Kubernetes precedent: CVE-2020-8554 (External IPs) was accepted as documented posture and mitigated via an opt-in admission plugin. ## Credit Reported by @0xVijay. Thanks for the disclosure. This appears to be an example of https://cwe.mitre.org/data/definitions/668.html. In terms of how it ended up here, it's more of an unimplemented security feature than an "bug". It seems to deviate from reasonable expectations and conventions in the K8s ecosystem. See https://nvd.nist.gov/vuln/detail/cve-2020-8554 as an example of a comparable vulnerability.

Source published

15 Jul 2026 22:44:48 UTC

Source modified

21 Jul 2026 19:19:14 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N

Publisher rating · MODERATE

open-feature-operator: Cross-namespace FeatureFlagSource and InProcessConfiguration resolution exposes spec contents on multi-tenant clusters in github.com/open-feature/open-feature-operator

Source published

17 Jul 2026 19:42:05 UTC

Source modified

21 Jul 2026 19:15:34 UTC

Observed here

24 Oct 2026 13:19:41 UTC

Source terms

OSV · upstream source license applies

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · OSV · upstream source license applies. Source text is retained; field grouping and change labels are provided by ChangeIntel.