go-getter CVE-2026-19585: S3 and GCS Downloads Write Outside the Folder

On 8 October 2026 HashiCorp published HCSEC-2026-44 for go-getter, the Go library many infrastructure tools use to fetch modules, plugins and artifacts. CVE-2026-19585 is a path traversal in S3 and GCS directory downloads: an object name in the bucket could make go-getter write a file outside the destination directory. Three weeks earlier, HCSEC-2026-39 (CVE-2026-88922) fixed a second bug, where files extracted from archives kept permission bits beyond read, write and execute.

go-getter is a library, so the fix only reaches you when the tools that embed it are rebuilt. That's the part worth checking.

What's affected

CVE-2026-19585. In directory mode, go-getter lists the objects under a prefix and writes each into the local destination. It didn't check that each object's destination stayed inside that directory. In the bulletin's words, "An attacker who can influence an object name in a bucket that an application retrieves in directory mode may cause files to be written outside that destination, subject to the downloader's filesystem permissions." Single-object downloads are not affected.

CVE-2026-88922. When extracting an archive, go-getter applied the permission metadata stored in each entry without limiting it to standard read, write and execute bits. A crafted archive could create files with elevated permission bits, and a local user with access to the destination could use them to gain the privileges of the account that ran the extraction. HashiCorp notes that extracting only trusted archives, or extracting as an unprivileged user into a directory other users can't reach, means no meaningful exposure.

Both were reported by Kris Kennaway. If CVE-2026-19585 looks familiar, it's the same bug class Argo Workflows fixed in its artifact drivers in September: bucket object keys treated as safe relative paths.

How to check if you're exposed

Start with your own Go code:

go list -m all | grep hashicorp/go-getter

In go-getter v2 the S3 and GCS getters are separate modules, go-getter/s3/v2 and go-getter/gcs/v2, and both have v2.2.5 tags. Check them too.

Then check the binaries you run but didn't build. Go embeds module versions in every binary, so you can read them without source:

for b in /usr/local/bin/* ~/go/bin/*; do
  v=$(go version -m "$b" 2>/dev/null | awk '/hashicorp\/go-getter/ {print $2, $3}')
  [ -n "$v" ] && echo "$b: $v"
done

Run the same loop inside the container images your CI uses for infrastructure jobs. Any binary reporting go-getter below 1.8.10 or v2 below 2.2.5 has the vulnerable code compiled in.

For a sense of how slowly a library fix spreads: on 18 October, the go.mod on the main branch of Terraform pinned go-getter v1.8.6, OpenTofu pinned v1.8.8, Packer pinned go-getter/v2 v2.2.4, and Nomad pinned v1.8.10. Pinning an older version doesn't by itself make a tool exploitable. That depends on whether it downloads S3 or GCS sources in directory mode, or extracts untrusted archives as a privileged user. But it tells you which vendors to ask.

What to do now

1. Update your own modules: go get github.com/hashicorp/go-getter@v1.8.10 or go get github.com/hashicorp/go-getter/v2@v2.2.5, plus the s3/v2 and gcs/v2 modules if you use them. Rebuild and redeploy.
2. Inventory third-party binaries with the loop above and track each vendor's release that picks up the fix.
3. Control who can write to buckets you download from as directories. The attack needs influence over object names. A module or artifact bucket that many teams can write to is the risky shape. Give each producer its own prefix and write permission only there.
4. Run downloads as an unprivileged user in a fresh, private directory. That caps the path traversal at what that user can write, and removes the local-user angle on the archive permission bug.
5. Expect one behavior change. After 1.8.9 and 2.2.4, extracted files keep only standard permission bits. Anything that relied on archives setting setuid or similar bits will stop working, which is the point.

Why it matters

Infrastructure tooling downloads a lot of code: modules, providers, plugins, job artifacts. Much of it comes through a handful of shared libraries, so one bug in a fetcher shows up in many tools at once, and each tool ships the fix on its own schedule. A dependency scan of your repositories won't see a vulnerable library compiled into a CLI on a build agent. Reading the module list out of the binary does.

The bug itself keeps recurring because object storage keys look like paths without being validated like paths. Any code that turns a remote listing into local files needs the same containment check as archive extraction: resolve the final path, confirm it is inside the destination, and refuse anything that isn't.

Try it yourself

Run the go version -m loop on one CI runner image and save the output. Then feed the same list of module versions into a dependency scan, or generate an SBOM from the image, and compare. Any go-getter version the binary loop found but the repository scan missed is a gap in what you're tracking.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• HCSEC-2026-44: go-getter path traversal in S3/GCS directory download handling
• HCSEC-2026-39: go-getter privilege escalation in archive decompression handling
• go-getter releases
• Terraform go.mod
• OpenTofu go.mod
• Packer go.mod
• Nomad go.mod