Skip to main content
CVE-2024-35195VulnerabilityPublished Updated

SUSE · security update for python-requests

Affects SUSESource GCVE Database

0

Not known to be exploited : upgrade to 2.27.0_1 when convenient.

Data as of 25 Oct 2026, 19:02 UTC

Severity
Medium

Rated by Threat Radar · No CVSS score from NVD or the CNA

EPSS
0.3% chance of exploitation in 30 days – higher than 27% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 2.27.0_1, 1.1.15_3

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 13 May 2025

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.

What to do

Upgrade locust to 2.27.0_1; onlykey-agent to 1.1.15_3.

Affected software

ProductAffectedFixed in
Homebrewlocustpkg:brew/locustOther threatsAffected
  • >=2.2.1 <2.27.0_1
Fixed in
  • 2.27.0_1
Homebrewonlykey-agentpkg:brew/onlykey-agentOther threatsAffected
  • >=1.1.14 <1.1.15_3
Fixed in
  • 1.1.15_3

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Red Hat has released updated python-requests packages that fix this vulnerability. Users of Red Hat OpenStack Platform 17.1 and affected Red Hat Enterprise Linux 8 systems should apply the security update described in Red Hat Security Advisory RHSA-2024:9988. Refer to https://access.redhat.com/articles/11258 for detailed update instructions. No additional mitigation is required beyond applying the official patch.

Description

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.

References

Community reviews

Loading reviews…