CVE-2026-58469

What it actually does

GNU Wget through 1.25.0 contains a heap buffer underread in src/metalink.c within clean_metalink_string(). When Wget processes a Metalink document supplied by a remote server, a URL field containing only whitespace can cause pointer arithmetic to move before the beginning of the allocated buffer. This results in memory corruption and can cause abnormal process behavior, most plausibly a denial of service through Wget crash or instability. The provided CVSS vector indicates network exploitation with low attack complexity, no privileges, no user interaction, and high availability impact, with no stated confidentiality or integrity impact.

Why it matters to the business

Systems, scripts, package workflows, CI/CD jobs, backup jobs, or automation that use vulnerable Wget versions to retrieve Metalink files from untrusted or compromised servers may be interrupted by crashes or unreliable behavior. The operational risk is highest where Wget is part of unattended automation, because a malicious or compromised download endpoint could repeatedly break retrieval workflows. This vulnerability is not listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so urgency is moderate unless Metalink downloads are used in business-critical automation or against untrusted sources.

How an attack unfolds

An attacker positions a malicious HTTP, HTTPS, or FTP server, compromises a legitimate download endpoint, or influences a victim workflow to retrieve an attacker-controlled Metalink document. The victim runs a vulnerable Wget version with Metalink support enabled or otherwise processes a Metalink response. The malicious Metalink document includes a URL element whose value is entirely whitespace. During parsing, Wget calls clean_metalink_string(), which attempts to trim or normalize the string and decrements a pointer past the start of the buffer. This corrupts memory and can cause Wget to crash or behave unpredictably, disrupting the download process. There is no public indication in the provided data of active exploitation or mature exploit tooling.

How to fix it

Upgrade GNU Wget to a version that includes the upstream fix from commit 37a40fc or apply the vendor-provided security update for the operating system or distribution package. If a fixed package version is not yet available, rebuild Wget from a patched upstream source that includes the fix, or temporarily avoid processing Metalink documents from untrusted sources. Where feasible, disable Metalink usage in automation, remove reliance on Metalink files from untrusted locations, pin downloads to trusted HTTPS endpoints, and use network allowlisting for download infrastructure. Treat Wget bundled inside containers, appliances, build images, and developer tooling as separately patchable assets, because embedded copies may not be updated by host operating system patching alone.

How to confirm the fix worked

Confirm the installed Wget version and package build include the fix for commit 37a40fc. Use package manager metadata, vendor advisories, binary provenance, or source package changelogs to verify the patched build rather than relying only on version strings if a distribution backported the fix. Inventory systems, containers, CI runners, build images, and automation hosts for Wget versions through 1.25.0. Review scripts and scheduled jobs for Metalink usage, including invocations with --metalink or downloads of .metalink or .meta4 files. In a controlled test environment only, validate that a patched Wget handles a Metalink document containing a whitespace-only URL without crashing. Monitor for Wget crashes or abnormal exits after Metalink downloads as potential exposure signals.

Typical attack path

1. Identify targets or automation workflows that use GNU Wget through 1.25.0 to process Metalink documents.
2. Host or inject a malicious Metalink document containing a whitespace-only URL field.
3. Cause the target to retrieve the malicious Metalink document from the attacker-controlled or compromised server.
4. Wget parses the Metalink content and passes the whitespace-only URL to clean_metalink_string().
5. The vulnerable pointer decrement moves before the start of the buffer, triggering heap buffer underread and memory corruption.
6. The Wget process crashes or behaves abnormally, interrupting the download or automation workflow.

How to detect it

To determine whether exploitation may already have occurred, review endpoint, application, CI/CD, and system logs for Wget crashes or abnormal exits correlated with Metalink downloads. Useful log sources include syslog, journald, kernel crash logs, auditd or EDR process telemetry, CI runner logs, package mirror logs, web proxy logs, and HTTP server access logs for download infrastructure. Look for Wget invocations using --metalink, downloads of .metalink or .meta4 files, responses with Metalink content types, and immediate process crashes such as segmentation faults, aborts, core dumps, or nonzero exits after fetching a Metalink document. If artifacts are available, inspect retrieved Metalink files for URL elements that are empty or contain only spaces, tabs, carriage returns, or newlines. Network telemetry may show requests to untrusted hosts followed by Wget termination without successful download completion. Absence of these artifacts does not prove non-exploitation, because the main expected effect is process instability and logs may not retain the malicious document body.

• --metalink
• .metalink
• .meta4
• application/metalink+xml
• application/metalink4+xml
• <url> </url>
• <url> </url>
• <url> </url>
• clean_metalink_string
• src/metalink.c
• wget: Segmentation fault
• wget: Aborted
• segfault at
• core dumped
• SIGSEGV
• SIGABRT

What your security team should do

• Prioritize patching internet-facing, automation-heavy, CI/CD, package mirroring, backup, and build systems that use Wget to process Metalink files.
• Inventory Wget installations across hosts, containers, golden images, developer workstations, and appliances; identify versions through 1.25.0 or builds lacking commit 37a40fc.
• Apply vendor security updates or deploy a patched Wget build that includes the upstream fix.
• Temporarily restrict Metalink downloads to trusted repositories and block retrieval of Metalink documents from untrusted or user-controlled URLs.
• Review automation for --metalink usage and replace untrusted Metalink consumption with direct trusted URLs where practical.
• Add monitoring for Wget crashes, segmentation faults, abnormal terminations, and downloads of suspicious Metalink documents containing whitespace-only URL elements.
• Because this is not currently KEV-listed and has low EPSS, schedule broad remediation through normal vulnerability management, but accelerate fixes for systems where download failures would disrupt production operations.