{"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\/pt\/blog\/news\/uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy","title":{"rendered":"Vulnerabilidades no projeto Pingora permitindo infiltra\u00e7\u00e3o em solicita\u00e7\u00f5es externas","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
A empresa Cloudflare anunciou a corre\u00e7\u00e3o de tr\u00eas vulnerabilidades no framework Pingora, sendo duas delas classificadas como cr\u00edticas (9,3 de 10). O framework Pingora \u00e9 escrito na linguagem Rust e \u00e9 destinado \u00e0 cria\u00e7\u00e3o de servi\u00e7os de rede de alto desempenho e seguran\u00e7a. Constru\u00eddo com o Pingora, o proxy \u00e9 usado na rede de entrega de conte\u00fado da Cloudflare e processa mais de 40 milh\u00f5es de solicita\u00e7\u00f5es por segundo. As vulnerabilidades foram corrigidas na vers\u00e3o 0.8.0 do Pingora. <\/p>\n
As duas vulnerabilidades mais perigosas permitem ataques do tipo \u2018HTTP Request Smuggling\u2019, que podem contornar sistemas de restri\u00e7\u00e3o de acesso e infiltrar-se no conte\u00fado de solicita\u00e7\u00f5es de outros usu\u00e1rios, processadas no mesmo fluxo entre o frontend e o backend (por exemplo, para injetar c\u00f3digo JavaScript malicioso na sess\u00e3o de outro usu\u00e1rio com o site). Os problemas foram identificados por um participante do programa Bug Bounty, que oferece recompensas por encontrar vulnerabilidades. <\/p>\n
No esquema de chamada ao backend atrav\u00e9s de um proxy reverso, solicita\u00e7\u00f5es de clientes s\u00e3o recebidas por um n\u00f3 adicional que estabelece uma conex\u00e3o TCP de longa dura\u00e7\u00e3o com o backend, que efetua o processamento direto das solicita\u00e7\u00f5es. Atrav\u00e9s dessa conex\u00e3o comum, geralmente s\u00e3o transmitidas solicita\u00e7\u00f5es de diferentes usu\u00e1rios, que seguem encadeadas uma ap\u00f3s a outra com separa\u00e7\u00e3o por meio do protocolo HTTP. Ataques do tipo HTTP Request Smuggling surgem devido a interpreta\u00e7\u00f5es diferentes dos cabe\u00e7alhos HTTP e das especifica\u00e7\u00f5es do protocolo HTTP nos frontends e backends, por exemplo, quando o frontend usa o cabe\u00e7alho HTTP \u2018Content-Length\u2019 para determinar o tamanho da solicita\u00e7\u00e3o, enquanto o backend usa \u2018Transfer-Encoding: chunked\u2019. <\/p>\n
A primeira vulnerabilidade CVE-2026-2835 est\u00e1 presente no c\u00f3digo de an\u00e1lise de solicita\u00e7\u00f5es HTTP\/1.0 e \u00e9 causada pelo manuseio incorreto do cabe\u00e7alho \u2018Transfer-Encoding\u2019 com m\u00faltiplos valores, al\u00e9m do uso do fechamento da conex\u00e3o como sinal do fim do corpo da solicita\u00e7\u00e3o (close-delimited). O Pingora verificava apenas a variante \u2018Transfer-Encoding: chunked\u2019 e ignorava esse cabe\u00e7alho se houvesse m\u00faltiplos valores. Nesta situa\u00e7\u00e3o, o Pingora n\u00e3o considerava o tamanho no cabe\u00e7alho \u2018Content-Length\u2019 e tratava como corpo da solicita\u00e7\u00e3o todos os dados recebidos at\u00e9 o fechamento da conex\u00e3o. <\/p>\n
Por meio da especifica\u00e7\u00e3o de m\u00faltiplos valores no cabe\u00e7alho \u2018Transfer-Encoding\u2019, um atacante poderia criar condi\u00e7\u00f5es nas quais uma solicita\u00e7\u00e3o redirecionada ao backend teria um tamanho real que n\u00e3o corresponde ao tamanho da cadeia chunked, calculado com base no cabe\u00e7alho \u2018Transfer-Encoding\u2019. O Pingora redirecionava todos os dados recebidos como uma \u00fanica solicita\u00e7\u00e3o, enquanto o backend, por exemplo, o Node.js, calculava a solicita\u00e7\u00e3o com base em \u2018Transfer-Encoding: chunked\u2019 e tratava o restante como o in\u00edcio de outra solicita\u00e7\u00e3o. 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
A segunda vulnerabilidade CVE-2026-2833 \u00e9 causada pelo processamento inadequado do cabe\u00e7alho HTTP 'Upgrade' em requisi\u00e7\u00f5es HTTP\/1.1. Quando um cabe\u00e7alho 'Upgrade' est\u00e1 presente na requisi\u00e7\u00e3o, o proxy imediatamente passa para o backend os dados da requisi\u00e7\u00e3o que se seguem ao cabe\u00e7alho 'Upgrade', sem esperar pela resposta do backend com o c\u00f3digo 101 (Switching Protocols). Isso resultava em uma sincroniza\u00e7\u00e3o quebrada entre o proxy e o backend, fazendo com que o backend tratasse os dados enviados ap\u00f3s o cabe\u00e7alho 'Upgrade' como uma requisi\u00e7\u00e3o separada, enviando a resposta de execu\u00e7\u00e3o dessa requisi\u00e7\u00e3o em resposta a uma requisi\u00e7\u00e3o subsequente de outro usu\u00e1rio. GET \/ HTTP\/1.1 Host: example.com Upgrade: foo GET \/admin HTTP\/1.1 Host: example.com
<\/center>
<\/center> <\/p>\n
Os problemas se manifestam ao usar o Pingora na forma de proxy reverso (ingress proxy), retransmitindo as requisi\u00e7\u00f5es dos usu\u00e1rios para os backends utilizando os protocolos HTTP\/1.0 ou HTTP\/1.1. A configura\u00e7\u00e3o do Pingora na rede de entrega de conte\u00fado Cloudflare n\u00e3o permitia a explora\u00e7\u00e3o de vulnerabilidades, pois o Pingora no CDN n\u00e3o \u00e9 utilizado na fun\u00e7\u00e3o de proxy ingress, redirecionando requisi\u00e7\u00f5es apenas com o protocolo HTTP\/1.1, bloqueia requisi\u00e7\u00f5es com valores incorretos de Content-Length, redireciona somente um valor do cabe\u00e7alho 'Transfer-Encoding: chunked' e insere um cabe\u00e7alho adicional 'Connection: close' em requisi\u00e7\u00f5es com o cabe\u00e7alho 'Upgrade:', que impede o envio de requisi\u00e7\u00f5es adicionais na mesma conex\u00e3o. <\/p>\n
A terceira vulnerabilidade CVE-2026-2836 (n\u00edvel de severidade 8.4 de 10) leva \u00e0 contamina\u00e7\u00e3o de cache (cache poisoning) devido \u00e0 gera\u00e7\u00e3o da chave de armazenamento de dados em cache (CacheKey) apenas com base no caminho do URI, ignorando o conte\u00fado do cabe\u00e7alho 'Host'. Essa falha resulta na forma\u00e7\u00e3o de chaves de cache id\u00eanticas para caminhos HTTP iguais em hosts diferentes. A vulnerabilidade pode ser utilizada para substituir o conte\u00fado do cache ao usar o modo de cache para m\u00faltiplos hosts. No Pingora, o cache \u00e9 uma fun\u00e7\u00e3o experimental, n\u00e3o recomendada para implementa\u00e7\u00f5es em produ\u00e7\u00e3o. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"Vulnerabilidades](\"\/wp-content\/uploads\/2026\/03\/6a4654a05c9ff8c64cc4cb4773bf4ec9.png\")
<\/center> <\/p>\n![\"Vulnerabilidades](\"\/wp-content\/uploads\/2026\/03\/f86f840431a9be00c4cfd74cc6b4c89b.png\")
<\/center> ![\"Vulnerabilidades](\"\/wp-content\/uploads\/2026\/03\/8b23d0642fc0b783c2027b91078607e4.png\")
<\/center> <\/p>\n