### 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 controller pod. This surface exists only on source-controller v1.6.0 and later, where the sparse-checkout feature was introduced. ### Patches This vulnerability was fixed in source-controller **v1.8.5**. ### Workarounds There is no in-product workaround. Users should upgrade to a patched version. As a defense-in-depth measure for the GitRepository sparse-checkout surface, a `ValidatingAdmissionPolicy` (or a third-party policy engine such as Kyverno or OPA Gatekeeper) can be deployed to reject `GitRepository` resources whose `.spec.sparseCheckout` entries contain `..` or absolute path segments. ### References - [source-controller#2054](https://github.com/fluxcd/source-controller/pull/2054) ### Credits The path traversal in the Bucket reconciler was reported by JUNYI LIU. The path traversal in the GitRepository sparse-checkout validation was found and patched by the Flux engineering team. ### 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.
### 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 controller pod. This surface exists only on source-controller v1.6.0 and later, where the sparse-checkout feature was introduced. ### Patches This vulnerability was fixed in source-controller **v1.8.5**. ### Workarounds There is no in-product workaround. Users should upgrade to a patched version. As a defense-in-depth measure for the GitRepository sparse-checkout surface, a `ValidatingAdmissionPolicy` (or a third-party policy engine such as Kyverno or OPA Gatekeeper) can be deployed to reject `GitRepository` resources whose `.spec.sparseCheckout` entries contain `..` or absolute path segments. ### References - [source-controller#2054](https://github.com/fluxcd/source-controller/pull/2054) ### Credits The path traversal in the Bucket reconciler was reported by JUNYI LIU. The path traversal in the GitRepository sparse-checkout validation was found and patched by the Flux engineering team. ### 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.
Update github.com/fluxcd/source-controller to 1.8.5 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanSource controller: Improper path handling allows traversal affects github.com/fluxcd/source-controller (go). Severity is medium. ### 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 controller pod. This surface exists only on source-controller v1.6.0 and later, where the sparse-checkout feature was introduced. ### Patches This vulnerability was fixed in source-controller **v1.8.5**. ### Workarounds There is no in-product workaround. Users should upgrade to a patched version. As a defense-in-depth measure for the GitRepository sparse-checkout surface, a `ValidatingAdmissionPolicy` (or a third-party policy engine such as Kyverno or OPA Gatekeeper) can be deployed to reject `GitRepository` resources whose `.spec.sparseCheckout` entries contain `..` or absolute path segments. ### References - [source-controller#2054](https://github.com/fluxcd/source-controller/pull/2054) ### Credits The path traversal in the Bucket reconciler was reported by JUNYI LIU. The path traversal in the GitRepository sparse-checkout validation was found and patched by the Flux engineering team. ### 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.
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/fluxcd/source-controllergo | >=0.0.17,<=1.8.4 | 1.8.5 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate github.com/fluxcd/source-controller to 1.8.5 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanSource controller: Improper path handling allows traversal affects github.com/fluxcd/source-controller (go). Severity is medium. ### 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 controller pod. This surface exists only on source-controller v1.6.0 and later, where the sparse-checkout feature was introduced. ### Patches This vulnerability was fixed in source-controller **v1.8.5**. ### Workarounds There is no in-product workaround. Users should upgrade to a patched version. As a defense-in-depth measure for the GitRepository sparse-checkout surface, a `ValidatingAdmissionPolicy` (or a third-party policy engine such as Kyverno or OPA Gatekeeper) can be deployed to reject `GitRepository` resources whose `.spec.sparseCheckout` entries contain `..` or absolute path segments. ### References - [source-controller#2054](https://github.com/fluxcd/source-controller/pull/2054) ### Credits The path traversal in the Bucket reconciler was reported by JUNYI LIU. The path traversal in the GitRepository sparse-checkout validation was found and patched by the Flux engineering team. ### 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.
AI coding agents often install or upgrade packages automatically in go. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| github.com/fluxcd/source-controllergo | >=0.0.17,<=1.8.4 | 1.8.5 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard