CVE-2024-49768: Icloudpd · Waitress has request processing race condition in HTTP pipelining with invalid first request
Affects icloudpdSource GCVE Database
Mentioned vulnerabilities
Not known to be exploited · CVSS 9.1 Critical : upgrade to 1.25.1 as a priority.
Data as of 26 Oct 2026, 06:26 UTC
- EPSS
- 0.4% chance of exploitation in 30 days – higher than 41% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 1.25.1
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:NExploitation evidence
Disclosed: evidence found.
CVE published 13 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by 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-26.
What to do
Upgrade icloudpd to 1.25.1.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
Homebrewicloudpdpkg:brew/icloudpdOther threats | Affected
| Fixed in
|
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-waitress packages for Red Hat OpenStack Platform 17.1 on RHEL 8 x86_64 that address these vulnerabilities. Users should apply the security update as described in Red Hat advisory RHSA-2025:1192 and the related article at https://access.redhat.com/articles/11258. No alternative mitigations or workarounds are indicated. Patch status is confirmed as available.
Description
### Impact A remote client may send a request that is exactly `recv_bytes` (defaults to 8192) long, followed by a secondary request using HTTP pipelining. When request lookahead is disabled (default) we won't read any more requests, and when the first request fails due to a parsing error, we simply close the connection. However when request lookahead is enabled, it is possible to process and receive the first request, start sending the error message back to the client while we read the next request and queue it. This will allow the secondary request to be serviced by the worker thread while the connection should be closed. ### Patches Waitress 3.0.1 fixes the race condition. ### Workarounds Disable `channel_request_lookahead`, this is set to `0` by default disabling this feature. For this vulnerability this value is required to be changed from the default. ### For more information If you have any questions or comments about this advisory: * Open an issue in https://github.com/Pylons/waitress/issues (if not sensitive or security related) * email the Pylons Security mailing list: [pylons-project-security@googlegroups.com](mailto:pylons-project-security@googlegroups.com) (if security related) ### Thanks - m4yfly and urn1ce From TianGong Team of Legendsec at Qi'anxin Group.
References
- access.redhat.com/errata/RHSA-2025:1192 (opens in a new tab)
- access.redhat.com/security/updates/classification/ (opens in a new tab)
- bugzilla.redhat.com/show_bug.cgi?id=2322460 (opens in a new tab)
- bugzilla.redhat.com/show_bug.cgi?id=2322461 (opens in a new tab)
- security.access.redhat.com/data/csaf/v2/advisories/2025/rhsa-2025_1192.json (opens in a new tab)
- github.com/Pylons/waitress/security/advisories/GHSA-9298-4cf8-g4wj (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2024-49768 (opens in a new tab)
- github.com/Pylons/waitress/commit/e4359018537af376cf24bd13616d861e2fb76f65 (opens in a new tab)
- github.com/Pylons/waitress (opens in a new tab)
- github.com/pypa/advisory-database/tree/main/vulns/waitress/PYSEC-2024-210.yaml (opens in a new tab)