GNU wget, the command line downloader that ships with nearly every Linux distribution and turns up in countless build scripts and cron jobs, can be talked into performing roughly 2.1 billion pointless hash calculations by a single number from a hostile server. CERT Polska disclosed the flaw on August 25 as CVE-2026-16599, after coordinating the report with the wget project. Every version through 1.25.0 is affected.
A challenge number nobody bounded
The problem sits in wget's support for OPIE and S/KEY, two older one-time-password schemes sometimes used for FTP logins. Those schemes work by hashing a secret a set number of times, and the server tells the client how many rounds to run by sending a sequence number in its challenge. wget took that number and used it directly as the loop counter for an MD5 key derivation, without ever checking whether it was reasonable. CERT Polska classes it as CWE-606, unchecked input for a loop condition, which is precisely what it is.
A malicious FTP server, or an attacker positioned on the network to tamper with FTP traffic, can send a crafted OPIE challenge carrying a sequence number close to INT_MAX. wget will obediently start grinding through up to about 2.1 billion MD5 operations, and stop doing anything else until it finishes.
Why the timeout does not save you
The obvious defence is the one that does not work. wget's --timeout option governs only network input and output, not computation. Once the process is inside the hashing loop it is not waiting on the network, so the timeout never fires. A script that fetches a file with a generous timeout and assumes it will either succeed or give up will instead sit there burning a core.
This is a denial of service rather than code execution, and the scope is genuinely narrow. The vulnerable code path is FTP only, so anything fetching over HTTPS is out of reach, and the attacker has to control or intercept the FTP server being contacted. But the shape of the exposure is worth thinking about. Automated jobs that pull from FTP mirrors, unattended and unwatched, are exactly where a process quietly stalling for a long time goes unnoticed longest.
The fix is a commit, not a release
Here is the awkward part. CERT Polska says the issue was fixed in commit e9697d98e7249b0f68a6be040a4f3dcc5bc101fa, and lists all versions through 1.25.0 as vulnerable. It does not name a fixed release. Until one lands and distributions pick it up, the practical options are configuration rather than patching: prefer HTTPS over FTP wherever the source offers it, restrict which FTP endpoints automated jobs are allowed to reach, and treat the OPIE authentication path as something you do not need unless you know that you do. Anyone building wget from source can take the commit directly. This is the same upstream lag that keeps surfacing in long-lived open source tooling, where a fix can exist for years without reaching the version people actually run.
The report came from Michał Majchrowicz and Marcin Wyczechowski of the AFINE Team, who brought it through the coordinated disclosure process run by CERT Polska, Poland's national CERT.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. Indicators of compromise are defanged; re-arm them only in controlled environments. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.