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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/fluxcd/source-controller >= 0.0.17, <= 1.8.4
Fixed in
1.8.5· Vendor fix available
Issue
Impact An actor with the ability to influence the contents of a bucket referenced by a Bucket resource can cause source-controller to write fetched object data to paths outside the per-reconciliation working directory. The corruption surface is bounded by source-controller's own and downstream Flux controllers' digest verification: source-controller verifies stored artifact digests during reconciliation and rebuilds on divergence; consumers (kustomize-controller, helm-controller) verify the digest of fetched artifacts and reject mismatches. These checks prevent a manipulated artifact from reaching the cluster, but an attacker can still write files anywhere the source-controller pod has permission to write. Separately, a user with permission to create or update GitRepository resources can cause source-controller to test for the existence of paths outside the cloned repository. Because the result is exposed via the resource's status, this allows limited enumeration of file paths on the…
Recommended action: Upgrade to 1.8.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When source-controller is configured to use an Azure SAS token when connecting to Azure Blob Storage, the token was logged along with the Azure URL when the controller encountered a connection error. An attacker with access to the source-controller logs could use the token to gain access to the Azure Blob Storage until the token expires. Patches This vulnerability was fixed in source-controller v1.2.5. Workarounds There is no workaround for this vulnerability except for using a different auth mechanism such as Azure Workload Identity. Credits This issue was reported and fixed by Jagpreet Singh Tamber (@jagpreetstamber) from the Azure Arc team. References https://github.com/fluxcd/source-controller/pull/1430 For more information If you have any questions or comments about this advisory: - Open an issue in the source-controller repository. - Contact us at the CNCF Flux Channel.
Recommended action: Upgrade to 1.2.5 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/source-controller >= 0.0.1-alpha-1, < 0.30.0
Fixed in
0.30.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.30.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.