GHSA-mg85-8mv5-ffjr

What it actually does

The vulnerability is a denial-of-service flaw in HashiCorp go-getter, a Go library used to retrieve files and directories from remote sources. When vulnerable versions process specially crafted input, an attacker may be able to trigger excessive resource consumption or a crash in the application that embeds the library. The impact depends on how the consuming application exposes go-getter functionality: services that accept user-controlled source URLs, archive references, or download instructions are at higher risk than applications that only use trusted, static inputs.

Why it matters to the business

Successful exploitation can make an affected application or service unavailable, interrupting automation workflows, provisioning pipelines, build systems, configuration retrieval, or other software that depends on go-getter for fetching remote content. The issue is not listed in CISA KEV and no mature public exploitation is indicated from the provided data, which lowers immediate emergency priority, but it has been public for a long time and should be remediated during normal dependency maintenance, especially where untrusted users can influence download sources.

How an attack unfolds

An attacker first identifies an application or API that uses a vulnerable version of github.com/hashicorp/go-getter and allows attacker-controlled input to reach go-getter retrieval logic. The attacker then submits a crafted source, URL, archive, or retrieval request designed to trigger the vulnerable behavior. When the application processes that input, go-getter may consume excessive CPU, memory, disk, network resources, goroutines, or otherwise enter an unstable state, causing request handling delays, worker exhaustion, process crashes, or service downtime. Exploitation generally requires a path for untrusted input to be passed into the library; applications that only fetch fixed, trusted sources are less exposed.

How to fix it

Upgrade github.com/hashicorp/go-getter to version 1.7.5 or later. Rebuild and redeploy all applications, command-line tools, containers, and automation components that vendor or statically compile the vulnerable Go module. If immediate upgrade is not possible, reduce exposure by rejecting untrusted go-getter source inputs, enforcing strict allowlists for schemes and hostnames, applying request timeouts and context cancellation, limiting archive/download sizes, constraining CPU and memory usage, rate-limiting retrieval endpoints, and isolating retrieval workers from critical application processes.

How to confirm the fix worked

Confirm dependency resolution shows github.com/hashicorp/go-getter at 1.7.5 or later using Go module inventory, software composition analysis, SBOMs, or commands such as `go list -m -json github.com/hashicorp/go-getter` within each affected build. Verify vendored dependencies and container images were rebuilt after the upgrade, not merely updated in source control. Test exposed retrieval features with expected valid inputs to ensure normal behavior, and confirm defensive controls such as input allowlists, request timeouts, size limits, and rate limits are active where untrusted input can initiate downloads.

Typical attack path

1. Find an externally reachable service, API, CI/CD component, or automation tool that uses github.com/hashicorp/go-getter.
2. Determine whether the service accepts user-controlled repository URLs, file URLs, archive paths, module sources, or other go-getter-compatible source strings.
3. Submit a crafted retrieval input intended to trigger the denial-of-service condition in the vulnerable library.
4. Cause the consuming application to allocate excessive resources, hang, fail requests, or crash.
5. Repeat or parallelize requests to prolong service disruption or exhaust worker capacity.

How to detect it

To assess prior exploitation, review application logs, API gateway logs, load balancer logs, CI/CD job logs, and system telemetry for unusual spikes in go-getter-driven retrieval requests, repeated malformed or unusual source URLs, long-running download operations, request timeouts, process restarts, out-of-memory events, worker saturation, or sudden CPU/memory/disk exhaustion correlated with user-supplied download inputs. On Linux hosts and containers, check service manager logs, Kubernetes events, container runtime logs, and kernel logs for crashes or OOM kills affecting applications that embed go-getter. Because the advisory does not provide a unique exploit string, detection should focus on behavioral indicators: repeated retrieval attempts, abnormal resource consumption, and availability failures immediately following external source-fetch requests.

• github.com/hashicorp/go-getter
• go-getter
• out of memory
• OOMKilled
• Killed process
• signal: killed
• panic:
• fatal error: out of memory
• context deadline exceeded
• request canceled
• timeout awaiting response
• too many open files
• connection reset by peer
• service unavailable
• HTTP 503
• HTTP 504

What your security team should do

• Inventory applications, containers, CI/CD tools, and automation systems that include github.com/hashicorp/go-getter.
• Prioritize remediation for internet-facing services, multi-tenant services, build systems, and APIs where users can provide source URLs or archive references.
• Upgrade github.com/hashicorp/go-getter to 1.7.5 or later and redeploy all statically linked Go binaries that include the module.
• Add compensating controls for retrieval workflows: scheme and hostname allowlists, download size limits, execution timeouts, concurrency limits, and rate limiting.
• Review logs for suspicious bursts of failed, slow, or resource-intensive retrieval requests, especially from a small set of source IPs or repeated unusual source strings.
• Track this as dependency hygiene rather than KEV-driven emergency response, unless local exposure involves unauthenticated user-controlled retrieval input.