CVE-2026-2833: https://github.com/cloudflare/pingora · HTTP Request/Response Smuggling
Affects https://github.com/cloudflare/pingoraSource CVE Database V5
Not known to be exploited · CVSS 9.3 Critical : upgrade to 0.8.0 as a priority.
Data as of 30 Oct 2026, 20:25 UTC
- EPSS
- 0.6% chance of exploitation in 30 days – higher than 51% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 0.8.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:H/SI:H/SA:NExploitation evidence
Disclosed: evidence found.
CVE published 4 Mar 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: 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 30 Oct 2026.
What to do
Upgrade https://github.com/cloudflare/pingora and cloudflare/pingora to 0.8.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| Cloudflarehttps://github.com/cloudflare/pingora | Affected
| Fixed in
|
GitHubcloudflare/pingorapkg:github/cloudflare/pingoraOther threats | Affected
| Fixed in
|
GitHubhttps://github.com/cloudflare/pingorapkg:github/https://github.com/cloudflare/pingoraOther 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
To mitigate CVE-2026-2833, organizations should immediately upgrade all Pingora deployments to version 0.8.0 or later, which includes fixes for the improper HTTP/1.1 Upgrade header handling. Until upgrades can be applied, implement request filtering rules that reject or return errors on any HTTP requests containing Upgrade headers to prevent the proxy from forwarding bytes beyond the initial request header. Disable downstream connection reuse where possible to limit the impact of smuggled requests. Monitor backend logs for anomalous request patterns that may indicate smuggling attempts, such as unexpected requests following Upgrade headers. Employ layered security controls including backend authentication and strict session management to reduce the impact of any smuggled requests. Regularly audit proxy configurations and update security policies to detect and respond to suspicious traffic. Finally, maintain awareness of any emerging exploit reports or patches related to Pingora and HTTP request smuggling.
Description
An HTTP request smuggling vulnerability (CWE-444) was found in Pingora's handling of HTTP/1.1 connection upgrades. The issue occurs when a Pingora proxy reads a request containing an Upgrade header, causing the proxy to pass through the rest of the bytes on the connection to a backend before the backend has accepted the upgrade. An attacker can thus directly forward a malicious payload after a request with an Upgrade header to that backend in a way that may be interpreted as a subsequent request header, bypassing proxy-level security controls and enabling cross-user session hijacking. Impact This vulnerability primarily affects standalone Pingora deployments where a Pingora proxy is exposed to external traffic. An attacker could exploit this to: * Bypass proxy-level ACL controls and WAF logic * Poison caches and upstream connections, causing subsequent requests from legitimate users to receive responses intended for smuggled requests * Perform cross-user attacks by hijacking sessions or smuggling requests that appear to originate from the trusted proxy IP Cloudflare's CDN infrastructure was not affected by this vulnerability, as ingress proxies in the CDN stack maintain proper HTTP parsing boundaries and do not prematurely switch to upgraded connection forwarding mode. Mitigation: Pingora users should upgrade to Pingora v0.8.0 or higher As a workaround, users may return an error on requests with the Upgrade header present in their request filter logic in order to stop processing bytes beyond the request header and disable downstream connection reuse.