urllib3 before 1.24.2 does not remove the authorization HTTP header when following a cross-origin redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the authorization header to be exposed to unintended hosts or transmitted in cleartext. NOTE: this issue exists because of an incomplete fix for CVE-2018-20060 (which was case-sensitive).

The remote Oracle Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the ELSA-2024-2988 advisory.

  - The crypto/tls package of Go through 1.16.5 does not properly assert that the type of public key in an     X.509 certificate matches the expected type when doing a RSA based key exchange, allowing a malicious TLS     server to cause a TLS client to panic. (CVE-2021-34558)

  - The html/template package does not apply the proper rules for handling occurrences of <script, <!--,     and </script within JS literals in <script> contexts. This may cause the template parser to improperly     consider script contexts to be terminated early, causing actions to be improperly escaped. This could be     leveraged to perform an XSS attack. (CVE-2023-39319)

  - BuildKit is a toolkit for converting source code to build artifacts in an efficient, expressive and     repeatable manner. A malicious BuildKit client or frontend could craft a request that could lead to     BuildKit daemon crashing with a panic. The issue has been fixed in v0.12.5. As a workaround, avoid using     BuildKit frontends from untrusted sources. (CVE-2024-23650)

  - Extremely large RSA keys in certificate chains can cause a client/server to expend significant CPU time     verifying signatures. With fix, the size of RSA keys transmitted during handshakes is restricted to <=     8192 bits. Based on a survey of publicly trusted RSA keys, there are currently only three certificates in     circulation with keys larger than this, and all three appear to be test certificates that are not actively     deployed. It is possible there are larger keys in use in private PKIs, but we target the web PKI, so     causing breakage here in the interests of increasing the default safety of users of crypto/tls seems     reasonable. (CVE-2023-29409)

  - The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other     products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the     extension negotiation message), and a client and server may consequently end up with a connection for     which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because     the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and     mishandles use of sequence numbers. For example, there is an effective attack against SSH's use of     ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and     (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API     before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80,     AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0,     Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15,     SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH     through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang     XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd     through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and     LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3,     Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server     before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the     mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh     crate before 0.40.2 for Rust. (CVE-2023-48795)

  - Before Go 1.20, the RSA based TLS key exchanges used the math/big library, which is not constant time. RSA     blinding was applied to prevent timing attacks, but analysis shows this may not have been fully effective.
    In particular it appears as if the removal of PKCS#1 padding may leak timing information, which in turn     could be used to recover session key bits. In Go 1.20, the crypto/tls library switched to a fully constant     time RSA implementation, which we do not believe exhibits any timing side channels. (CVE-2023-45287)

  - In Go before 1.15.13 and 1.16.x before 1.16.5, there can be a panic for a large exponent to the     math/big.Rat SetString or UnmarshalText method. (CVE-2021-33198)

  - QUIC connections do not set an upper bound on the amount of data buffered when reading post-handshake     messages, allowing a malicious QUIC connection to cause unbounded memory growth. With fix, connections now     consistently reject messages larger than 65KiB in size. (CVE-2023-39322)

  - Processing an incomplete post-handshake message for a QUIC connection can cause a panic. (CVE-2023-39321)

  - A malicious HTTP sender can use chunk extensions to cause a receiver reading from a request or response     body to read many more bytes from the network than are in the body. A malicious HTTP client can further     exploit this to cause a server to automatically read a large amount of data (up to about 1GiB) when a     handler fails to read the entire body of a request. Chunk extensions are a little-used HTTP feature which     permit including additional metadata in a request or response body sent using the chunked encoding. The     net/http chunked encoding reader discards this metadata. A sender can exploit this by inserting a large     metadata segment with each byte transferred. The chunk reader now produces an error if the ratio of real     body to encoded bytes grows too small. (CVE-2023-39326)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP     request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method     changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs.
    Although this behavior is not specified in the section for redirects, it can be inferred by piecing     together information from different sections and we have observed the behavior in other major HTTP client     implementations like curl and web browsers. Because the vulnerability requires a previously trusted     service to become compromised in order to have an impact on confidentiality we believe the exploitability     of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request     bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions     must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information     in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts     redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised.
    This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve     this issue. Users unable to update should disable redirects for services that aren't expecting to respond     with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle     301, 302, and 303 redirects manually by stripping the HTTP request body. (CVE-2023-45803)

  - Requests forwarded by ReverseProxy include the raw query parameters from the inbound request, including     unparsable parameters rejected by net/http. This could permit query parameter smuggling when a Go proxy     forwards a parameter with an unparsable value. After fix, ReverseProxy sanitizes the query parameters in     the forwarded query when the outbound request's Form field is set after the ReverseProxy. Director     function returns, indicating that the proxy has parsed the query parameters. Proxies which do not parse     query parameters continue to forward the original query parameters unchanged. (CVE-2022-2880)

  - The html/template package does not properly handle HTML-like  comment tokens, nor hashbang #! comment     tokens, in <script> contexts. This may cause the template parser to improperly interpret the contents of     <script> contexts, causing actions to be improperly escaped. This may be leveraged to perform an XSS     attack. (CVE-2023-39318)

  - urllib3 before 1.24.2 does not remove the authorization HTTP header when following a cross-origin redirect     (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the     authorization header to be exposed to unintended hosts or transmitted in cleartext. NOTE: this issue     exists because of an incomplete fix for CVE-2018-20060 (which was case-sensitive). (CVE-2018-25091)

  - Reader.Read does not set a limit on the maximum size of file headers. A maliciously crafted archive could     cause Read to allocate unbounded amounts of memory, potentially causing resource exhaustion or panics.
    After fix, Reader.Read limits the maximum size of header blocks to 1 MiB. (CVE-2022-2879)

  - Programs which compile regular expressions from untrusted sources may be vulnerable to memory exhaustion     or denial of service. The parsed regexp representation is linear in the size of the input, but in some     cases the constant factor can be as high as 40,000, making relatively small regexps consume much larger     amounts of memory. After fix, each regexp being parsed is limited to a 256 MB memory footprint. Regular     expressions whose representation would use more space than that are rejected. Normal use of regular     expressions is unaffected. (CVE-2022-41715)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Redhat Enterprise Linux 8 host has packages installed that are affected by multiple vulnerabilities as referenced in the RHSA-2024:2988 advisory.

    The container-tools module contains tools for working with containers, notably podman, buildah, skopeo,     and runc.

    Security Fix(es):

    * urllib3: urllib3 does not remove the authorization HTTP header when following a cross-origin redirect     (CVE-2018-25091)

    * golang: math/big.Rat: may cause a panic or an unrecoverable fatal error if passed inputs with very large     exponents (CVE-2021-33198)

    * golang: crypto/tls: certificate of wrong type is causing TLS client to panic (CVE-2021-34558)

    * golang: archive/tar: unbounded memory consumption when reading headers (CVE-2022-2879)

    * golang: net/http/httputil: ReverseProxy should not forward unparseable query parameters (CVE-2022-2880)

    * golang: regexp/syntax: limit memory used by parsing regexps (CVE-2022-41715)

    * golang: crypto/tls: slow verification of certificate chains containing large RSA keys (CVE-2023-29409)

    * golang: html/template: improper handling of HTML-like comments within script contexts (CVE-2023-39318)

    * golang: html/template: improper handling of special tags within script contexts (CVE-2023-39319)

    * golang: crypto/tls: panic when processing post-handshake message on QUIC connections (CVE-2023-39321)

    * golang: crypto/tls: lack of a limit on buffered post-handshake (CVE-2023-39322)

    * golang: net/http/internal: Denial of Service (DoS) via Resource Consumption via HTTP requests     (CVE-2023-39326)

    * golang: crypto/tls: Timing Side Channel attack in RSA based TLS key exchanges. (CVE-2023-45287)

    * urllib3: Request body not stripped after redirect from 303 status changes request method to GET     (CVE-2023-45803)

    * ssh: Prefix truncation attack on Binary Packet Protocol (BPP) (CVE-2023-48795)

    * moby/buildkit: Possible race condition with accessing subpaths from cache mounts (CVE-2024-23650)

    For more details about the security issue(s), including the impact, a CVSS score, acknowledgments, and     other related information, refer to the CVE page(s) listed in the References section.

    Additional Changes:

    For detailed information on changes in this release, see the Red Hat Enterprise Linux 8.10 Release Notes     linked from the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

According to the versions of the python-pip packages installed, the EulerOS Virtualization installation on the remote host is affected by the following vulnerabilities :

  - urllib3 before 1.24.2 does not remove the authorization HTTP header when following a cross-origin redirect     (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the     authorization header to be exposed to unintended hosts or transmitted in cleartext. NOTE: this issue     exists because of an incomplete fix for CVE-2018-20060 (which was case-sensitive). (CVE-2018-25091)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `Cookie` HTTP header     special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user.
    However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP     redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been     patched in urllib3 version 1.26.17 or 2.0.5. (CVE-2023-43804)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the python-urllib3 packages installed, the EulerOS Virtualization installation on the remote host is affected by the following vulnerabilities :

  - urllib3 before 1.24.2 does not remove the authorization HTTP header when following a cross-origin redirect     (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the     authorization header to be exposed to unintended hosts or transmitted in cleartext. NOTE: this issue     exists because of an incomplete fix for CVE-2018-20060 (which was case-sensitive). (CVE-2018-25091)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `Cookie` HTTP header     special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user.
    However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP     redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been     patched in urllib3 version 1.26.17 or 2.0.5. (CVE-2023-43804)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP     request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method     changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs.
    Although this behavior is not specified in the section for redirects, it can be inferred by piecing     together information from different sections and we have observed the behavior in other major HTTP client     implementations like curl and web browsers. Because the vulnerability requires a previously trusted     service to become compromised in order to have an impact on confidentiality we believe the exploitability     of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request     bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions     must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information     in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts     redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised.
    This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve     this issue. Users unable to update should disable redirects for services that aren't expecting to respond     with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle     301, 302, and 303 redirects manually by stripping the HTTP request body. (CVE-2023-45803)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the python-urllib3 packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - urllib3 before 1.24.2 does not remove the authorization HTTP header when following a cross-origin redirect     (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the     authorization header to be exposed to unintended hosts or transmitted in cleartext. NOTE: this issue     exists because of an incomplete fix for CVE-2018-20060 (which was case-sensitive). (CVE-2018-25091)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `Cookie` HTTP header     special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user.
    However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP     redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been     patched in urllib3 version 1.26.17 or 2.0.5. (CVE-2023-43804)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP     request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method     changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs.
    Although this behavior is not specified in the section for redirects, it can be inferred by piecing     together information from different sections and we have observed the behavior in other major HTTP client     implementations like curl and web browsers. Because the vulnerability requires a previously trusted     service to become compromised in order to have an impact on confidentiality we believe the exploitability     of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request     bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions     must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information     in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts     redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised.
    This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve     this issue. Users unable to update should disable redirects for services that aren't expecting to respond     with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle     301, 302, and 303 redirects manually by stripping the HTTP request body. (CVE-2023-45803)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the versions of the python-pip packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - urllib3 before 1.24.2 does not remove the authorization HTTP header when following a cross-origin redirect     (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the     authorization header to be exposed to unintended hosts or transmitted in cleartext. NOTE: this issue     exists because of an incomplete fix for CVE-2018-20060 (which was case-sensitive). (CVE-2018-25091)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `Cookie` HTTP header     special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user.
    However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP     redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been     patched in urllib3 version 1.26.17 or 2.0.5. (CVE-2023-43804)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote Ubuntu 16.04 ESM / 18.04 ESM / 20.04 LTS / 22.04 LTS / 23.04 host has packages installed that are affected by multiple vulnerabilities as referenced in the USN-6473-2 advisory.

  - urllib3 before 1.24.2 does not remove the authorization HTTP header when following a cross-origin redirect     (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the     authorization header to be exposed to unintended hosts or transmitted in cleartext. NOTE: this issue     exists because of an incomplete fix for CVE-2018-20060 (which was case-sensitive). (CVE-2018-25091)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `Cookie` HTTP header     special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user.
    However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP     redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been     patched in urllib3 version 1.26.17 or 2.0.5. (CVE-2023-43804)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP     request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method     changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs.
    Although this behavior is not specified in the section for redirects, it can be inferred by piecing     together information from different sections and we have observed the behavior in other major HTTP client     implementations like curl and web browsers. Because the vulnerability requires a previously trusted     service to become compromised in order to have an impact on confidentiality we believe the exploitability     of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request     bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions     must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information     in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts     redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised.
    This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve     this issue. Users unable to update should disable redirects for services that aren't expecting to respond     with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle     301, 302, and 303 redirects manually by stripping the HTTP request body. (CVE-2023-45803)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Ubuntu 16.04 ESM / 18.04 ESM / 20.04 LTS / 22.04 LTS / 23.04 / 23.10 host has packages installed that are affected by multiple vulnerabilities as referenced in the USN-6473-1 advisory.

  - urllib3 before 1.24.2 does not remove the authorization HTTP header when following a cross-origin redirect     (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the     authorization header to be exposed to unintended hosts or transmitted in cleartext. NOTE: this issue     exists because of an incomplete fix for CVE-2018-20060 (which was case-sensitive). (CVE-2018-25091)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `Cookie` HTTP header     special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user.
    However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP     redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been     patched in urllib3 version 1.26.17 or 2.0.5. (CVE-2023-43804)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn't remove the HTTP     request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method     changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs.
    Although this behavior is not specified in the section for redirects, it can be inferred by piecing     together information from different sections and we have observed the behavior in other major HTTP client     implementations like curl and web browsers. Because the vulnerability requires a previously trusted     service to become compromised in order to have an impact on confidentiality we believe the exploitability     of this vulnerability is low. Additionally, many users aren't putting sensitive data in HTTP request     bodies, if this is the case then this vulnerability isn't exploitable. Both of the following conditions     must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information     in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts     redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised.
    This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve     this issue. Users unable to update should disable redirects for services that aren't expecting to respond     with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle     301, 302, and 303 redirects manually by stripping the HTTP request body. (CVE-2023-45803)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The remote Debian 10 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-3610 advisory.

  - urllib3 before version 1.23 does not remove the Authorization HTTP header when following a cross-origin     redirect (i.e., a redirect that differs in host, port, or scheme). This can allow for credentials in the     Authorization header to be exposed to unintended hosts or transmitted in cleartext. (CVE-2018-20060)

  - In the urllib3 library through 1.24.1 for Python, CRLF injection is possible if the attacker controls the     request parameter. (CVE-2019-11236)

  - The urllib3 library before 1.24.2 for Python mishandles certain cases where the desired set of CA     certificates is different from the OS store of CA certificates, which results in SSL connections     succeeding in situations where a verification failure is the correct outcome. This is related to use of     the ssl_context, ca_certs, or ca_certs_dir argument. (CVE-2019-11324)

  - An issue was discovered in urllib2 in Python 2.x through 2.7.16 and urllib in Python 3.x through 3.7.3.
    CRLF injection is possible if the attacker controls a url parameter, as demonstrated by the first argument     to urllib.request.urlopen with \r\n (specifically in the query string after a ? character) followed by an     HTTP header or a Redis command. This is fixed in: v2.7.17, v2.7.17rc1, v2.7.18, v2.7.18rc1; v3.5.10,     v3.5.10rc1, v3.5.8, v3.5.8rc1, v3.5.8rc2, v3.5.9; v3.6.10, v3.6.10rc1, v3.6.11, v3.6.11rc1, v3.6.12,     v3.6.9, v3.6.9rc1; v3.7.4, v3.7.4rc1, v3.7.4rc2, v3.7.5, v3.7.5rc1, v3.7.6, v3.7.6rc1, v3.7.7, v3.7.7rc1,     v3.7.8, v3.7.8rc1, v3.7.9. (CVE-2019-9740)

  - http.client in Python 3.x before 3.5.10, 3.6.x before 3.6.12, 3.7.x before 3.7.9, and 3.8.x before 3.8.5     allows CRLF injection if the attacker controls the HTTP request method, as demonstrated by inserting CR     and LF control characters in the first argument of HTTPConnection.request. (CVE-2020-26116)

  - urllib3 before 1.25.9 allows CRLF injection if the attacker controls the HTTP request method, as     demonstrated by inserting CR and LF control characters in the first argument of putrequest(). NOTE: this     is similar to CVE-2020-26116. (CVE-2020-26137)

  - urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn't treat the `Cookie` HTTP header     special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user.
    However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP     redirects to a different origin if that user doesn't disable redirects explicitly. This issue has been     patched in urllib3 version 1.26.17 or 2.0.5. (CVE-2023-43804)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
197998	Oracle Linux 8 : container-tools:ol8 (ELSA-2024-2988)	Nessus	Oracle Linux Local Security Checks	high
197773	RHEL 8 : container-tools:rhel8 (RHSA-2024:2988)	Nessus	Red Hat Local Security Checks	high
197285	EulerOS Virtualization 3.0.6.0 : python-pip (EulerOS-SA-2024-1702)	Nessus	Huawei Local Security Checks	high
197273	EulerOS Virtualization 3.0.6.0 : python-urllib3 (EulerOS-SA-2024-1703)	Nessus	Huawei Local Security Checks	high
191874	EulerOS 2.0 SP8 : python-urllib3 (EulerOS-SA-2024-1296)	Nessus	Huawei Local Security Checks	high
191845	EulerOS 2.0 SP8 : python-pip (EulerOS-SA-2024-1295)	Nessus	Huawei Local Security Checks	high
185739	Ubuntu 16.04 ESM / 18.04 ESM / 20.04 LTS / 22.04 LTS / 23.04 / 23.10 : pip vulnerabilities (USN-6473-2)	Nessus	Ubuntu Local Security Checks	high
185342	Ubuntu 16.04 ESM / 18.04 ESM / 20.04 LTS / 22.04 LTS / 23.04 / 23.10 : urllib3 vulnerabilities (USN-6473-1)	Nessus	Ubuntu Local Security Checks	high
182762	Debian DLA-3610-1 : python-urllib3 - LTS security update	Nessus	Debian Local Security Checks	critical

Detections

Analytics

CVE-2018-25091

medium

Tenable Plugins

high

high

high

high

high

high

high

high

critical