تغيّر ثغرة عالية الخطورة في curl وlibcurl الطريقة المعتادة للتفكير في أمن أدوات العميل. تُفعَّل CVE-2026-92392 أثناء عملية رفع عبر HTTP/2، لكن الطرف المعادي هو الخادم الذي يستقبل الرفع. يستطيع خادم خبيث إرسال استجابة محددة لإعادة ضبط التدفق بينما يرسل العميل البيانات، ما يترك curl محتفظاً بمرجع إلى كائن جرى تحريره بالفعل. والنتيجة هي تلف في الذاكرة، ويقول مشروع curl إن الخطأ ثبتت قابليته للتحول إلى تنفيذ تعليمات عن بُعد عندما تجتمع مجموعة دقيقة من شروط البناء والمعمارية ومخصّص الذاكرة والتوقيت والبروتوكول.

رسم توضيحي تحريري للأمن السيبراني: يصل رفع HTTP/2 إلى خادم بينما يتابع المهندسون تصحيح curl وجرد التبعيات.

يوجد الإصلاح في curl وlibcurl 8.23.0، اللذين أُطلقا في 14 أكتوبر 2026. وتشمل النطاقات المتأثرة الإصدارات من 8.12.0 حتى 8.22.0. وتكتسب هذه الحدود أهمية لأن libcurl مدمج كثيراً في التطبيقات ومكوّنات أنظمة التشغيل وأدوات الأتمتة ومديري الحزم ومنتجات الأمن والخدمات التي لا تعلن عن استخدام curl. لذلك قد يؤدي تحديث البرنامج التنفيذي لسطر الأوامر على محطة عمل مسؤول واحد إلى ترك النسخ الأهم دون معالجة.

هذه قصة تصحيح، لكنها ليست قصة بسيطة من نوع «شغّل التحديث في كل مكان». المهمة الأولى هي اكتشاف المواضع التي يُستخدم فيها curl لإجراء عمليات رفع عبر HTTP/2، سواء من خلال مكتبة أو تطبيق مرتبط بها ثابتاً. والثانية هي تقرير ما إذا كان خفض قدرة البروتوكول مؤقتاً أمراً عملياً إلى أن تمر الحزمة الدائمة عبر حزم المورّد ونوافذ التغيير في الإنتاج. والثالثة هي التحقق من أن الأنظمة التي ترفع الملفات لا يُسمح لها بالاتصال إلا بالوجهات المقصودة.

ما الذي تتأثر به CVE-2026-92392 فعلياً

يصف تنبيه curl ثغرة استخدام بعد التحرير في مسار رفع HTTP/2. أثناء الرفع، يستطيع الخادم إصدار رسالة HTTP/2 من نوع RST_STREAM بسبب HTTP_1_1_REQUIRED أو REFUSED_STREAM. وقد يظل الاتصال نفسه حياً بينما تتوقف عملية النقل الفردية. وفي حالة آلة الحالات المتأثرة، ينظف curl عملية النقل والاتصال لاحقاً بترتيب يترك مرجعاً معلّقاً إلى كائن النقل.

لا يعني الاستخدام بعد التحرير تلقائياً أن كل استدعاء سيتحول إلى تنفيذ تعليمات. معناه أن البرنامج يواصل استخدام ذاكرة بعد أن حرر مالكها تلك الذاكرة. وبحسب ما يشغلها تالياً، قد تكون النتيجة المباشرة انهياراً أو حالة فاسدة أو كشفاً للمعلومات أو فشلاً أكثر قابلية للتحكم من ناحية سلامة الذاكرة. في هذه الحالة يصنّف مشروع curl المشكلة بدرجة خطورة عالية، ويوثق مساراً من خطأ الذاكرة إلى تنفيذ تعليمات عن بُعد.

الإصدارات المتأثرة هي curl وlibcurl من 8.12.0 إلى 8.22.0، شاملةً الطرفين. الإصدارات السابقة لـ8.12.0 لا تتأثر بهذا الخلل بعينه، بينما يتضمن 8.23.0 الإصلاح. والتمييز بين curl وlibcurl مهم تشغيلياً: فأداة سطر الأوامر مستهلك واحد، في حين قد يستدعي عدد أكبر بكثير من التطبيقات المكتبة مباشرة. ويمكن لخادم لا يشغّل الملف التنفيذي curl مطلقاً أن يظل مكشوفاً من خلال تطبيق مرتبط بـlibcurl.

تتطلب الثغرة HTTP/2. وهذا لا يعني أن كل عملية نقل HTTPS معرضة تلقائياً، لكنه يعني أن الفرق لا ينبغي أن يستنتج الأمان لمجرد أن المستخدمين لم يمرروا خيار HTTP/2 صراحة. يمكن لـcurl التفاوض على HTTP/2 عند الاتصال بخدمة HTTPS تعرضه، وعندما يتضمن البناء المحلي الدعم المناسب. كما قد تختار التطبيقات HTTP/2 صراحة من خلال خيارات libcurl أو أطر الشبكات الأعلى مستوى.

العملية المعرضة للخطر هي رفع من العميل إلى الخادم. أما التنزيلات العادية فليست السيناريو الذي يصفه التنبيه. وهذا يضيّق نطاق التعرض، لكنه لا يجعل المشكلة نادرة أو غريبة. فوكالات النسخ الاحتياطي وناشرو المخرجات البرمجية وعملاء القياس عن بُعد وخدمات إدخال المستندات وأنظمة التكامل المستمر وموصلات السحابة وأدوات دعم العملاء وبرامج المزامنة وواجهات البرمجة الداخلية ترسل البيانات إلى الخارج عادةً. وبعضها يستخدم curl في جزء صغير واحد من سير عمل أكبر، وهو بالضبط ما يجعل جرد الحزم وحده غير كافٍ لاكتشاف التعرض العملي.

المهاجم موجود في جهة الاستقبال

تبدأ كثير من أدلة الدفاع بافتراض أن الخادم الخطير هو الخادم الذي يقدّم التنزيل. أما CVE-2026-92392 فتقلب هذا التصور. يبدأ العميل رفعاً إلى خادم يعتقد أنه موثوق، ويمكن للخادم أن يكون المكوّن الذي يقدّم سلوك البروتوكول المعادي.

هذا لا يعني أن المهاجم يستطيع استغلال أي عملية curl بمجرد وضع صفحة خبيثة على الإنترنت. يجب أن تتصل العملية الضحية بخادم يسيطر عليه المهاجم أو يستطيع التأثير فيه، وأن تنفذ عملية رفع، وأن تتفاوض على HTTP/2، وأن تتحقق شروط التنفيذ اللازمة للوصول إلى تسلسل التنظيف الضعيف. وفي بيئة فعلية قد يحدث ذلك عبر نقطة نهاية خبيثة عمداً، أو خدمة مخترقة، أو سير عمل أعيد توجيهه، أو وجهة رفع يختارها المستخدم، أو تطبيق يقبل إعدادات بعيدة. ويعتمد المسار الدقيق على المنتج المحيط.

يسرد مشروع curl متطلبات دقيقة على نحو غير معتاد لتحويل الخلل إلى تنفيذ تعليمات. يحتاج المهاجم إلى معرفة إصدار curl الدقيق وتخطيط الكائنات، وتفاصيل معمارية الهدف، ومخصّص libc وتخطيط heap متوافقين، وتأثيرات متوقعة من nghttp2 وTLS 1.3، وتوقيت مضبوط بعناية عبر عمليات نقل متوازية. كما أن الاستغلال المنشور مقيد بعدد قصير من الأوامر. تجعل هذه الشروط الاستغلال الموثوق صعباً، لكنها ليست سبباً لاعتبار المشكلة غير مؤذية. فكثير من سلاسل الهجوم الحديثة تبدأ بانهيار أو تلف جزئي للذاكرة ثم تتحسن مع توفر تفاصيل الهدف.

يميز السجل العام حالياً بين قابلية الاستغلال والاستغلال المعروف. يوثق التنبيه إثبات مفهوم ومساراً إلى تنفيذ التعليمات في ظروف دقيقة. أما إدخال NVD فلا يقدم تقييماً خاصاً به لـCVSS ولا يقول إن الثغرة تُستغل في البرية. ومع ذلك يظل إثبات المفهوم العلني إشارة مهمة للمدافعين، خصوصاً حيث يكون curl مدمجاً في خدمات طويلة العمر أو يجري تحديثه ببطء. وهو ليس دليلاً على اختراق كل تثبيت معرض.

لماذا يستحق إصدار 8.23.0 معالجة دقيقة

جاء الإصلاح ضمن إصدار منسق لـcurl عالج أيضاً 23 مشكلة أمنية منشورة أخرى، صُنّف معظمها منخفض الخطورة من جانب المشروع. وتمثل CVE-2026-92392 المشكلة الوحيدة عالية الخطورة في الإصدار. ويخلق هذا التجميع خطرين تشغيليين متعارضين. فقد ترى بعض الفرق عدداً كبيراً من التنبيهات فتتوقف لأن الترقية تبدو معقدة. وقد تحدّث فرق أخرى حزمة سطر أوامر ظاهرة وتفترض أن كامل رسم التبعيات أصبح مشمولاً.

الاستجابة الصحيحة تفصل بين الإلحاح والتوحيد. الأولوية العاجلة هي تحديد البنى الضعيفة التي تنفذ عمليات رفع، ونقل تلك الأنظمة إلى حزمة مورّد ثابتة أو إلى curl وlibcurl 8.23.0. وقد يختلف مسار التنفيذ حسب نظام التشغيل أو صورة الحاوية أو بيئة اللغة أو الجهاز أو التطبيق التجاري. وقد تعيد حزمة libcurl التي يديرها التوزيع تضمين الإصلاح من دون تغيير رقم الإصدار upstream بالطريقة التي يتوقعها فحص إصدار بسيط. لذلك ينبغي لفرق الأمن تأكيد تنبيه المورّد وسجل تغييرات الحزمة، لا الاعتماد على مقارنة سلسلة نصية واحدة.

لم يغيّر الإصدار شفرة الأمن وحدها. فقد أزال المشروع دعم SMB وSMBS وأدخل تغييرات سلوكية أخرى وإصلاحات للأخطاء. ولا يجعل ذلك الترقية غير آمنة، لكنه يؤكد الحاجة إلى اختبار التطبيقات التي تعتمد على بروتوكولات أقل شيوعاً أو تدفقات مصادقة غير معتادة أو خلفيات TLS مخصصة أو سلوك صارم في التعامل مع الملفات. لا ينبغي تأخير الإصلاح الأمني انتظاراً لمجموعة اختبارات عالمية مثالية، لكن النشر المرحلي قد يمنع المعالجة نفسها من تعطيل خدمة رفع حرجة.

يحافظ curl على معلومات إصدار منفصلة للإصدارات القياسية وفروعه طويلة الدعم Rock-solid. والمنظمات التي تستهلك فرعاً طويل الدعم ينبغي أن تتحقق مما إذا كان إصدار الفرع المناسب هو 8.14.3 أو 8.16.2 أو 8.20.2، بدلاً من استبداله عشوائياً بأحدث فرع قياسي. والسؤال الحاكم ليس «ما الرقم الذي تعرضه صفحة تنزيل سطر أوامر upstream؟»، بل «أي حزمة مدعومة تتضمن إصلاح CVE-2026-92392، وكيف نثبت أن هذه الحزمة منشورة؟».

جرد عملي لهذه الثغرة

ابدأ بالتثبيتات الواضحة، لكن لا تتوقف عندها. ابحث في صور نقاط النهاية والخوادم عن الملف التنفيذي curl، واستعلم من مديري حزم نظام التشغيل، وافحص طبقات الحاويات، وراجع قوائم مكونات البرمجيات، وافحص بيانات البناء الخاصة بـlibcurl. تختلف أسماء الحزم: فقد يعرض المضيف curl أو libcurl أو حزمة تطوير أو حزمة تشغيل خاصة بالمورّد. ويمكن للربط الثابت أن يزيل المكتبة من قاعدة حزم المضيف المعتادة، لذلك تمثل بيانات إصدارات التطبيقات وSBOM أدلة ثمينة.

أضف بعد ذلك السلوك إلى الجرد. السجلات الأعلى أولوية هي للعمليات التي تحقق الشروط التالية كلها:

  • تشغّل بناءً ضعيفاً من curl أو libcurl؛
  • ترفع ملفات أو أجسام طلبات إلى خدمة بعيدة؛
  • تسمح بالتفاوض على HTTP/2 أو تفعّل HTTP/2 صراحة؛
  • وتتعامل مع بيانات أو بيانات اعتماد ستكون خسارتها مؤثرة.

لا ينبغي أن يعامل مستوى الاستعجال نفسه مكتبة ضعيفة تُستخدم فقط لتحليل بيانات وصفية محلية وخدمة أتمتة مكشوفة للعامة ترفع بيانات اعتماد أو مخرجات بناء أو مستندات عملاء أو نسخاً احتياطية. وينبغي أن يأخذ ترتيب الخطر في الحسبان أيضاً من يسيطر على الوجهة. فالقائمة الثابتة لنقاط نهاية المورّدين تعرضاً مختلفاً عن أداة تقبل عنوان URL عشوائياً من مستخدم أو معلمة مهمة أو webhook أو ملف إعدادات بعيد.

بالنسبة إلى المنتجات المرتبطة ثابتاً أو غير الشفافة، اطلب من المورّد ثلاث إجابات محددة: هل يتضمن المنتج curl أو libcurl ضمن النطاق المتأثر؟ هل يمكن تنفيذ عمليات رفع HTTP/2؟ وما البناء الذي يحتوي على الإصلاح؟ احتفظ بالإجابة مع سجل الأصل. فعبارة «المنتج يستخدم HTTPS» لا تكفي للتقييم، وعبارة «المنتج لا يعرض curl في واجهته» ليست إجابة عن تبعياته المدمجة.

وتحتاج بيئات الحاويات إلى فحص إضافي. فتحديث المضيف لا يحدّث صورة قديمة، وإعادة بناء صورة تطبيق لا تستبدل بالضرورة مكتبة curl المنسوخة إلى المرحلة النهائية. افحص كلاً من الصورة المشغلة حالياً والصورة التي ستُرقّى تالياً. وإذا كان المنسق يحتفظ بنسخ قديمة أثناء نشر تدريجي، فتأكد من أن كل نسخة نشطة غادرت النطاق المتأثر قبل إغلاق حادثة الأمن أو تذكرة الثغرة.

إجراءات تخفيف مؤقتة إلى أن تتحرك الرقع

يسرد تنبيه curl تجنب HTTP/2 كخيار احتياطي عندما لا تكون الترقية أو التصحيح ممكنين فوراً. هذه وسيلة تخفيف وليست بديلاً عن المعالجة. ففي سير عمل سطر الأوامر قد يستطيع المشغّل فرض HTTP/1.1 لعملية نقل محددة بدقة. أما في التطبيق فقد يكون الإعداد المكافئ خياراً في المكتبة أو سياسة proxy أو قاعدة في شبكة الخدمات أو إعداداً من المورّد. ويجب اختبار الضبط: تعطيل HTTP/2 في غلاف واحد لا يفيد إذا كان التطبيق الأساسي يفتح اتصالاً منفصلاً عبر مسار شيفرة آخر.

وقد يسبب تقييد البروتوكول مؤقتاً آثاراً جانبية. فبعض الخدمات تتطلب HTTP/2 أو تستخدم تعدد الإرسال على الاتصال لتحسين الأداء أو تطبق سلوكاً مختلفاً للمصادقة والمهل الزمنية حسب البروتوكول. وثّق الاستثناء، وحدد مالكه، وضع تاريخ انتهاء. أما الإجراء الذي يستمر بلا نهاية لأن لا أحد يعرف هل ما زال فعالاً، فسيتحول إلى مشكلة جرد أخرى.

وحيثما أمكن، قيّد وجهات الرفع خلال الفترة الانتقالية. طبّق قوائم سماح للخروج في المهام الآلية، وارفض الوجهات التي يحددها المستخدم ما لم يحتج سير العمل إليها صراحة، وتحقق من عمليات إعادة التوجيه بدلاً من اتباع سلسلة بصمت إلى مضيف غير متوقع. تقلل هذه الإجراءات احتمال وصول عميل ضعيف إلى خادم استقبال خبيث، لكنها لا تستبدل الرقعة: فقد تُخترق وجهة شرعية، وقد تتضمن قائمة السماح الواسعة بنية تحتية يسيطر عليها مهاجم.

لا تستجب بتعطيل التحقق من الشهادات أو إضعاف TLS. فتشمل شروط الاستغلال في التنبيه خادماً يمر من فحوص شهادة العميل، وهو تذكير بأن مصادقة النقل العادية ليست دفاعاً كاملاً ضد نقطة نهاية مخترقة أو يديرها طرف خبيث. وإزالة التحقق من الشهادة ستوسّع سطح الهجوم من دون معالجة خطأ سلامة الذاكرة.

ما الذي ينبغي فحصه إذا تعرض عميل ضعيف

وجود إصدار ضعيف ليس دليلاً على الاختراق، كما أن الانهيار ليس دليلاً على الاستغلال. ومع ذلك يستحق عميل رفع مكشوف مراجعة متناسبة مع الخطر. حدد الوجهات التي اتصل بها خلال الفترة ذات الصلة، والملفات أو أجسام الطلبات التي أرسلها، والبناء الدقيق لـcurl أو libcurl، وما إذا جرى التفاوض على HTTP/2. وقد تجيب سجلات التطبيق وسجلات proxy وقياس TLS وسجلات العمليات على نقطة النهاية عن هذه الأسئلة حتى عندما لا يسجل curl نفسه إلا خطأ نقل عاماً.

ابحث عن إنهاء غير معتاد للعملية، ومحاولات متكررة تجاه نقطة نهاية غير مألوفة، وتغير في العمليات الابنة التي يطلقها برنامج الرفع، وملفات غير متوقعة، واتصالات صادرة بدأت مباشرة بعد نقل فاشل. هذه مؤشرات فرز وليست بصمات فريدة لـCVE-2026-92392. فقد ينتج فشل الرفع الطبيعي محاولات إعادة، وقد يؤدي الانهيار إلى إعادة تشغيل، لذا يجب ربط التفسير بالسلوك المتوقع للمضيف.

إذا كانت العملية تملك وصولاً إلى بيانات اعتماد أو رموز أو مفاتيح توقيع أو ملفات محلية حساسة، فقيّم ذلك الوصول بصورة منفصلة. الثغرة المنشورة مشكلة في سلامة ذاكرة العميل، ولا توصف بأنها خلل مباشر في كشف بيانات الاعتماد. لكن تنفيذ التعليمات بنجاح داخل برنامج رفع قد يكشف الامتيازات والبيانات المتاحة للعملية. دوّر الأسرار عندما لا يستطيع التحقيق إثبات بقاء العملية داخل حدودها المتوقعة، واحفظ السجلات ذات الصلة قبل أن تزيلها سياسة الاحتفاظ الاعتيادية.

وفي الأنظمة ذات القيمة العالية، قارن البناء الضعيف بالبناء الثابت واحتفظ بدليل التحديث. سجّل checksum الحزمة أو digest الصورة، وإصدار العملية المشغلة، وتوقيت النشر. وإذا قدم مورّد المنتج إصلاحاً عاجلاً بدلاً من إصدار upstream، فسجّل نشرة المورّد ومعرّف بناء الحزمة. وهذه الأدلة أنفع من تعليق في تذكرة يقول «تم تصحيح curl»، خصوصاً عندما توجد عدة نسخ من المكتبة على المضيف نفسه.

ما الذي ينبغي للمطورين تغييره

ينبغي للمطورين التعامل مع libcurl بوصفها جزءاً من حدود أمن التطبيق، لا أداة قابلة للاستبدال مخفية أسفل منطق الأعمال. فتثبيت إصدار في ملف بناء لا يكفي إذا كانت صورة التشغيل توفر مكتبة مشتركة مختلفة، أو كانت الصورة الأساسية قديمة، أو حل مدير الحزم إصداراً ضعيفاً أثناء إعادة البناء. اجعل التبعية ظاهرة في SBOM، واجعل مسار تحديثها قابلاً للتكرار.

راجع شيفرة الرفع من حيث التحكم في الوجهة وسلوك إعادة التوجيه ومنطق إعادة المحاولة واختيار البروتوكول. فالخدمة التي ترفع فقط إلى نقطة نهاية ثابتة تختلف في نموذج التهديد عن خدمة تقبل عناوين URL عشوائية. وقد تنفذ مكتبة إعادة المحاولة اتصالاً ثانياً بخيارات مختلفة عن الاتصال الأول. وقد يتفاوض proxy على HTTP/2 حتى عندما لا يستدعي التطبيق ذلك صراحة. ينبغي للمراجعة الأمنية أن تتبع مسار الاتصال الحقيقي، لا ملف الإعداد الأكثر سهولة للفحص.

حد من امتيازات عمال الرفع. شغّلهم بأقل قدر من وصول الملفات والشبكة وبيانات الاعتماد الذي تحتاجه المهمة. استخدم هويات منفصلة لقراءة ملف محلي ونشره، وتجنب منح عامل نقل عام صلاحية بيانات اعتماد إدارة السحابة أو مفاتيح التوقيع أو مقبس حاويات المضيف. لا يلغي مبدأ أقل الامتيازات الثغرة، لكنه قد يحول حادث تنفيذ تعليمات إلى حادث خدمة محصور بدلاً من اختراق أوسع للمضيف.

أضف اختبارات للمسارات السلبية حول عمليات نقل HTTP/2 المتقطعة وإعادات ضبط الخادم وإعادة المحاولات والتنظيف. الهدف ليس إعادة إنتاج الاستغلال في الإنتاج أو بناء قدرة هجومية. الهدف هو التحقق من أن التطبيق يعالج النقل الفاشل بأمان، وأن التبعية الثابتة محمّلة فعلاً، وأن سلوك إعادة التشغيل وإعادة المحاولة لا ينشئ مساراً ثانياً يتجاوز التحديث.

ما الذي ينبغي لفرق التشغيل إبلاغه

يكون الإشعار الداخلي الأكثر فائدة دقيقاً: تؤثر CVE-2026-92392 في curl وlibcurl من 8.12.0 إلى 8.22.0؛ ويتضمن السيناريو الضعيف رفعاً عبر HTTP/2؛ والإصدار upstream الثابت هو 8.23.0؛ وتُحتسب نسخ المكتبة المدمجة أيضاً. تجنب إخبار كل موظف بتحديث متصفح أو التوقف عن استخدام الإنترنت. فمعظم الناس لا يديرون تدفقات الرفع المتأثرة، والتحذيرات العشوائية تجعل سماع التنبيه الجاد التالي أصعب.

اطلب من مالكي الخدمات الإبلاغ عما إذا كانت أنظمتهم ترفع بيانات، والوجهات التي تتصل بها، وما إذا كان HTTP/2 مفعلاً، وأي حزمة أو صورة توفر curl. امنحهم إجراء تخفيف مؤقتاً يمكن التحقق منه ومالكاً للتحديث الدائم. هكذا يتحول تنبيه تبعية واسع إلى مجموعة أسئلة قابلة للإجابة.

ويقدم إفصاح مشروع curl درساً أوسع. فما يزال بإمكان مكوّن ناضج خضع لتدقيق مكثف أن يشحن خللاً خطيراً في سلامة الذاكرة. لا ينبغي لهذه الحقيقة أن تطلق دورة هلع تستبدل البرمجيات الموثوقة ببدائل غير متحقق منها. بل ينبغي أن تؤدي إلى وضوح أكبر للتبعيات، وتسريع انتقال الرقع، وامتيازات أكثر أماناً للعمليات، وأدلة أوضح عن طريقة التفاوض على بروتوكولات الشبكة.

الخلاصة

تستحق CVE-2026-92392 الأولوية لأنها تجمع بين انتشار واسع للتبعية ومحفز يأتي من جهة الخادم أثناء عمليات رفع العميل. لكنها ليست سيطرة عن بُعد شاملة على كل تثبيت لـcurl، كما أن شروط الاستغلال المنشورة صعبة. وغياب مؤشر حالي على استغلال معروف لا يجعل خدمة رفع غير مصححة استثناءً مريحاً على المدى الطويل.

اعثر على كل نسخة من curl وlibcurl، وحدد النسخ التي ترفع عبر HTTP/2، وحدّث البنى الضعيفة إلى إصدار ثابت مدعوم من المورّد، واستخدم HTTP/1.1 أو تقييد الوجهات كضوابط مؤقتة فقط. ثم احتفظ بدليل على أن العملية المشغلة نفسها، لا ملف البناء أو الصورة الأساسية فحسب، تتضمن الإصلاح. تلك هي الاستجابة التي تتطلبها هذه الثغرة: محددة، واعية بالتبعيات، وهادئة بما يكفي لاكتشاف النسخ التي لم يتذكر أحد أنها موجودة.

المصادر