CVE-2026-40109: Improper Authentication in Flux notification-controller GCR Receiver

The Flux notification-controller component manages event forwarding and dispatching for GitOps Toolkit controllers. Prior to version 1.8.3, the Google Container Registry (GCR) Receiver implementation contained an improper authentication vulnerability. This flaw resides in the handling of Google OpenID Connect (OIDC) tokens submitted via Pub/Sub push notifications.

The vulnerability, tracked as CVE-2026-40109, allows unauthorized principals to trigger Flux reconciliation processes. The root cause is a failure to properly implement identity binding during JWT verification. Specifically, the software checks that the token is signed by a trusted issuer but omits validation of the recipient and the subject.

The severity is classified as Low (CVSS 3.1) due to mitigating factors inherent to Flux's design. Successful exploitation requires prior knowledge of a high-entropy webhook URL. Furthermore, unauthorized reconciliations are generally benign because the operation is idempotent and state modifications only occur if the underlying Git or OCI source has changed.

This vulnerability exposes affected systems to unauthorized API invocation. It highlights the critical difference between verifying cryptographic signatures and verifying identity authorizations in modern authentication protocols.

The flaw manifests in the authenticateGCRRequest function responsible for validating incoming webhook payloads from Google Cloud Pub/Sub. When Pub/Sub dispatches a push notification, it includes a JSON Web Token (JWT) in the HTTP Authorization header. The unpatched controller uses the https://oauth2.googleapis.com/tokeninfo endpoint to verify the cryptographic signature of this token.

Relying solely on the tokeninfo endpoint confirms that the token was generated by Google, but it does not evaluate the claims within the payload. In a multi-tenant OIDC architecture like Google Cloud, verifying the issuer (iss) claim is insufficient for authentication. Google issues valid OIDC tokens to millions of distinct entities, including personal Gmail accounts and isolated GCP projects.

A secure OIDC implementation requires validating the identity (email or sub) and the intended audience (aud). Because the controller lacked these explicit checks, it accepted any Google-signed token. The system incorrectly mapped the possession of a valid generic token to authorization for the specific GCR Receiver endpoint.

The only protective measure was the obfuscation of the webhook path, generated as /hook/sha256sum(token+name+namespace). While this URL is difficult to brute-force, security through obscurity provides no defense if the URL is leaked through logs or misconfigured access controls. Once the endpoint is known, the application layer authentication completely fails.

The vulnerable implementation lacked local JWT parsing capabilities and delegated validation to a generic Google API endpoint. This approach obscured the token claims from the controller logic, preventing granular access control. The patch introduced in version 1.8.3 replaces the remote endpoint check with local validation using the google.golang.org/api/idtoken library.

Commit 61b0521f3c7678ea2460a7ac06844b8d94c1140b implements the strict enforcement of standard OIDC claims. The refactored authenticateGCRRequest function now requires expectedEmail and expectedAudience parameters. It explicitly extracts the JWT payload and verifies the issuer against accounts.google.com or https://accounts.google.com.

Crucially, the patch introduces logic to verify that the token belongs to the expected Service Account. The code extracts the email and email_verified claims from the parsed token and compares them against the configured values. The email_verified claim must be explicitly true.

The following snippet demonstrates the core validation logic added in the patch. The implementation now explicitly rejects requests if the email does not match the configured Service Account, eliminating the vulnerability.

// New validation logic in version 1.8.3
func authenticateGCRRequest(ctx context.Context, bearer string, expectedEmail string, expectedAudience string) error {
    const bearerPrefix = "Bearer "
    if !strings.HasPrefix(bearer, bearerPrefix) {
        return fmt.Errorf("the Authorization header is missing or malformed")
    }
    token := bearer[len(bearerPrefix):]
 
    v, err := idtoken.NewValidator(ctx)
    if err != nil {
        return fmt.Errorf("cannot create ID token validator: %w", err)
    }
    payload, err := v.Validate(ctx, token, expectedAudience)
    if err != nil {
        return fmt.Errorf("invalid ID token: %w", err)
    }
 
    // Verify the token issuer.
    issuer, _ := payload.Claims["iss"].(string)
    if issuer != "accounts.google.com" && issuer != "https://accounts.google.com" {
        return fmt.Errorf("token issuer is '%s', want 'accounts.google.com' or 'https://accounts.google.com'", issuer)
    }
 
    // Verify the token was issued for the expected service account.
    email, _ := payload.Claims["email"].(string)
    emailVerified, _ := payload.Claims["email_verified"].(bool)
    if expectedEmail != "" && email != expectedEmail {
        return fmt.Errorf("token email is '%s', want '%s'", email, expectedEmail)
    }
    if !emailVerified {
        return fmt.Errorf("token email '%s' is not verified", email)
    }
    return nil
}

Exploitation of CVE-2026-40109 requires the attacker to fulfill two primary prerequisites. First, the attacker must discover the specific URL of the target Flux GCR Receiver webhook. Second, the attacker must possess or generate a valid Google OIDC token.

An attacker can generate a valid token using any standard Google account or a separate Google Cloud Service Account under their control. The specific permissions associated with the account do not matter, as the unpatched controller does not inspect the token's origin. The attacker packages this token into the Authorization header as a Bearer token.

The exploit is delivered via an HTTP POST request to the discovered webhook URL. Upon receiving the request, the notification-controller queries the Google token info endpoint, receives a confirmation of the signature validity, and authorizes the request.

Once authorized, the controller executes a reconciliation loop for all resources specified in the Receiver's .spec.resources array. Current vulnerability intelligence, including data from VulnCheck and CISA, indicates no known weaponized exploits or active exploitation in the wild, largely due to the low impact and the prerequisite of discovering the webhook URL.

The vulnerability exposes the notification-controller to unauthorized API invocation, resulting in a CVSS v3.1 base score of 3.1. The vector string CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N reflects the network attack vector, high attack complexity (due to the obfuscated URL), and low integrity impact. There is no direct impact on confidentiality or availability.

The concrete security consequences of this flaw are highly constrained by the design of the GitOps Toolkit. The notification-controller performs state reconciliations, which are inherently idempotent operations. Triggering a reconciliation via the webhook forces the system to compare the current cluster state against the defined source state in the Git or OCI repository.

If the source state has not been modified by an authorized user, the unauthorized reconciliation attempt results in a no-op. The attacker cannot inject arbitrary configuration data, alter container images, or access sensitive cluster resources. The attack only forces an early execution of a process that runs on a schedule regardless.

Additionally, Flux controllers implement event deduplication. If an attacker attempts to degrade performance by flooding the webhook endpoint with authenticated requests, the controller collapses the requests and processes a single reconciliation event. This behavior effectively neutralizes potential denial-of-service vectors associated with the unauthorized triggers.

The primary remediation strategy is upgrading the fluxcd/notification-controller component to version 1.8.3 or later. This update replaces the vulnerable authentication mechanism with strict OIDC claim validation. Organizations utilizing Flux should deploy the updated manifests via their standard GitOps pipelines.

Upgrading the controller binary is necessary but insufficient to fully resolve the vulnerability. Administrators must also update the configuration of existing GCR Receivers. The Kubernetes Secret associated with each Receiver must be updated to include an email key, which specifies the authorized GCP Service Account email used for the Pub/Sub subscription.

If custom audiences are utilized within the GCP Pub/Sub configuration, the Secret must also include an audience key. When the audience key is absent, the updated controller falls back to reconstructing the expected audience from the request URL, which aligns with standard Pub/Sub behavior but may not cover advanced deployments.

In environments where an immediate upgrade is not feasible, mitigation options are limited. The system relies entirely on the secrecy of the webhook URL. Administrators should rotate the webhook tokens stored in the Kubernetes Secrets to invalidate any potentially leaked URLs, ensuring the new tokens are securely managed.