CVE-2026-105299 in Pingora
الملخص
بحسب VulDB • 20/10/2026
الملخص
قبل الإصدار 0.9.0، كان مسار HTTP/1 إلى الخادم الخلفي (upstream) في pingora-proxy يمرر الطلبات الواردة من العميل عبر `upstream_request_filter` ويكتبها إلى الخادم الخلفي دون إزالة رأس الاتصال (Connection header) الخاص بالعميل، أو رؤوس أخرى الخاصة بنقطة لنقطة (hop-by-hop headers)، أو الرؤوس التي يحددها رأس Connection، على الرغم من أن القسم 7.6.1 من RFC 9110 يفرض على الوسيطات إزالتها. كان مسار HTTP/2 إلى الخادم الخلفي يقوم بالفعل بإزالة رأس Connection والرؤوس الأخرى الخاصة بـ HTTP/1. لذلك، يمكن للعميل تحديد رأس يضيفه التطبيق في `upstream_request_filter` (على سبيل المثال: Connection: keep-alive, X-Forwarded-For). ثم تقوم وسيطة HTTP/1 تابعة للشبكة السفلية (downstream) تحترم رؤوس Connection بإزالة الرأس المضاف من قبل Pingora قبل وصوله إلى الخادم الأصلي.
التأثير
يؤثر ذلك بشكل خاص على عمليات النشر المتسلسلة حيث تعالج وسيطة HTTP/1 موجودة بين Pingora والخادم الأصلي ترشيحات رأس Connection (على سبيل المثال: Go's net/http/httputil.ReverseProxy) ويثق الخادم الأصلي بالرؤوس المضافة من قبل تلك الوسيطة (مثل X-Forwarded-For للمصادقة القائمة على عنوان IP). يمكن لمهاجم عن بُعد وغير مصرح له إزالة هذه الرؤوس، مما قد يتيح تجاوز عمليات المصادقة. أظهر المُبلغ إمكانية الوصول إلى نقطة نهاية مقيدة بناءً على عناوين IP باستخدام X-Forwarded-For للتحقق من صحة العنوان في الخادم الأصلي. هذا هو نفس فئة المشكلة الموجودة في CVE-2022-31813 بخدمة Apache HTTP Server.
يرجى ملاحظة أن عملاء Cloudflare CDN لم يتأثروا، حيث لا يوجد مثل هذا النشر المتسلسل الموصوف أعلاه مع خدمات Pingora الداخلية، ويتم تنقية رؤوس Connection قبل وصولها إلى بوابات Pingora.
التخفيف:
*
قم بالترقية إلى pingora الإصدار 0.9.0 أو أحدث. بشكل افتراضي، يقوم Pingora الآن بإزالة الرؤوس الخاصة بنقطة لنقطة والرؤوس التي يحددها رأس Connection من طلبات الخادم الخلفي، ويرفض الطلبات التي يحدد فيها رأس Connection رؤوس Host, X-Forwarded-For, X-Forwarded-Host, X-Forwarded-Proto، أو رأس زائف (pseudo-header). يتم التحكم في ذلك بواسطة `PeerOptions::http_upstream_request_policy` (`HttpUpstreamRequestPolicy`). تصحيحات الإصلاح: https://github.com/cloudflare/pingora/commit/28c18e6b6b04dd0bd937234e5950049e6d74cded , https://github.com/cloudflare/pingora/commit/ca23f1668eca8e78be7ba62ef0edbd458b40eeee
*
لا تستخدم `HttpUpstreamRequestPolicy::preserve()` إذا كان الخادم الأصلي يعتمد على الرؤوس المضافة من قبل Pingora؛ حيث يعيد ذلك سلوك الإرسال المباشر القديم.
*
إذا لم تتمكن من الترقية: في دالة `upstream_request_filter`، قم بإزالة رأس Connection وكل الرأس التي يحددها قبل إضافة الرؤوس الموثوقة.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.