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
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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.35.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Helm controller is tightly integrated with the Helm SDK. A vulnerability found in the Helm SDK allows for specific data inputs to cause high memory consumption, which in some platforms could cause the controller to panic and stop processing reconciliations. Impact In a shared cluster multi-tenancy environment, a tenant could create a HelmRelease that makes the controller panic, denying all other tenants from their Helm releases being reconciled. Credits The initial crash bug was reported by oss-fuzz. The Flux Security team produced the first exploit and worked together with the Helm Security team to ensure that both projects were patched timely. For more information If you have any questions or comments about this advisory: - Open an issue in any of the affected repositories. - Contact us at the CNCF Flux Channel. References - https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=48360 - https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=44996 -…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Flux CLI allows users to deploy Flux components into a Kubernetes cluster via command-line. The vulnerability allows other applications to replace the Flux deployment information with arbitrary content which is deployed into the target Kubernetes cluster instead. The vulnerability is due to the improper handling of user-supplied input, which results in a path traversal that can be controlled by the attacker. Impact Users sharing the same shell between other applications and the Flux CLI commands could be affected by this vulnerability. In some scenarios no errors may be presented, which may cause end users not to realise that something is amiss. Workarounds A safe workaround is to execute Flux CLI in ephemeral and isolated shell environments, which can ensure no persistent values exist from previous processes. However, upgrading to the latest version of the CLI is still the recommended mitigation strategy. Credits The Flux engineering team found and patched this vulnerability. For…
Recommended action: Upgrade to 0.32.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The kustomize-controller enables the use of Kustomize’s functionality when applying Kubernetes declarative state onto a cluster. A malicious user can use a specially crafted kustomization.yaml to cause Denial of Service at controller level. In multi-tenancy deployments this can lead to multiple tenants not being able to apply their Kustomizations until the malicious kustomization.yaml is removed and the controller restarted. Impact Within the affected versions, users with write access to a Flux source are able to craft a malicious kustomization.yaml file which causes the controller to enter an endless loop. Patches This vulnerability was fixed in kustomize-controller v0.24.0 and included in flux2 v0.29.0 released on 2022-04-20. The changes introduce better handling of Kustomization files blocking references that could lead to endless loops. Credits The Flux engineering team found and patched this vulnerability. For more information If you have any questions or comments about this…
Recommended action: Upgrade to 0.29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Flux2 can reconcile the state of a remote cluster when provided with a kubeconfig with the correct access rights. Kubeconfig files can define commands to be executed to generate on-demand authentication tokens. A malicious user with write access to a Flux source or direct access to the target cluster, could craft a kubeconfig to execute arbitrary code inside the controller’s container. In multi-tenancy deployments this can also lead to privilege escalation if the controller's service account has elevated permissions. Impact Within the affected versions range, one of the permissions set below would be required for the vulnerability to be exploited: - Direct access to the cluster to create Flux Kustomization or HelmRelease objects and Kubernetes Secrets. - Direct access to the cluster to modify existing Kubernetes secrets being used as kubeconfig in existing Flux Kustomization or HelmRelease objects. - Direct access to the cluster to modify existing Flux Kustomization or HelmRelease…
Recommended action: Upgrade to 0.29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The kustomize-controller enables the use of Kustomize’s functionality when applying Kubernetes declarative state onto a cluster. A malicious user can use built-in features and a specially crafted kustomization.yaml to expose sensitive data from the controller’s pod filesystem. In multi-tenancy deployments this can lead to privilege escalation if the controller's service account has elevated permissions. Within the affected versions, users with write access to a Flux source are able to use built-in features to expose sensitive data from the controller’s pod filesystem using a malicious kustomization.yaml file. This vulnerability was fixed in kustomize-controller v0.24.0 and included in flux2 v0.29.0 released on 2022-04-20. The changes introduce a new Kustomize file system implementation which ensures that all files being handled are contained within the Kustomization working directory, blocking references to any files that do not meet that requirement. Automated tooling (e.g.…
Recommended action: Upgrade to 0.29.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.