Affected: AlmaLinux:8: python3-requests

Python is an interpreted, interactive, object-oriented programming language, which includes modules, classes, exceptions, very high level dynamic data types and dynamic typing. Python supports interfaces to many system calls and libraries, as well as to various windowing systems.

Security Fix(es):

* requests: subsequent requests to the same host ignore cert verification (CVE-2024-35195)

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.

Affected: Alpaquita:23: py3-requests, Alpaquita:stream: py3-requests

Affected: Homebrew: abi3audit

When using a `requests.Session`, if the first request to a given origin is made with `verify=False`, TLS certificate verification may remain disabled for all subsequent requests to that origin, even if `verify=True` is explicitly specified later.

This occurs because the underlying connection is reused from the session's connection pool, causing the initial TLS verification setting to persist for the lifetime of the pooled connection. As a result, applications may unintentionally send requests without certificate verification, leading to potential man-in-the-middle attacks and compromised confidentiality or integrity.

This behavior affects versions of `requests` prior to 2.32.0.

Withdrawn by the publisher.

Affected: CleanStart: k8s-sidecar

Multiple security vulnerabilities affect the k8s-sidecar package. These issues are resolved in later releases. See references for individual vulnerability details.

Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0.

Affected: PyPI: requests

When using a `requests.Session`, if the first request to a given origin is made with `verify=False`, TLS certificate verification may remain disabled for all subsequent requests to that origin, even if `verify=True` is explicitly specified later.

This occurs because the underlying connection is reused from the session's connection pool, causing the initial TLS verification setting to persist for the lifetime of the pooled connection. As a result, applications may unintentionally send requests without certificate verification, leading to potential man-in-the-middle attacks and compromised confidentiality or integrity.

This behavior affects versions of `requests` prior to 2.32.0.

Affected: openEuler:22.03-LTS-SP4: python-requests

Requests is an HTTP library, written in Python, as an alternative to Python's builtin urllib2 which requires work (even method overrides) to perform basic tasks. Features of Requests: - GET, HEAD, POST, PUT, DELETE Requests: + HTTP Header Request Attachment. + Data/Params Request Attachment. + Multipart File Uploads. + CookieJar Support. + Redirection History. + Redirection Recursion Urllib Fix. + Automatic Decompression of GZipped Content. + Unicode URL Support. - Authentication: + URL + HTTP Auth Registry. Security Fix(es):

Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0.(CVE-2024-35195)

python310-requests-2.32.2-1.1 on GA media

Affected: PyPI: requests

When using a `requests.Session`, if the first request to a given origin is made with `verify=False`, TLS certificate verification may remain disabled for all subsequent requests to that origin, even if `verify=True` is explicitly specified later.

This occurs because the underlying connection is reused from the session's connection pool, causing the initial TLS verification setting to persist for the lifetime of the pooled connection. As a result, applications may unintentionally send requests without certificate verification, leading to potential man-in-the-middle attacks and compromised confidentiality or integrity.

This behavior affects versions of `requests` prior to 2.32.0.

pypa/setuptools: Remote code execution via download functions in the package_index module in pypa/setuptools jsonata: malicious expression can pollute the "Object" prototype jinja2: accepts keys containing non-attribute characters requests: subsequent requests to the same host ignore cert verification

Recommended update for python-requests

Affected: Ubuntu:Pro:14.04:LTS: python-pip, Ubuntu:Pro:14.04:LTS: requests, Ubuntu:Pro:16.04:LTS: requests, Ubuntu:Pro:16.04:LTS: python-pip, Ubuntu:Pro:18.04:LTS: requests, Ubuntu:Pro:18.04:LTS: python-pip, Ubuntu:Pro:20.04:LTS: requests, Ubuntu:Pro:20.04:LTS: python-pip, Ubuntu:22.04:LTS: requests, Ubuntu:Pro:22.04:LTS: python-pip and 2 more

Requests is a HTTP library. Prior to 2.32.0, when making requests through a Requests `Session`, if the first request is made with `verify=False` to disable cert verification, all subsequent requests to the same host will continue to ignore cert verification regardless of changes to the value of `verify`. This behavior will continue for the lifecycle of the connection in the connection pool. This vulnerability is fixed in 2.32.0.

Ein Angreifer kann mehrere Schwachstellen in Red Hat Ansible Automation Platform ausnutzen, um beliebigen Programmcode auszuführen, einen Denial-of-Service-Zustand erzeugen, vertrauliche Informationen offenzulegen, Sicherheitsmaßnahmen zu umgehen, Dateien zu manipulieren oder Cross-Site-Scripting (XSS)-Angriffe durchzuführen.