mediumCVE-2026-58471

CVE-2026-58471 GNU Wget vulnerability

GNU Wget through 1.25.0, fixed in commit c2640fe, contains a heap buffer overflow vulnerability in the convert_fname() function within src/url.c that allows remote attackers to trigger memory corruption through a server-supplied filename requiring character set conversion. When the output buffer is too small during iconv E2BIG reallocation, the reallocation logic miscalculates the remaining space, leading to a heap buffer overflow that can be exploited via a maliciously crafted server response.

ProductGNU Wget
CVSS6.0
EPSS0.00217
UpdatedJuly 12, 2026

Quick answer

GNU Wget should be reviewed and updated if it matches the affected versions. The recommended fix is to apply the vendor-supported patched version or the mitigation steps below, then retest the public website with Fixnx.

Who is affected

Affected versions

  • GNU Wget through 1.25.0

Fixed versions

  • commit c2640fe5171c59f87c58dc9fcb195b2d18b010ee

How to fix it

CVE-2026-58471 affects GNU Wget through version 1.25.0 in convert_fname() in src/url.c. A malicious or compromised server can trigger heap buffer overflow during charset conversion of a server-supplied filename, so systems that use Wget in automated fetch, mirroring, build, or deployment jobs should be prioritized. The upstream fix is commit c2640fe5171c59f87c58dc9fcb195b2d18b010ee; apply a vendor package that includes that patch, a distro backport, or a locally rebuilt Wget package containing the commit. Until a patched package is deployed, reduce use of affected Wget workflows against untrusted servers, especially downloads that trust server-supplied filenames or filename conversion.

  1. Inventory GNU Wget installations on servers, containers, CI runners, deployment images, cron jobs, backup scripts, and developer workstations.
  2. Identify Wget versions through package metadata and `wget --version`, and treat versions through 1.25.0 as affected unless the vendor package clearly backports the relevant fix.
  3. Update GNU Wget to a vendor-supported patched package or backport the upstream fix commit c2640fe5171c59f87c58dc9fcb195b2d18b010ee.
  4. Reduce exposure to downloads that trust server-supplied filenames or filename conversion until patched, and avoid using vulnerable Wget against untrusted or user-controlled URLs.
  5. Run high-risk download automation in a restricted container or sandbox with minimal credentials, filesystem access, and outbound reachability.
  6. Review recent download logs, CI artifacts, mirrors, and fetched files for unexpected servers, crafted headers, malformed Metalink data, or abnormal Wget crashes.
  7. Rebuild base images and redeploy automation hosts so patched Wget is used consistently by scripts, package mirrors, and scheduled jobs.

Scan now. Google sign-in is only needed to unlock fix guidance.

Verify the fix

  • Confirm package changelogs or source history include CVE-2026-58471 or upstream commit c2640fe5171c59f87c58dc9fcb195b2d18b010ee.
  • Confirm `wget --version` and package manager output show the patched vendor build on every affected host and container image.
  • Rerun OS package, container, and dependency scans to confirm vulnerable Wget builds are no longer reported.
  • Retest affected download, mirroring, resume, conversion, or Metalink workflows against trusted fixtures and confirm they complete without crashes or unsafe parsing behavior.
  • Document patched package versions, rebuilt images, compensating controls, and scan evidence for change tracking.

Related categories

Trusted references

FAQ

What is affected by CVE-2026-58471?

GNU Wget versions listed as affected should be reviewed: GNU Wget through 1.25.0.

What should I fix first?

Start with internet-facing sites, admin panels, login flows, plugins, themes, modules, packages, and systems that process user-controlled input or sensitive data.

How do I confirm the fix worked?

Apply the patched version or mitigation, clear caches where relevant, retest the affected workflow, and run a new Fixnx scan to verify public website exposure signals.

How are Fixnx security risk categories chosen?

Fixnx keeps one canonical risk page and assigns only broad, relevant categories such as ecosystem, technology area, or vulnerability class.