CVE-2026-58470

What it actually does

GNU Wget through 1.25.0 contains a signed integer overflow in src/http.c in parse_content_range(). A malicious HTTP server, or an attacker able to modify HTTP responses in transit, can send crafted Content-Range header values that cause server-controlled arithmetic to overflow. The practical impact is undefined behavior in the Wget client, most notably incorrect range handling, download desynchronization, corrupted or incomplete downloads, or client failure. The available scoring indicates low availability impact and no confirmed confidentiality or integrity impact beyond the affected download stream.

Why it matters to the business

Systems and automation that rely on Wget to retrieve files from remote HTTP sources may receive corrupted, incomplete, or incorrectly resumed downloads when interacting with a malicious or compromised server. This can disrupt software distribution, build pipelines, update jobs, backup retrieval, data ingestion, and operational scripts that assume downloaded artifacts are complete and trustworthy. The vulnerability is not in the CISA KEV catalog, is not known to be ransomware-used, has low EPSS probability, and has no reported exploit maturity, so remediation should be prioritized through normal patch cycles unless Wget is used against untrusted HTTP endpoints or in critical automation.

How an attack unfolds

An attacker first needs to influence the HTTP response processed by an affected Wget client. This can be done by operating a malicious server that the victim downloads from, compromising a legitimate download endpoint, or modifying unencrypted HTTP traffic in transit. When the victim invokes Wget against that endpoint, the attacker returns a response containing a crafted Content-Range header with extreme or inconsistent numeric values. Wget parses those values in parse_content_range(), where signed integer arithmetic can overflow. The resulting undefined behavior can desynchronize Wget's understanding of the requested byte range versus the received body, leading to failed, corrupted, truncated, or incorrectly resumed downloads. Exploitation does not require authentication or interactive user prompts once Wget is directed to the attacker-controlled response source, but it generally requires the victim workflow to fetch content from an attacker-influenced HTTP response.

How to fix it

Upgrade GNU Wget to a version that includes the upstream fix for commit 43d3ba9, or apply the vendor backport containing that fix. Because no package-specific fixed versions were provided, use distribution advisories to identify the corrected package release for each operating system or container base image. Where immediate patching is not possible, reduce exposure by avoiding downloads from untrusted HTTP endpoints, preferring HTTPS with certificate validation, disabling or tightly controlling resume/range-based download workflows where feasible, validating downloaded artifacts with cryptographic hashes or signatures, and isolating automation that retrieves files from external sources. Rebuild container images, CI runners, appliances, and base images that bundle Wget, since vulnerable copies are often inherited indirectly.

How to confirm the fix worked

Confirm the installed Wget version and vendor package revision using commands such as `wget --version` and the platform package manager. Treat upstream GNU Wget versions through 1.25.0 as affected unless the distributor documents a backported fix for commit 43d3ba9. Validate that patched systems include the corrected src/http.c behavior from the upstream fix or vendor advisory. For operational validation, test representative download workflows against benign HTTP responses containing unusual but non-malicious Content-Range values and confirm Wget fails safely rather than producing corrupted or desynchronized output. Also verify that automation checks cryptographic hashes or signatures before using downloaded files.

Typical attack path

1. Identify a target workflow, script, package retrieval job, or user that uses GNU Wget through 1.25.0 to download files over HTTP or from an attacker-influenced server.
2. Host malicious content, compromise a legitimate download endpoint, or position on path for plaintext HTTP traffic.
3. Return an HTTP response that includes a malformed or extreme Content-Range header designed to trigger signed integer overflow during range parsing.
4. Allow the affected Wget client to parse the response in parse_content_range().
5. Cause undefined behavior such as download desynchronization, failed transfer, corrupted output, or incorrect resume behavior.
6. Rely on downstream automation to consume the corrupted or incomplete downloaded file, if the attacker’s objective is operational disruption or artifact tampering of the download process.

How to detect it

To determine whether exploitation may already have occurred, focus on environments where Wget downloaded content over HTTP or from untrusted servers. Review proxy, web gateway, packet capture, and server logs for HTTP responses to Wget clients that contain malformed, inconsistent, negative, or extremely large Content-Range values. Correlate those events with endpoint logs, CI/CD job logs, cron output, package retrieval logs, and application logs showing Wget transfer failures, resumed downloads, unexpected file sizes, checksum mismatches, archive extraction failures, or downstream parsing errors. On endpoints, review shell history, automation logs, and process execution telemetry for Wget invocations against suspicious or newly introduced URLs. Because no public exploit pattern, threat actor campaign, or stable payload signature is currently identified, detection should emphasize behavioral evidence: anomalous Content-Range headers followed by corrupted or failed downloads. For HTTPS traffic, network devices will generally need TLS inspection or endpoint-side logs to observe response headers.

What your security team should do

• Inventory systems, containers, build agents, CI/CD jobs, appliances, and scripts that include or invoke GNU Wget.
• Prioritize patching where Wget retrieves files from external, third-party, user-controlled, or plaintext HTTP sources.
• Upgrade to a vendor package that includes the upstream fix for commit 43d3ba9, or deploy a patched Wget build.
• Require HTTPS with certificate validation for automated downloads wherever possible; avoid plaintext HTTP for software, configuration, and data retrieval.
• Add hash or signature verification to workflows that consume files downloaded by Wget, especially software packages, scripts, models, archives, and configuration files.
• Review critical automation for use of resume/range download behavior and disable it where it is not needed.
• Rebuild container images and golden machine images after patching so vulnerable Wget binaries are not reintroduced.
• Monitor for anomalous Wget failures, repeated resumed downloads, corrupted artifacts, and HTTP responses with unusually large or malformed Content-Range headers.