GHSA-h9cx-xjg6-5v2w
LOWGHSA-h9cx-xjg6-5v2w is a low-severity (CVSS 3.1) Improper Authentication vulnerability in github.com/fluxcd/notification-controller. O3 Security confirms whether GHSA-h9cx-xjg6-5v2w is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Flux notification-controller GCR Receiver missing email validation allows unauthorized reconciliation triggering
Blast Radius
github.com/fluxcd/notification-controllerReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Impact
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.
Patches
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. This enables operators to configure their Receiver's secret with the expected GCP Service Account email and audience, which the controller will validate against the token's claims before accepting the request.
Email validation example:
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)>
For more information, please see the GCR Receiver documentation: https://fluxcd.io/flux/components/notification/receivers/#gcr
Credits
Thanks to Saroj Khadka for reporting this issue to the Flux Security Team.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/fluxcd/notification-controller | all versions | 1.8.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/fluxcd/notification-controller. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/fluxcd/notification-controller to 1.8.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h9cx-xjg6-5v2w is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-h9cx-xjg6-5v2w is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-h9cx-xjg6-5v2w. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-h9cx-xjg6-5v2w in your dependencies?
O3 detects GHSA-h9cx-xjg6-5v2w across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.