CVE-2026-58471

What it actually does

GNU Wget through 1.25.0 contains a heap buffer overflow in src/url.c in convert_fname(). A malicious HTTP/FTP server can return a crafted filename that requires character-set conversion; when iconv reports E2BIG and Wget reallocates the destination buffer, the remaining-space calculation can be wrong, causing writes past the heap allocation. The most likely outcomes are process crash and denial of service for the Wget invocation, with limited memory corruption possible; reliable code execution is not established and exploitation requires the victim to run Wget against attacker-controlled content.

Why it matters to the business

Systems, scripts, CI/CD jobs, update tasks, and operational automation that use Wget to retrieve untrusted or redirectable URLs can be made to crash or fail, disrupting downloads, deployments, backups, or data-ingestion workflows. Current public exploitation likelihood appears low based on the provided EPSS score, the issue is not in CISA KEV, and no exploit maturity is reported, but Wget is widely embedded in scripts and base images, so exposure can be broad even when direct business impact is usually localized to failed automation.

How an attack unfolds

An attacker hosts a malicious endpoint or compromises a server that victims fetch from with Wget. The attacker returns a response that causes Wget to derive a local output filename requiring character-set conversion. During filename conversion, the crafted byte sequence and resulting output size drive iconv into an E2BIG path where Wget expands the buffer but miscalculates the remaining writable space. Subsequent conversion output overflows the heap buffer, corrupting Wget process memory. In practical scenarios this can terminate the process and interrupt the consuming workflow; more advanced exploitation would require shaping heap state and bypassing platform memory protections, making it higher effort and less reliable.

How to fix it

Upgrade GNU Wget to a vendor package or upstream build that includes the fix from commit c2640fe; Wget versions through 1.25.0 should be considered affected unless the distribution has backported the patch. Where immediate upgrade is not possible, avoid using Wget with untrusted or user-controlled URLs, avoid server-selected filenames when feasible, use explicit output paths such as a fixed -O destination for automation, do not enable Content-Disposition-based naming unless required, restrict redirects to trusted hosts, and run Wget in a low-privilege sandbox or container with limited filesystem and network access. Rebuild container images and base images that include the vulnerable Wget binary, and ensure scripts use the patched binary rather than bundled or statically copied versions.

How to confirm the fix worked

Confirm the installed Wget package is newer than the affected range or that the distribution changelog explicitly references the backport for the convert_fname()/iconv E2BIG heap buffer overflow fix or upstream commit c2640fe. Validate all runtime locations with `wget --version`, package-manager inventory, SBOM/container image scans, and path checks such as `command -v wget` in automation contexts. For assurance, run a controlled regression test with crafted charset-conversion filenames against a patched build under AddressSanitizer or crash monitoring and confirm Wget does not report heap-buffer-overflow or abort. Re-scan container images and CI runners after rebuilds to verify no vulnerable Wget binary remains.

Typical attack path

1. Identify users, scripts, containers, or automation that invoke GNU Wget against attacker-controlled, user-supplied, or redirectable URLs.
2. Host or control a server that can return a crafted response with a filename requiring character-set conversion.
3. Induce the target to run Wget against the malicious URL, or compromise a legitimate download location used by Wget automation.
4. Return the crafted filename so Wget enters convert_fname() and triggers the iconv E2BIG reallocation path.
5. Cause a heap buffer overflow in the Wget process, typically resulting in process crash and download/job failure, with possible memory corruption side effects.

How to detect it

Review endpoint, EDR, shell history, cron/systemd timer logs, CI/CD job logs, proxy logs, and web gateway telemetry for Wget executions that contacted unfamiliar or untrusted servers shortly before crashes or failed jobs. On Linux systems, inspect kernel logs, systemd-coredump, apport/abrt, and application logs for Wget aborts, segmentation faults, heap corruption messages, or AddressSanitizer findings. Correlate crash timestamps with outbound HTTP/HTTPS/FTP requests by the wget process and response metadata involving unusual Content-Disposition filenames, non-ASCII filenames, charset conversion, or redirect chains. Because there are no known public attacker-specific indicators in the provided data, focus on behavioral evidence: Wget process crashes after downloads, core dumps containing convert_fname/url.c/iconv frames, and suspicious server-supplied filenames from external hosts.

• wget: Segmentation fault
• wget: Aborted (core dumped)
• segfault at
• comm="wget"
• systemd-coredump
• Process wget dumped core
• AddressSanitizer: heap-buffer-overflow
• heap-buffer-overflow
• convert_fname
• src/url.c
• iconv
• malloc(): corrupted top size
• malloc(): invalid size
• double free or corruption
• corrupted size vs. prev_size
• Content-Disposition: attachment; filename=

What your security team should do

• Inventory Wget installations across servers, containers, CI/CD runners, appliances, and scripts, including statically bundled copies.
• Prioritize patching systems that fetch from the internet, third-party mirrors, user-supplied URLs, or locations that may redirect to untrusted hosts.
• Upgrade or backport the fix containing upstream commit c2640fe, then rebuild and redeploy affected base images and automation environments.
• Temporarily constrain Wget usage to trusted allowlisted domains and fixed output filenames where patching cannot be completed immediately.
• Hunt for recent Wget crashes, core dumps, and failed automation runs correlated with downloads from unfamiliar or newly registered domains.
• Add process and proxy monitoring for Wget executions that follow redirects, retrieve from unusual destinations, or write server-derived filenames.
• Run Wget with least privilege and sandboxing in automated workflows to reduce the impact of memory-corruption bugs.