CVE-2026-69246 in Guzzle
الملخص
بحسب VulDB • 04/08/2026
Guzzle هو عميل HTTP قابل للتوسيع في لغة PHP. قبل الإصدارين 7.15.2 و 8.0.1، كان Guzzle يمرر عنوان URI للطلب كسلسلة نصية ويوفر رأس Host بشكل منفصل. تقوم معالجات cURL بتعيين CURLOPT_URL إلى العنوان كما هو مكتوب تماماً وتدفع قيمة Header هذه ضمن CURLOPT_HTTPHEADER؛ ويقوم StreamHandler بذلك أيضاً عبر fopen(). بعد ذلك، يقوم libcurl بتحليل السلطة (authority) بنفسه، حيث يفك تشفير النسبة المئوية (percent-decoding)، وفي الإصدارات القادرة على التعامل مع النطاقات الدولية للأسماء المستضافة (IDN-capable build)، يطبق تعيين IDNA، ويستخدم النتيجة لحل الاسم، وإنشاء الاتصال، وتسمية نظير TLS ومعالجة طلب CONNECT للوكيل. في المقابل، فإن قيمة Host المقدمة تكبح القيمة المتوافقة التي كان من الممكن أن يولدها libcurl. بالنسبة لعنوان URI مكتوباً كـ 127.0.0.%31، ترفض دالة filter_var() العنوان باعتباره حرفياً خاصاً بعنوان IP (IP literal)، بينما يقوم libcurl بفك تشفيره إلى 127.0.0.1 ويصل إلى حلقة العودة المحلية (loopback) دون إجراء بحث DNS، في حين يتلقى الخادم قيمة Host: 127.0.0.%31. لذلك، يمكن لمهاجم يؤثر على عنوان URI يتم جلبه الوصول إلى مضيف استبعدته فحوصات التطبيق وقراءة أي بيانات يكشف عنها المضيف من الاستجابة. يؤدي نفس التباين أيضاً إلى تحويل قرارات Guzzle الخاصة به نحو تهجئة لا يستخدمها النقل: حيث تختار no_proxy توجيه الوكيل بناءً على العنوان الحرفي، ويقرر RedirectMiddleware ما إذا كان يجب إزالة Authorization و Cookie استناداً إليه. يتطلب الاستفادة من هذه الثغرة أن يقوم التطبيق ببناء عنوان URI للطلب من مدخلات غير موثوقة وأن يتخذ قراراً بشأن المضيف قبل تسليمه إلى Guzzle. تم إصلاح هذه المشكلة في الإصدارين 7.15.2 و 8.0.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.