Listen to this Post
The `gcr` Receiver in Flux notification-controller prior to version 1.8.3 fails to validate the `email` claim of Google OpenID Connect (OIDC) tokens used for Pub/Sub push authentication. This flaw allows any valid Google-issued token—regardless of its intended audience or service account—to successfully authenticate against the Receiver’s webhook endpoint.
To exploit this, an attacker must first know the target Receiver’s webhook URL. This URL is generated using a predictable pattern: /hook/sha256sum(token+name+namespace). The `token` is a random string stored in a Kubernetes Secret, while `name` and `namespace` are the Receiver’s metadata. There is no API or endpoint that enumerates these webhook paths. An attacker cannot discover the path without either having access to the cluster and permissions to read the Receiver’s `.status.webhookPath` in the target namespace, or obtaining the URL through other means (e.g., leaked secrets or access to Pub/Sub configuration).
If the attacker knows the URL, they can send a crafted HTTP POST request containing any valid Google-issued token. The controller will accept the token without verifying its `email` claim, triggering a reconciliation for all resources listed in the Receiver’s .spec.resources. However, the practical impact is limited because Flux reconciliation is idempotent: if the desired state in the configured sources (Git, OCI, Helm) has not changed, the reconciliation results in a no-op with no effect on the cluster state. Additionally, Flux controllers deduplicate reconciliation requests, so many requests in a short period result in only a single reconciliation being processed.
The fix in notification-controller v1.8.3 refactors the GCR Receiver authentication to allow users to extend the verification to `email` and `audience` claims in the JWT. Operators can now configure their Receiver’s secret with the expected GCP Service Account email and audience, which the controller will validate before accepting the request.
dailycve form:
Platform: Flux notification-controller
Version: Prior 1.8.3
Vulnerability : Missing email validation
Severity: Low (3.1)
date: 2026-04-09
Prediction: Patch 2026-04-09
Analytics under heading What Undercode Say:
Check notification-controller version
kubectl get deployment notification-controller -n flux-system -o jsonpath="{.spec.template.spec.containers[bash].image}"
List all Receivers in the cluster
kubectl get receivers --all-namespaces
Generate the webhook URL for a given Receiver (requires token and metadata)
token=$(kubectl get secret <receiver-secret> -n <namespace> -o jsonpath="{.data.token}" | base64 -d)
name="<receiver-name>"
namespace="<receiver-namespace>"
echo "/hook/$(echo -n "${token}${name}${namespace}" | sha256sum | cut -d' ' -f1)"
Simulate an exploit attempt using curl (requires the webhook URL and any valid Google-issued token)
curl -X POST https://<notification-controller-host>/hook/<sha256> \
-H "Authorization: Bearer <any-valid-google-oidc-token>" \
-H "Content-Type: application/json" \
-d '{"message": {"data": "test"}}'
Exploit:
- Identify a target Receiver’s webhook URL (requires cluster access or leaked secrets).
- Obtain any valid Google-issued OIDC token (e.g., from a GCP workload or user).
- Send an HTTP POST request to the webhook URL with the token in the `Authorization: Bearer` header.
- The controller accepts the token without email validation, triggering a reconciliation of the specified resources.
Protection from this CVE
- Upgrade Flux notification-controller to version 1.8.3 or later.
- For existing Receivers, configure the secret with the expected email and audience claims:
apiVersion: v1 kind: Secret metadata: name: gcr-webhook-token namespace: apps type: Opaque stringData: token: <random-token> email: <service-account>@<project>.iam.gserviceaccount.com audience: https://<hostname>/hook/<sha256(token+name+namespace)>
- Restrict network access to the notification-controller webhook endpoint using Kubernetes Network Policies.
Impact
An attacker with a valid Google-issued token and knowledge of the webhook URL can trigger unauthorized Flux reconciliations. However, due to idempotent reconciliations and request deduplication, the impact is limited to unnecessary API calls and potential noise in logs. No cluster state changes occur unless the desired state in the configured sources has actually changed. The vulnerability is rated Low severity (CVSS 3.1).
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
