CVE-2026-40109: 
vulnerability analysis and mitigation

CVE-2026-40109 is an improper authentication vulnerability in Flux notification-controller's gcr Receiver type, where Google OIDC tokens used for Pub/Sub push authentication are not validated against the email claim. This allows any valid Google-issued OIDC token — regardless of the associated service account — to authenticate against the Receiver webhook endpoint and trigger unauthorized Flux reconciliations. The vulnerability affects all versions of github.com/fluxcd/notification-controller prior to 1.8.3, and was disclosed on April 9, 2026, with a patch released the same day. It carries a CVSS v3.1 base score of 3.1 (Low) (GitHub Advisory, GitHub Security Advisory).

The root cause is classified under CWE-287 (Improper Authentication) and CWE-345 (Insufficient Verification of Data Authenticity). The gcr Receiver type validates that an incoming JWT is a legitimate Google-issued OIDC token but fails to verify the email claim, meaning any Google account or service account can present a valid token and be accepted. The webhook path is constructed as /hook/sha256sum(token+name+namespace), where token is a random string stored in a Kubernetes Secret, providing security-through-obscurity as the primary access control. Exploitation requires the attacker to already know this webhook URL — obtainable only via cluster access with permissions to read .status.webhookPath, or through leaked secrets or Pub/Sub configuration (GitHub Security Advisory, GitHub Advisory).

Successful exploitation allows an attacker to trigger unauthorized Flux reconciliations for all resources listed in the Receiver's .spec.resources. However, the practical impact is significantly limited: Flux reconciliation is idempotent, so if the desired state in configured sources (Git, OCI, Helm) has not changed, the reconciliation is a no-op with no effect on cluster state. Additionally, Flux controllers deduplicate reconciliation requests, meaning a flood of requests results in only a single reconciliation being processed. There is no confidentiality or availability impact; the integrity impact is low and constrained to potentially forcing an unscheduled reconciliation cycle (GitHub Security Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (GitHub Advisory). The EPSS score is approximately 0.012–0.018%, placing it in the 5th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is further constrained by the high attack complexity — the attacker must possess a valid Google-issued OIDC token and independently know the target webhook URL, which is not discoverable through any public API or enumeration endpoint.

1. Obtain a valid Google OIDC token: Acquire any valid Google-issued OIDC token, for example by authenticating as any Google account or GCP service account using standard Google OAuth2/OIDC flows.
2. Discover the webhook URL: Obtain the Receiver's webhook path (/hook/<sha256sum>) through one of the following means: gaining cluster access with permissions to read the Receiver's .status.webhookPath in the target namespace, or finding the URL in leaked secrets, environment variables, or Pub/Sub push subscription configuration.
3. Craft the HTTP request: Send an HTTP POST request to the discovered webhook endpoint, including the obtained Google OIDC token as a Bearer token in the Authorization header.
4. Trigger unauthorized reconciliation: The notification-controller, lacking email claim validation, accepts the token as valid and triggers a reconciliation for all resources listed in the Receiver's .spec.resources, potentially forcing an unscheduled sync from the configured Git, OCI, or Helm sources (GitHub Security Advisory).

• Logs: Unexpected or anomalous reconciliation events in notification-controller logs originating from the /hook/ endpoint at unusual times or frequencies; JWT email claims in access logs that do not match the expected GCP service account (e.g., not <service-account>@<project>.iam.gserviceaccount.com).
• Network: Inbound HTTP POST requests to /hook/<sha256hash> endpoints from unexpected source IPs or at unexpected times, particularly those not originating from Google Pub/Sub infrastructure IP ranges.
• Kubernetes Events: Unexpected Reconciling or ReconcileSucceeded events for Flux resources (e.g., GitRepository, HelmRelease, Kustomization) outside of normal commit or schedule-driven cycles.

Upgrade fluxcd/notification-controller to version v1.8.3 or later, which refactors GCR Receiver authentication to validate both email and audience claims in the JWT (v1.8.3 Release). After upgrading, configure the Receiver's Kubernetes Secret with the expected GCP Service Account email and audience fields to enforce strict claim validation:

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://<host>/hook/<path>

As an interim measure, ensure the webhook URL is not exposed in any accessible configuration, logs, or Pub/Sub settings (GitHub Advisory).

The vulnerability was reported to the Flux Security Team by Saroj Khadka and was published by Flux maintainer Stefan Prodan on April 9, 2026. The fix was implemented by Matheus Pimenta via PR #1279 and reviewed and approved by Stefan Prodan prior to the advisory's public release (Fix PR, GitHub Security Advisory). No significant broader community or media reactions have been identified beyond the standard advisory publication.