Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/fluxcd/notification-controller < 1.8.3
Fixed in
1.8.3· Vendor fix available
Issue
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:…
Recommended action: Upgrade to 1.8.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/fluxcd/notification-controller >= 0.0.1-alpha-1, < 0.27.0
Fixed in
0.27.0· Vendor fix available
Issue
Flux controllers within the affected versions range are vulnerable to a denial of service attack. Users that have permissions to change Flux’s objects, either through a Flux source or directly within a cluster, can provide invalid data to fields .spec.interval or .spec.timeout (and structured variations of these fields), causing the entire object type to stop being processed. The issue has two root causes: a) the Kubernetes type metav1.Duration not being fully compatible with the Go type time.Duration as explained on upstream report; b) lack of validation within Flux to restrict allowed values. Workarounds Admission controllers can be employed to restrict the values that can be used for fields .spec.interval and .spec.timeout, however upgrading to the latest versions is still the recommended mitigation. Credits This issue was reported by Alexander Block (@codablock) through the Flux security mailing list (as recommended). For more information If you have any questions or comments…
Recommended action: Upgrade to 0.27.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.