Skip to main content
CVE-2024-35195VulnerabilityPublished Updated

Red Hat Security Advisory: Satellite 6.16.3 Async Update

Affects Red Hat locustSource GCVE Database

0

Mentioned vulnerabilities

Not known to be exploited · fixed in Red Hat package updates : update Red Hat locust when convenient.

Data as of 26 Oct 2026, 17:16 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, 3.4.0_1

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 5 Mar 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 26 Oct 2026.

What to do

Upgrade locust to 2.27.0_1; localstack to 3.4.0_1.

Affected software

ProductAffectedFixed in
Homebrewlocustpkg:brew/locustOther threatsAffected
  • >=2.2.1 <2.27.0_1
Fixed in
  • 2.27.0_1
Homebrewlocalstackpkg:brew/localstackOther threatsAffected
  • >=0.11.3.3 <3.4.0_1
Fixed in
  • 3.4.0_1

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 Red Hat Satellite 6.16.3 which includes fixes for these vulnerabilities. Users should upgrade to version 6.16.3 after applying all previously released errata relevant to their systems. Detailed update instructions are available in the Red Hat Satellite documentation. No additional mitigations are indicated beyond applying the official update.

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…