CVE-2004-2014 still unpatched

[hugusmaximus]

This vulnerability:

https://nvd.nist.gov/vuln/detail/CVE-2004-2014

was reported 20 years ago. It is still working on Wget 1.21.4

Here original details:

https://bugs.gentoo.org/51365

Fix is simple: just lock the file where Wget will write the downloaded file. A safe programming approach would be to use O_CREAT | O_EXCL when creating a file

This approach ensures that the file is created and locked atomically. If the file already exists (even as a symlink), the operation will fail.

Best,

[hugusmaximus]

I think Wget should enable atomic creation and locking by default, and we could add an option to disable this behavior (for backward compatibility with edge cases where atomicity isn’t necessary).

So my new proposed behavior would be:

Default: Secure file creation (atomic + locked).
Optional: --no-atomic or --insecure-write for legacy use cases.

[hugusmaximus]

Maybe a more robust approach would be to make Wget’s file-handling explicitly mode-dependent, rather than trying to address this with locking or a single flag... Concretely: use exclusive creation semantics for new outputs, stage data into a securely created temporary file followed by an atomic rename for overwrite paths, and only allow resume when operating on a previously validated regular file descriptor. This avoids relying on advisory locking and directly addresses the root issue (unsafe pathname resolution) while remaining compatible with existing behaviors.