{"id":163792,"date":"2026-03-10T23:11:57","date_gmt":"2026-03-10T21:11:59","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy"},"modified":"2026-03-10T23:11:57","modified_gmt":"2026-03-10T21:11:59","slug":"uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy","title":{"rendered":"Vulnerabilities in the Pingora project allow for injection into external requests","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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. <\/p>\n
Two of the most dangerous vulnerabilities allow for 'HTTP Request Smuggling' attacks, which can bypass access control systems and infiltrate the content of requests from other users processed in the same stream between the frontend and backend (for instance, to inject malicious JavaScript code into another user\u2019s session on the website). These issues were identified by a participant in the Bug Bounty program, which offers rewards for discovering vulnerabilities. <\/p>\n
In a scheme where the backend is accessed through a reverse proxy, client requests are received by an additional node that establishes a long-lasting TCP connection with the backend performing the actual request processing. Through this common connection, requests from different users are usually transmitted sequentially in accordance with the HTTP protocol. 'HTTP Request Smuggling' attacks arise from different interpretations of HTTP headers and protocol specifications on the frontends and backends, for example, when the frontend uses the HTTP header 'Content-Length' to determine the request size, while the backend uses 'Transfer-Encoding: chunked'. <\/p>\n
The first vulnerability, CVE-2026-2835, exists in the parsing code for HTTP\/1.0 requests and is caused by the improper handling of the 'Transfer-Encoding' header with multiple values, as well as using connection closure as an indicator of the end of the request body (close-delimited). Pingora only checked the 'Transfer-Encoding: chunked' variant and ignored this header if it indicated multiple values. In this situation, Pingora did not account for the size in the 'Content-Length' header and considered all data received before the connection was closed as the request body. <\/p>\n
By specifying multiple values in the 'Transfer-Encoding' header, an attacker could create conditions under which a request was redirected to the backend, where the actual size did not match 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 handled the remaining tail as the beginning 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:
<\/center> <\/p>\n
The second vulnerability CVE-2026-2833 is caused by incorrect handling of the HTTP header «Upgrade» in HTTP\/1.1 requests. When the «Upgrade» header is present in a request, the proxy immediately forwards it to the backend without waiting for a response with status code 101 (Switching Protocols). As a result, stream synchronization between the proxy and the backend is disrupted, causing the backend to treat data sent after the «Upgrade» header as a separate request, thus sending the result of this request in response to a subsequent request from another user. GET \\\/ HTTP\\\/1.1 Host: example.com Upgrade: foo GET \\\/admin HTTP\\\/1.1 Host: example.com
<\/center>
<\/center> <\/p>\n
Issues become apparent when using Pingora in reverse proxy mode (ingress proxy), which routes user requests to backends using HTTP\/1.0 or HTTP\/1.1 protocols. The configuration of Pingora used in the Cloudflare content delivery network does not allow for the exploitation of vulnerabilities, as Pingora in the CDN is not used as an ingress proxy, forwarding requests only using the HTTP\/1.1 protocol, blocking requests with incorrect Content-Length values, only forwarding a single «Transfer-Encoding: chunked» header value, and adding an additional «Connection: close» header to requests with the «Upgrade:» header, preventing additional requests from being sent over the same connection. <\/p>\n
The third vulnerability CVE-2026-2836 (severity rating 8.4 out of 10) leads to cache poisoning due to generating the cache data placement key (CacheKey) solely based on the URI path, ignoring the «Host» header content. This flaw results in the generation of identical caching keys for the same HTTP paths to different hosts. The vulnerability can be exploited to replace cache content when caching mode is used for multiple hosts. In Pingora, caching is an experimental feature not recommended for production deployments. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Vulnerabilities](\"\/wp-content\/uploads\/2026\/03\/6a4654a05c9ff8c64cc4cb4773bf4ec9.png\")
<\/center> <\/p>\n![\"Vulnerabilities](\"\/wp-content\/uploads\/2026\/03\/f86f840431a9be00c4cfd74cc6b4c89b.png\")
<\/center> ![\"Vulnerabilities](\"\/wp-content\/uploads\/2026\/03\/8b23d0642fc0b783c2027b91078607e4.png\")
<\/center> <\/p>\n