Cloudflare has announced the resolution of three vulnerabilities in the Pingora framework, two of which have been assigned a critical severity level (9.3 out of 10). The Pingora framework is written in Rust and is intended for developing secure, high-performance network services. A proxy built using Pingora is used in Cloudflare's content delivery network and handles more than 40 million requests per second. The vulnerabilities have been fixed in the Pingora 0.8.0 release.
The two most dangerous vulnerabilities allow for "HTTP Request Smuggling" attacks, which enable bypassing access control systems and injecting into the content of requests from other users being processed in the same thread between the frontend and backend (for example, inserting malicious JavaScript code into another user's session with the website). The issues were discovered by a participant in the Bug Bounty program, which rewards the identification of vulnerabilities.
In a setup where requests are directed to the backend through a reverse proxy, client requests are received by an additional node that establishes a long-lived TCP connection with the backend, which directly processes the requests. Through this shared connection, requests from different users are typically transmitted in sequence, separated by the HTTP protocol's mechanisms. HTTP Request Smuggling attacks arise from differing interpretations of HTTP headers and specifications between frontends and backends, for instance, when the frontend uses the HTTP header "Content-Length" to determine the request size, while the backend uses "Transfer-Encoding: chunked."
The first vulnerability, CVE-2026-2835, exists in the HTTP/1.0 request parsing code and is caused by improper handling of the "Transfer-Encoding" header with multiple values, as well as using connection closure as an indication of the end of the request body (close-delimited). Pingora only checked for the "Transfer-Encoding: chunked" variant and ignored this header if it indicated multiple values. In this scenario, Pingora did not account for the size in the "Content-Length" header and considered all data received until the connection was closed as the request body.
By specifying multiple values in the 'Transfer-Encoding' header, an attacker could create conditions in which a request was redirected to the backend, with the actual size not matching the size of the chunked chain computed based on the 'Transfer-Encoding' header. Pingora redirected all received data as a single request, while the backend, for instance, Node.js, computed the request based on 'Transfer-Encoding: chunked' and processed the remaining tail as the start of another request. GET \/ HTTP\/1.0 Host: example.com Connection: keep-alive Transfer-Encoding: identity, chunked Content-Length: 29 0 GET \/admin HTTP\/1.1 X:
The second vulnerability CVE-2026-2833 arises from improper handling of the 'Upgrade' HTTP header in HTTP\/1.1 requests. When an 'Upgrade' header was present in the request, the proxy immediately forwarded it to the backend along with the rest of the request data that followed the 'Upgrade' header, without waiting for a response from the backend with status code 101 (Switching Protocols). This caused the synchronization of the stream between the proxy and the backend to be disrupted, and the backend treated the data sent after the 'Upgrade' header as a separate request, sending the result of executing that request in response to the subsequent request from another user. GET \/ HTTP\/1.1 Host: example.com Upgrade: foo GET \/admin HTTP\/1.1 Host: example.com
Issues arise when using Pingora in the form of a reverse proxy (ingress proxy), translating user requests to backends using HTTP\/1.0 or HTTP\/1.1 protocols. The configuration of Pingora used in the Cloudflare content delivery network did not allow for the exploitation of vulnerabilities, as Pingora is not used as an ingress proxy in the CDN, redirects requests only using HTTP\/1.1, blocks requests with invalid Content-Length values, redirects only a single value of the 'Transfer-Encoding: chunked' header, and adds an additional 'Connection: close' header to requests with the 'Upgrade:' header, preventing additional requests from being sent over the same connection.
The third vulnerability CVE-2026-2836 (severity level 8.4 out of 10) leads to cache poisoning due to the generation of the cache data placement key (CacheKey) based solely on the URI path, ignoring the content of the 'Host' header. This oversight results in the formation of identical cache keys for the same HTTP paths across different hosts. The vulnerability can be exploited to substitute cache content when using caching mode for multiple hosts. In Pingora, caching is an experimental feature not recommended for production deployments.
Source: opennet.ru
