- The Mess: A fresh vulnerability in GNU wget, tracked as CVE-2026-16599, lets a malicious FTP server turn a simple download attempt into a CPU-burning nightmare. The bug affects wget versions through 1.25.0 and was disclosed on August 25, 2026.
The vulnerable code sits in wget’s FTP OPIE/S-KEY authentication handling.
Here is the problem.
The FTP server sends a sequence number.
wget trusts it.
Way too much.
That number ends up controlling how many times wget performs an MD5-based key derivation loop. There is no proper upper limit. A malicious server can send a value close to INT_MAX.
The result?
Around 2.1 billion MD5 computations.
One bad FTP challenge can leave the wget process grinding away while the CPU does all the work.
This is not a memory corruption bug.
No RCE.
No webshell.
Just an input value that turns into an absurd amount of computation because nobody stopped to ask whether a sequence number really needs to be that large.
And there is another annoying detail.
Using wget’s --timeout option does not save you.
The timeout controls network I/O. The vulnerable operation happens after wget has already accepted the malicious input and started burning CPU cycles.
A malicious FTP server can trigger the problem directly. CERT Polska also notes that a network attacker capable of intercepting and modifying FTP traffic could inject the crafted challenge.
So yes.
Even in 2026, old-school FTP can still find creative ways to hurt you.
- The Damage: An attacker can force wget into a massive CPU workload, potentially hanging scripts, automated jobs or services that depend on it and effectively creating a denial-of-service condition.
For a desktop user, this might mean one stuck process and a screaming CPU fan.
For automation, it can be worse.
wget still appears inside scripts, cron jobs, build systems, backup processes and various bits of infrastructure that quietly fetch files from remote servers.
Imagine an automated task connecting to a hostile or compromised FTP server.
The job hangs.
CPU usage spikes.
Other work waits.
And because this is computation rather than network activity, the usual timeout setting may sit there looking completely useless.
The bug also highlights a familiar problem with security reviews.
Developers often focus on dangerous input leading to memory corruption, command injection or code execution.
Sometimes the input does something much simpler.
It tells the software:
“Do this operation two billion times.”
And the software politely obeys.
- The Fix: Update wget once a release containing the upstream fix is available, or apply the patch from commit
e9697d98e7249b0f68a6be040a4f3dcc5bc101fa; until then, avoid connecting vulnerable wget installations to untrusted FTP servers.
Administrators using wget inside automated workflows should also check whether those jobs communicate with external or third-party FTP infrastructure.
The safest script in the world cannot protect you from software blindly accepting attacker-controlled values and converting them into billions of CPU operations.
Bugstoday Opinion
This is not the sexiest CVE of the day.
Nobody gets remote root.
Nobody steals an admin session.
Nobody drops ransomware.
Instead, someone sends wget a stupidly large number and your CPU starts doing MD5 until it forgets what year it is.
But that is exactly why this bug is worth mentioning.
Denial-of-service vulnerabilities don’t need a flashy exploit chain when the vulnerable software sits inside automation.
One malicious server.
One poisoned response.
One ridiculous loop counter.
Bugstoday verdict: sometimes you don’t need to hack the machine. Just convince it to waste its own time.
