Severity by source
AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N
Lifecycle Timeline
4DescriptionGitHub Advisory
Flux notification-controller is the event forwarder and notification dispatcher for the GitOps Toolkit controllers. Prior to 1.8.3, the gcr Receiver type in Flux notification-controller does not validate the email claim of Google OIDC tokens used for Pub/Sub push authentication. This allows any valid Google-issued token, to authenticate against the Receiver webhook endpoint, triggering unauthorized Flux reconciliations. Exploitation requires the attacker to know the Receiver's webhook URL. The webhook path is generated as /hook/sha256sum(token+name+namespace), where the token is a random string stored in a Kubernetes Secret. There is no API or endpoint that enumerates webhook URLs. 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 config). Upon successful authentication, the controller triggers a reconciliation for all resources listed in the Receiver's .spec.resources. However, the practical impact is limited: Flux reconciliation is idempotent, so 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 cluster state. Additionally, Flux controllers deduplicate reconciliation requests, sending many requests in a short period results in only a single reconciliation being processed. This vulnerability is fixed in 1.8.3.
AnalysisAI
Flux notification-controller prior to version 1.8.3 fails to validate the email claim in Google OIDC tokens used for Pub/Sub push authentication, allowing any valid Google-issued token to trigger unauthorized reconciliations via the gcr Receiver webhook endpoint. An attacker must know or discover the webhook URL (generated from a random token stored in a Kubernetes Secret) to exploit this vulnerability; however, practical impact is severely limited because Flux reconciliations are idempotent and deduplicated, meaning unauthorized requests result in no operational changes to cluster state unless the underlying Git/OCI/Helm sources have been modified.
Technical ContextAI
Flux notification-controller is a GitOps Toolkit component that validates incoming webhook events and dispatches reconciliation requests to other Flux controllers. The vulnerability exists in the gcr Receiver type, which authenticates Pub/Sub push notifications using Google OIDC tokens. The controller should validate that the token's email claim matches an expected identity before accepting the authentication, but prior to version 1.8.3 this validation was absent. This is a CWE-287 (Improper Authentication) issue. The webhook path is derived via SHA256(token+name+namespace), creating a URL-obfuscation layer that mitigates discoverability; however, the absence of email claim validation means any valid Google-issued OIDC token (issued to any Google account) can authenticate. Affected Kubernetes cluster administrators running notification-controller as a pod would be exposed if Pub/Sub push webhook URLs are leaked or accessible to attackers with read permissions on the target namespace's Receiver resource.
RemediationAI
Vendor-released patch: Flux notification-controller version 1.8.3 or later. Users should upgrade to v1.8.3 or newer, which adds proper validation of the email claim in Google OIDC tokens before accepting Pub/Sub push authentication. Upgrades can be performed via Helm (fluxcd/flux2 chart or direct notification-controller chart) or kustomize manifests. See the official release notes at https://github.com/fluxcd/notification-controller/releases/tag/v1.8.3 and security advisory at https://github.com/fluxcd/notification-controller/security/advisories/GHSA-h9cx-xjg6-5v2w for detailed instructions. As a temporary workaround prior to upgrading, restrict network access to notification-controller webhook endpoints and ensure webhook URLs are not leaked via Git repositories, logs, or environment variable exposure.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Kamaji is the Hosted Control Plane Manager for Kubernetes. Rated critical severity (CVSS 9.9), this vulnerability is rem
Jumpserver is a popular open source bastion host, and Koko is a Jumpserver component that is the Go version of coco, ref
String filter bypass in Inspektor Gadget Kubernetes eBPF tooling before fix. Insufficient string escaping enables filter
Same weakness CWE-287 – Improper Authentication
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-21150
GHSA-h9cx-xjg6-5v2w