bugGNU Wget - Bugs: bug #56909, wget Authorization header leak via...


bug #56909: wget Authorization header leak via 3xx redirects

Submitter:  Cedric Buissart <rhcedric>
Submitted:  Tue 17 Sep 2019 09:28:06 AM UTC
Category:  Protocol Issue Severity:  3 - Normal
Priority:  5 - Normal Status:  None
Privacy:  Public Assigned to:  None
Originator Name:  Cedric Open/Closed:  Open
Release:  None Operating System:  GNU/Linux
Reproducibility:  Every Time Fixed Release:  None
Planned Release:  None Regression:  None
Work Required:  None Patch Included:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Thu 20 Jul 2023 03:43:25 AM UTC, comment #11: 

Is there any fix available for this CVE?

Mallikarjunarao Kosuri <vkosuri>
Sat 05 Mar 2022 06:57:49 AM UTC, comment #10: 

Looking at the curl patch, it seems that it restricts all Authorization headers, even manually added ones, unless the option is set. That seems like the right way to go to me.


Paul Wise <pabs>
Mon 20 Sep 2021 06:42:00 PM UTC, comment #9: 

How about adding a warning in the documentation and/or man page ?
That feels like a simple solution :

- RFC is still respected, there are no change in behavior or added options
- Users have a way to be warned that manually adding Authenticate  headers (or any headers with secret data) may be leaked on 30x response, and thus should be manipulated with care.

Cedric Buissart <rhcedric>
Tue 06 Jul 2021 08:21:08 AM UTC, comment #8: 

Is there any news on this issue?

Josef Möllers <jmoellers>
Thu 13 May 2021 12:51:47 PM UTC, comment #7: 

The Authorization is not special when set manually (someone else may want to use a different header to send private information that should removed on redirection).

So a new option may allow detailed control over how often each manually set header can be redirected.

Or simply a leading flag like

--header "0,Authorization: ..." # don't set in redirections
--header "1,Authorization: ..." # set in redirections (default)

Tim Ruehsen <rockdaboot>
Group administrator
Thu 06 May 2021 02:44:16 PM UTC, comment #6: 
Cedric Buissart <rhcedric>
Mon 14 Oct 2019 02:58:30 PM UTC, comment #5: 

Hi, I originally reported this issue. The only reason I reported it as a security issue was due to it matching the cve for curl. I was originally going to report it as a bug, due to the fact it breaks pulling down files from a generated(redirected) presigned aws s3 download link.

I use the header option because I'd prefer not to store, and/or use raw passwords on a system. Storing the auth header isn't secure by no means, but it's better than raw username and password stored in a file. But as it stands I have to use raw username and password to be able to pull down files from a presigned s3 link if using wget. This is because when using the auth header it is forwarded to aws, and aws throws a "ERROR 400: Bad Request" every time.

Would it be possible to add a parameter to not forward the auth header on redirects, or make it default to not forwarding unless you pass a parameter telling it to forward the header like curl implemented?

Ryan Blakley <ryanblakley>
Fri 04 Oct 2019 07:22:19 PM UTC, comment #4: 

I agree with Tim here that this is not a security issue.

Wget provides an option to correctly use the Authorization header. If the user chooses to otherwise coerce Wget into doing something different, we should not stop them from doing so.

Using `--header=Authorization: ds` means that the user is explicitly opting to send the header everytime rather than only to a specific domain.

On your request I'm making this issue public.

Darshit Shah <darnir>
Group administrator
Fri 04 Oct 2019 06:01:22 PM UTC, comment #3: 

If this isn't considered a security issue, would it be feasible to publish it for possible discussion ?

Cedric Buissart <rhcedric>
Tue 17 Sep 2019 12:47:42 PM UTC, comment #2: 

I do not really think header manipulation necessarily involves expert level knowledge with security in mind.

I do not think that the current behaviour is likely to be abused with malicious intent.
However, what can be considered worrying is the case of "cloud services", where you authenticate to Server A, which redirects you to cloud server B with a signed token. Even if both A and B are considered safe, there is still no reason for B, possibly hosted by some random cloud service on the other side of the world, to receive credentials meant for A. Even though B is probably trusted, it still accidentally receives credentials not meant to be sent there.

curl resolved this by defaulting to `Authorization` not being forwarded unless CURLOPT_UNRESTRICTED_AUTH flag is set (https://curl.haxx.se/docs/CVE-2018-1000007.html)

If the behavior is not going to be changed because undefined in RFC, then a warning in the documentation & man page could be written, to ensure that people using an `Authorization` header are aware that the server may return a redirect.

Cedric Buissart <rhcedric>
Tue 17 Sep 2019 09:36:56 AM UTC, comment #1: 

Manually crafting a header means there is some expert level knowledge at work. A person who really knows what she wants. This person should be aware of dangers introduced by redirections (and likely looks up --max-redirect if wanted).

IMO, not a bug but a feature for "power" users.

Except there is a specification (RFC) that doesn't allow Authentication: header in redirections. In this case I would like to make wget follow that.

We should make sure that Wget2 removes the Authentication: header on redirects (have the same behavior as Wget1.x).

Tim Ruehsen <rockdaboot>
Group administrator
Tue 17 Sep 2019 09:28:06 AM UTC, original submission:  

wget is vulnerable to
a flaw similar to curl's CVE-2018-1000007

Here's the description :
-> if you use wget with the regular --user & --password leading to a Basic authentication, and that the server returns a redirect, wget will correctly remove the `Authorization` header before following the redirect query
-> However, if you add the basic authentication manually in the header (e.g.: `Authorization: Basic <credentials>`), wget will NOT clean that up before the redirect. Which means that 2nd server will receive unexpected credentials.
Filling up the `Authorization` header is likely to happen when you use wget in a script, or if you want to avoid the first request created by the `--user` option.

The leak could be an issue in certain situation (e.g.: more and more services being in "the cloud", redirect to other servers after authentication is, I believe, not uncommon).

No CVE has been assigned yet, I was first hoping to get you feedback & plan.

This was originally reported by Ryan Blakley of Red Hat.

Best regards,


Cedric Buissart <rhcedric>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by vkosuri (Posted a comment)
  • -email is unavailable- added by pabs (Posted a comment)
  • -email is unavailable- added by jmoellers (Posted a comment)
  • -email is unavailable- added by jmoellers (bsc#1185551)
  • -email is unavailable- added by ryanblakley (Posted a comment)
  • -email is unavailable- added by darnir (Posted a comment)
  • -email is unavailable- added by rhcedric (Reporter)
  • -email is unavailable- added by rockdaboot (Posted a comment)
  • -email is unavailable- added by rhcedric (Submitted the item)

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-05-18 jmoellers Carbon-Copy- Added -email is unavailable-
    2019-10-04 darnir PrivacyPrivate Public
    2019-10-04 rhcedric Carbon-Copy- Added ryanblakley

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code