MEDIUM 5.9

CVE-2026-58472: GNU Wget Heap Buffer Overflow in HTML Parsing

GNU Wget versions through 1.25.0 contain a critical memory safety flaw in how they process HTML attributes from remote servers. When Wget downloads a webpage containing specially crafted HTML attributes with many characters that need encoding, an internal counter can overflow. This causes the program to allocate less memory than needed, and subsequently writes data beyond the allocated buffer. An attacker can exploit this by hosting malicious HTML that triggers the overflow when Wget parses it, potentially causing the application to crash or allowing code execution in limited scenarios.

Source data · NVD / CISA · public domain

CVSS
3.1 · 5.9 MEDIUM · CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:H
Weaknesses (CWE)
CWE-190
Affected products
1 configuration(s)
Published / Modified
2026-07-07 / 2026-07-09

NVD description (verbatim)

GNU Wget through 1.25.0, fixed in commit dd692d9, contains a heap buffer overflow vulnerability in the html_quote_string() function in src/convert.c that allows a remote attacker to trigger memory corruption by supplying a crafted HTML attribute with a large number of characters requiring entity encoding. A server-supplied HTML attribute causes a signed integer counter to overflow during output size accumulation, resulting in an undersized heap allocation and subsequent heap buffer overflow during the copy phase.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

The vulnerability exists in the html_quote_string() function within src/convert.c of GNU Wget. During HTML attribute processing, the function accumulates the expected output size using a signed integer counter. When an HTML attribute contains a large number of characters requiring entity encoding (e.g., special characters that must be converted to HTML entities), the counter overflows. This overflow results in a severely undersized heap allocation via malloc(). Subsequently, when the function copies the encoded data into the allocated buffer, a heap buffer overflow occurs. The issue is rooted in CWE-190 (Integer Overflow or Wraparound) and has been resolved in commit dd692d9.

Business impact

Organizations relying on Wget for automated website mirroring, content downloading, or scripted web retrieval face potential service disruption. A denial-of-service scenario is most likely: malicious or compromised websites can cause Wget to crash, interrupting scheduled downloads and backup operations. In environments where Wget processes untrusted URLs at scale, this could affect infrastructure reliability. The integrity impact is limited; confidentiality is not directly threatened. For security teams, this underscores the importance of validating remote content sources and segmenting systems that fetch web content.

Affected systems

GNU Wget through version 1.25.0 is affected. Systems running older versions, development builds, or distributions that bundle Wget are in scope. This includes Linux servers, containerized environments, and any automation tooling that invokes Wget to retrieve web content. Users who have already updated to versions incorporating commit dd692d9 or later are not affected.

Exploitability

Exploitation requires user interaction or automated invocation of Wget against an attacker-controlled or compromised website. The attacker cannot exploit this in passive network listening scenarios; the target must actively use Wget to fetch content from the malicious source. The CVSS vector (AC:H) reflects this elevated complexity—the specific conditions (large encoded HTML attributes) must align precisely. While not trivial to trigger, any organization running Wget without a strict allowlist of trusted URLs faces some risk, particularly in research, security monitoring, or content aggregation workflows.

Remediation

Update GNU Wget to a version incorporating commit dd692d9 or later. Verify the specific version number against the official GNU Wget repository and release notes. As an interim mitigation, restrict Wget usage to a curated list of trusted domains and consider running Wget in a sandboxed environment (e.g., containers, VMs) to limit blast radius. Security teams should audit scripts and automation that invoke Wget and prioritize patching systems in environments handling untrusted or semi-trusted URLs.

Patch guidance

Obtain the latest GNU Wget release from the official GNU Wget website or your distribution's package repository. Confirm the version includes the fix for this vulnerability—verify against the commit hash dd692d9 if installing from source. For package-based systems (apt, yum, brew), update via standard package management once your distribution has released the patched version. Test the update in a non-production environment to ensure backward compatibility with existing scripts and workflows.

Detection guidance

Monitor system logs and process execution for crashes or abnormal terminations of Wget, particularly when processing external URLs. If Wget is instrumented with debugging symbols, look for crash dumps mentioning html_quote_string() or heap corruption. Network-level detection is difficult; focus on behavioral anomalies: unexpected memory usage spikes, frequent Wget restarts, or failed scheduled downloads. Maintain an inventory of systems running Wget and cross-reference against patched versions post-deployment.

Why prioritize this

Although CVSS 5.9 is rated MEDIUM, several factors elevate practical concern: (1) User interaction requirement and environmental specificity lower likelihood slightly, but (2) denial-of-service impact on critical download/mirror workflows is disruptive, and (3) Wget is ubiquitous in Linux environments and automation. The vulnerability is not currently listed on CISA KEV, suggesting active exploitation is not yet widespread. Organizations should prioritize patching systems that process URLs from less-trusted sources or execute Wget in production automation.

Risk score, explained

CVSS 3.1 score of 5.9 (MEDIUM) reflects a network-based attack vector, elevated complexity due to required specific HTML crafting and user action, no confidentiality breach, limited integrity impact, but high availability impact (application crash). The score appropriately captures that while exploitation is plausible, it demands specific conditions and does not enable remote code execution in typical scenarios. However, the availability component is the primary concern for ops-focused teams.

Frequently asked questions

Can this vulnerability be exploited by simply visiting a website in a web browser?

No. The vulnerability is specific to GNU Wget's HTML parsing function. Web browsers use different HTML parsers and are not affected. Only systems explicitly running Wget to fetch content from the malicious source are at risk.

Is there any evidence this vulnerability is being actively exploited in the wild?

This vulnerability is not currently listed on CISA's Known Exploited Vulnerabilities (KEV) catalog, suggesting active, widespread exploitation has not been observed at the time of publication. However, the relative ease of hosting a malicious HTML file means organizations should not wait for public exploit demonstrations before patching.

What is the difference between updating Wget and applying other mitigations?

Updating is the definitive fix. Interim mitigations—such as restricting Wget to trusted domains or running it in a sandbox—reduce exposure but do not eliminate the vulnerability. Patching should be the primary goal; mitigations are supplementary while updates roll out.

Can I detect if someone has tried to exploit this vulnerability against my systems?

Direct detection is challenging because the exploit leaves only crash artifacts or abnormal termination logs. Establish a baseline of normal Wget behavior and alert on deviations: frequent crashes, unexpected memory spikes, or failed downloads. Correlate these anomalies with access logs to identify suspicious source URLs.

This analysis is provided for informational purposes and reflects the state of the vulnerability as of the publication date. While efforts have been made to ensure accuracy, SEC.co does not guarantee completeness or absence of errors. Organizations should validate all patch version numbers and compatibility against their specific environments and the vendor's official advisory. This document does not constitute security advice; consult your organization's security and engineering teams before deploying patches in production. References to specific version numbers, commit hashes, and timeline information should be verified against GNU Wget's official repository and release notes. Source: NVD (public-domain), retrieved 2026-08-16. Analysis generated by SEC.co (claude-haiku-4-5).