CVE-2026-40109: Flux Notification-Controller Auth Bypass

CVE-2026-40109 Overview

CVE-2026-40109 is an authentication bypass vulnerability in Flux notification-controller, the event forwarder and notification dispatcher for the GitOps Toolkit controllers. Prior to version 1.8.3, the gcr Receiver type does not properly validate the email claim of Google OIDC tokens used for Pub/Sub push authentication. This improper authentication allows any valid Google-issued token to authenticate against the Receiver webhook endpoint, potentially triggering unauthorized Flux reconciliations.

Critical Impact
Attackers with a valid Google-issued OIDC token and knowledge of the webhook URL can trigger unauthorized Flux reconciliations, though practical impact is limited by Flux's idempotent reconciliation behavior.

Affected Products

Flux notification-controller versions prior to 1.8.3
GitOps Toolkit deployments using gcr Receiver type with Google Pub/Sub push authentication
Kubernetes clusters running vulnerable notification-controller instances

Discovery Timeline

2026-04-09 - CVE CVE-2026-40109 published to NVD
2026-04-09 - Last updated in NVD database

Technical Details for CVE-2026-40109

Vulnerability Analysis

This authentication bypass vulnerability (CWE-287) exists in the gcr Receiver type of Flux notification-controller. The core issue is that the controller fails to validate the email claim within Google OIDC tokens when processing Pub/Sub push authentication requests. Without proper email claim verification, any valid Google-issued token can successfully authenticate to the webhook endpoint, regardless of whether the token belongs to an authorized service account or entity.

The vulnerability requires network access and knowledge of the target webhook URL. The webhook path is cryptographically generated using the formula /hook/sha256sum(token+name+namespace), where the token is a random string stored in a Kubernetes Secret. This design provides some inherent protection as there is no API or endpoint that enumerates webhook URLs.

While the vulnerability allows triggering unauthorized reconciliations, the practical impact is constrained by Flux's architecture. Reconciliation operations are idempotent, meaning if the desired state in configured sources (Git, OCI, Helm) has not changed, the reconciliation results in a no-op with no effect on cluster state. Additionally, Flux controllers deduplicate reconciliation requests, so sending many requests in a short period results in only a single reconciliation being processed.

Root Cause

The root cause is improper authentication validation in the gcr Receiver type. The notification-controller accepts Google OIDC tokens for Pub/Sub push authentication but fails to verify that the email claim in the token corresponds to an authorized identity. This missing validation step allows any entity with a valid Google-issued token to authenticate, bypassing the intended authorization controls.

Attack Vector

The attack vector requires network access to the notification-controller's webhook endpoint. An attacker must first obtain the target Receiver's webhook URL, which can be discovered by having cluster access with permissions to read the Receiver's .status.webhookPath in the target namespace, or by obtaining the URL through other means such as leaked secrets or access to Pub/Sub configuration.

Once the webhook URL is known, the attacker can send requests with any valid Google-issued OIDC token to trigger reconciliations for all resources listed in the Receiver's .spec.resources. The attack does not require any special privileges on the token itself—only that it be validly issued by Google.

Detection Methods for CVE-2026-40109

Indicators of Compromise

Unexpected reconciliation events in Flux controller logs without corresponding Git or source changes
Authentication requests to gcr Receiver webhook endpoints from unrecognized Google service accounts
Anomalous patterns of webhook requests that do not correlate with legitimate Pub/Sub activity
Multiple reconciliation triggers from different Google OIDC token identities

Detection Strategies

Monitor notification-controller logs for authentication events from Google OIDC tokens with unexpected email claims
Implement audit logging for all webhook endpoint access and compare against known authorized service accounts
Alert on reconciliation events that occur outside of expected CI/CD pipeline activity windows
Review Kubernetes audit logs for access to Receiver .status.webhookPath resources

Monitoring Recommendations

Enable verbose logging on notification-controller to capture authentication details including token email claims
Set up alerting for repeated reconciliation requests that are deduplicated by Flux controllers
Monitor for reconnaissance activity targeting Receiver resources or Kubernetes Secrets containing webhook tokens
Implement network monitoring to detect unusual traffic patterns to webhook endpoints

How to Mitigate CVE-2026-40109

Immediate Actions Required

Upgrade Flux notification-controller to version 1.8.3 or later immediately
Audit current Receiver configurations to identify gcr Receiver types using Google Pub/Sub push authentication
Review access controls on Kubernetes Secrets containing webhook tokens and Receiver resources
Rotate webhook tokens after upgrading to invalidate any potentially leaked URLs

Patch Information

The vulnerability is fixed in Flux notification-controller version 1.8.3. The fix implements proper validation of the email claim in Google OIDC tokens, ensuring only tokens from authorized identities can authenticate to the webhook endpoint. Organizations should upgrade to this version or later to remediate the vulnerability.

For detailed patch information, see the GitHub Pull Request #1279 and the v1.8.3 Release Notes. Additional security context is available in the GitHub Security Advisory GHSA-h9cx-xjg6-5v2w.

Workarounds

Restrict network access to notification-controller webhook endpoints using Kubernetes NetworkPolicies or service mesh policies
Implement additional authentication layers at the ingress level before traffic reaches the notification-controller
Monitor and alert on all gcr Receiver webhook activity until the upgrade can be completed
Consider temporarily disabling gcr Receiver types if they are not business-critical until patching is complete

bash

# Upgrade notification-controller to patched version
flux install --components=notification-controller --version=v1.8.3

# Verify the installed version
kubectl get deployment notification-controller -n flux-system -o jsonpath='{.spec.template.spec.containers[0].image}'

# Review existing Receiver configurations for gcr type
kubectl get receivers -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}: {.spec.type}{"\n"}{end}' | grep gcr