Vulnerabilities

2 via 2 paths

Dependencies

5

Source

GitHub

Commit

9674081b

Find, fix and prevent vulnerabilities in your code.

Severity
  • 2
Status
  • 2
  • 0
  • 0

medium severity
new

Resource Exhaustion

  • Vulnerable module: idna
  • Introduced through: requests@2.24.0

Detailed paths

  • Introduced through: deckbsd/glouton-satnogs-data-downloader@deckbsd/glouton-satnogs-data-downloader#9674081b669b0ca3c04513ede4127c6221962a73 requests@2.24.0 idna@2.10

Overview

Affected versions of this package are vulnerable to Resource Exhaustion via the idna.encode function. An attacker can consume significant resources and potentially cause a denial-of-service by supplying specially crafted arguments to this function.

Note: This is triggered by arbitrarily large inputs that would not occur in normal usage but may be passed to the library assuming there is no preliminary input validation by the higher-level application.

Remediation

Upgrade idna to version 3.7 or higher.

References

medium severity

Information Exposure

  • Vulnerable module: requests
  • Introduced through: requests@2.24.0

Detailed paths

  • Introduced through: deckbsd/glouton-satnogs-data-downloader@deckbsd/glouton-satnogs-data-downloader#9674081b669b0ca3c04513ede4127c6221962a73 requests@2.24.0
    Remediation: Upgrade to requests@2.31.0.

Overview

Affected versions of this package are vulnerable to Information Exposure by leaking Proxy-Authorization headers to destination servers during redirects to an HTTPS origin. This is a result of how rebuild_proxies is used to recompute and reattach the Proxy-Authorization header to requests when redirected.

NOTE: This behavior has only been observed to affect proxied requests when credentials are supplied in the URL user information component (e.g. https://username:password@proxy:8080), and only when redirecting to HTTPS:

  1. HTTP → HTTPS: leak

  2. HTTPS → HTTP: no leak

  3. HTTPS → HTTPS: leak

  4. HTTP → HTTP: no leak

For HTTP connections sent through the proxy, the proxy will identify the header in the request and remove it prior to forwarding to the destination server. However when sent over HTTPS, the Proxy-Authorization header must be sent in the CONNECT request as the proxy has no visibility into further tunneled requests. This results in Requests forwarding the header to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate those credentials.

Workaround

This vulnerability can be avoided by setting allow_redirects to False on all calls through Requests top-level APIs, and then capturing the 3xx response codes to make a new request to the redirect destination.

Remediation

Upgrade requests to version 2.31.0 or higher.

References