{"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\/da\/blog\/news\/uyazvimosti-v-proekte-pingora-pozvolyayushhie-vklinitsya-v-storonnie-zaprosy","title":{"rendered":"S\u00e5rbarheder i Pingora-projektet, der muligg\u00f8r indspr\u00f8jtning af tredjeparts foresp\u00f8rgsler","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Cloudflare har annonceret, at tre s\u00e5rbarheder i Pingora-rammen er blevet rettet, hvoraf to er vurderet til en kritisk faregrad (9,3 ud af 10). Pingora-rammen er skrevet i Rust og er designet til at udvikle sikre, h\u00f8jtydende netv\u00e6rkstjenester. Proxyen bygget ved hj\u00e6lp af Pingora anvendes i Cloudflares indholdsleveringsnet og h\u00e5ndterer over 40 millioner anmodninger pr. sekund. S\u00e5rbarhederne er blevet udbedret i udgivelsen Pingora 0.8.0. <\/p>\n
De to mest alvorlige s\u00e5rbarheder muligg\u00f8r angreb af typen \u201cHTTP Request Smuggling\u201d, som kan omg\u00e5 adgangskontrolsystemer og infiltrere indholdet af anmodninger fra andre brugere, der behandles i samme str\u00f8m mellem frontend og backend (for eksempel for at inds\u00e6tte skadelig JavaScript-kode i sessionen af en anden bruger med webstedet). Problemerne blev identificeret af en deltager i Bug Bounty-programmet, der tilbyder bel\u00f8nninger for at opdage s\u00e5rbarheder. <\/p>\n
I ordningen med adgang til backend gennem en omvendt proxy modtager en ekstra node klientanmodninger og opretter en langvarig TCP-forbindelse til backend'en, der udf\u00f8rer den direkte behandling af anmodninger. Gennem denne f\u00e6lles forbindelse overf\u00f8res normalt anmodninger fra forskellige brugere sekventielt ad gangen, adskilt af HTTP-protokolens midler. Angreb af typen HTTP Request Smuggling opst\u00e5r p\u00e5 grund af forskellig fortolkning af HTTP-headere og specifikationer af HTTP-protokollen p\u00e5 frontend og backend, for eksempel n\u00e5r frontend'en bruger HTTP-headeren \u201cContent-Length\u201d til at bestemme anmodningens st\u00f8rrelse, mens backend'en bruger \u201cTransfer-Encoding: chunked\u201d. <\/p>\n
Den f\u00f8rste s\u00e5rbarhed CVE-2026-2835 findes i koden til parsing af HTTP\/1.0-anmodninger og skyldes fejlagtig behandling af headeren \u201cTransfer-Encoding\u201d med flere v\u00e6rdier, samt brugen af forbindelseslukning som tegn p\u00e5 slutningen af anmodningens krop (close-delimited). Pingora kontrolled kun varianten \u201cTransfer-Encoding: chunked\u201d og ignorerede denne header, hvis der var angivet flere v\u00e6rdier i den. I denne situation tog Pingora ikke h\u00f8jde for st\u00f8rrelsen i headeren \u201cContent-Length\u201d, men betragtede alle data modtaget indtil forbindelseslukningen som anmodningens krop. <\/p>\n
Ved at angive flere v\u00e6rdier i headeren \u201cTransfer-Encoding\u201d kunne angriberen skabe forhold, hvor anmodningen, der blev omdirigeret til backend'en, ikke havde en faktisk st\u00f8rrelse, der svarede til st\u00f8rrelsen af chunked-k\u00e6den beregnet ud fra headeren \u201cTransfer-Encoding\u201d. Pingora omdirigerede alle modtagne data som \u00e9n anmodning, mens backend'en, for eksempel Node.js, beregnede anmodningen baseret p\u00e5 \u201cTransfer-Encoding: chunked\u201d og behandlede den resterende del som begyndelsen p\u00e5 en anden anmodning. 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
Den anden s\u00e5rbarhed CVE-2026-2833 skyldes ukorrekt h\u00e5ndtering af HTTP-headeren \u00abUpgrade\u00bb i HTTP\/1.1-anmodninger. Hvis en anmodning indeholder headeren \u00abUpgrade\u00bb, sendte bagudviklingen straks ogs\u00e5 de \u00f8vrige data fra anmodningen, der f\u00f8lger efter headeren \u00abUpgrade\u00bb, videre til backend, uden at vente p\u00e5 et svar fra backend med kode 101 (Switching Protocols). Dette f\u00f8rte til, at synkroniseringen af str\u00f8mmen mellem proxyen og backend blev forstyrret, og backend opfattede data, der blev sendt efter headeren \u00abUpgrade\u00bb, som en separat anmodning, og sendte resultatet af denne anmodning som svar p\u00e5 den f\u00f8lgende anmodning fra en anden bruger. GET \/ HTTP\/1.1 Host: example.com Upgrade: foo GET \/admin HTTP\/1.1 Host: example.com
<\/center>
<\/center> <\/p>\n
Problemerne opst\u00e5r ved brug af Pingora i form af en omvendt proxy (ingress proxy), der videresender brugerens anmodninger til backends ved hj\u00e6lp af HTTP\/1.0 eller HTTP\/1.1 protokoller. Den konfiguration, der anvendes i Cloudflares Content Delivery Network (CDN), tillod ikke udnyttelse af s\u00e5rbarheder, da Pingora i CDN ikke anvendes som ingress-proxy, viderekobler anmodninger kun ved hj\u00e6lp af HTTP\/1.1-protokollen, blokerer anmodninger med ukorrekte v\u00e6rdier for Content-Length, viderekobler kun et enkelt v\u00e6rdifelt fra headeren \u00abTransfer-Encoding: chunked\u00bb, og tilf\u00f8jer til anmodninger med headeren \u00abUpgrade:\u00bb en ekstra header \u00abConnection: close\u00bb, som forhindrer overf\u00f8rsel af yderligere anmodninger i samme forbindelse. <\/p>\n
Den tredje s\u00e5rbarhed CVE-2026-2836 (fareniveau 8.4 ud af 10) f\u00f8rer til cacheforgiftning (cache poisoning) p\u00e5 grund af genereringen af cachelagringsn\u00f8gle (CacheKey) baseret udelukkende p\u00e5 stien fra URI, mens indholdet af headeren \u00abHost\u00bb ignoreres. En s\u00e5dan mangel resulterer i dannelsen af identiske cachelagringsn\u00f8gler for de samme HTTP-stier til forskellige v\u00e6rter. S\u00e5rbarheden kan bruges til at \u00e6ndre cacheindholdet i situationer med cachen til flere v\u00e6rter. I Pingora er caching en eksperimentel funktion, der ikke anbefales til produktionsimplementeringer. \n Kilde: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"
![\"S\u00e5rbarheder](\"\/wp-content\/uploads\/2026\/03\/6a4654a05c9ff8c64cc4cb4773bf4ec9.png\")
<\/center> <\/p>\n![\"S\u00e5rbarheder](\"\/wp-content\/uploads\/2026\/03\/f86f840431a9be00c4cfd74cc6b4c89b.png\")
<\/center> ![\"S\u00e5rbarheder](\"\/wp-content\/uploads\/2026\/03\/8b23d0642fc0b783c2027b91078607e4.png\")
<\/center> <\/p>\n