curl 8.23.0: أصلح ثغرة HTTP/2 Upload Use-After-Free

يعالج curl 8.23.0 الثغرة CVE-2026-92392، وهي Use-After-Free عالية الخطورة في رفع الملفات عبر HTTP/2 يمكن لخادم خبيث تشغيلها بإعادة أسباب محددة ضمن RST_STREAM. يقول مشروع curl إنه أثبت إمكانية تحويل الخلل إلى Remote Code Execution عند اجتماع شروط دقيقة تخص البيئة وHeap Layout والتزامن. على الفرق التي تشغّل curl أوlibcurl من 8.12.0 حتى 8.22.0 جرد كل Runtime ونسخة مضمّنة، والترقية إلى 8.23.0 أوتطبيق Backport موثوق، وإعادة بناء Artifacts التابعة، واستبدال الأحمال العاملة، ثم التحقق من الإصدار والمكتبة اللذين يعالجان المرور فعلًا.

نشر التنبيه مع curl 8.23.0 في 14 أكتوبر 2026، وأُعيد التحقق من المصادر في 27 أكتوبر 2026. إثبات مسار استغلال يعني أن الأثر ممكن، ولا يعني أن Deployment بعينها اختُرقت أوأن هجمات رُصدت في البرية. لا يدعي تنبيه curl وجود Active Exploitation. نطاق الإصدارات وآلية الخلل والإصلاح حقائق من المورد؛ أما خطة النشر والكشف فهي إرشاد هندسي.

القرار أولًا

أعطِ الأولوية للخدمات التي ترفع بيانات متأثرة بالمستخدم أوحساسة إلى Origins خارجية، وتشغل Transfers متزامنة، أوتستخدم libcurl داخل Workers طويلة العمر، أوتضمّن curl في Appliances وAgents وContainers. لا تحصر الجرد في أمر curl الذي يكتبه المطور؛ فـlibcurl مضمّن في تطبيقات قد لا تعلن استخدامه.

أين يوجد الخلل؟

أثناء HTTP/2 Upload يستطيع الخادم رفض Stream أوطلب تغيير طريقة التعامل عبر RST_STREAM. عند سببي HTTP_1_1_REQUIRED وREFUSED_STREAM قد تسيء الإصدارات المتأثرة إدارة حالة Retry وتستمر في استخدام كائن struct Curl_easy بعد تحريره.

تعني Use-After-Free أن منطق البرنامج يحتفظ بمؤشر بعد تحرير الذاكرة التي يشير إليها. قد تعيد Allocations اللاحقة استخدام المنطقة نفسها. قد تكون النتيجة Crash، وقد يحول التحكم في إعادة الاستخدام قراءة أوكتابة قديمة إلى Code Execution. يصنف مشروع curl المشكلة CWE-416 وخطأ Memory Safety بلغة C.

يجب أن يكون المهاجم هو Remote Server الذي يتصل به Client، أوقادرًا على التحكم في سلوك HTTP/2 لذلك الخادم. لا تصل حركة Inbound العادية إلى Web Server تلقائيًا إلى هذا المسار من جهة العميل. السؤال الصحيح: أي Processes تستخدم curl أوlibcurl للرفع عبر HTTP/2 إلى Origin يمكن للمهاجم التأثير في Responses الخاصة به؟

لماذا تحتاج عبارة «RCE ممكن» إلى سياق؟

يتطلب إثبات المشروع بيئة متطابقة بدقة. يسرد التنبيه معرفة Layout لإصدار curl والمعمارية، وlibc allocator وHeap Layout متوافقين، وسلوك nghttp2 وOpenSSL/TLS 1.3 في Allocations، وCA Bundle مثبتة، وتحويلين متوازيين بتوقيت ثابت، وOffsets مضبوطة لـlibc، وقيدًا لأمر قصير يقارب 23 Byte.

هذه الشروط لا تجعل الخلل غير مهم. لكنها تشرح لماذا لا يتساوى الوجود مع قابلية الاستغلال:

• vulnerable: توجد نسخة curl/libcurl متأثرة؛
• reachable: تنفذ Process متأثرة HTTP/2 Upload إلى خادم يمكن للمهاجم التأثير فيه؛
• attempted exploitation: تسجل Telemetry عمليات Reset مصممة وسلوكًا غير طبيعي مترابطًا؛
• confirmed compromise: يثبت دليل من Host أوProcess أوBusiness تنفيذًا غير مصرح أوأثرًا فعليًا.

لا تصف كل Binary متأثرة بأنها «مخترقة». وفي المقابل لا تنتظر Telemetry عامة للهجمات قبل إصلاح Memory Corruption أثبت المورد إمكانية تحويله إلى RCE.

ارسم خريطة curl الفعلية

ابدأ من التنفيذ لا من Package Manifest. قد يظهر curl كأداة CLI، أوShared libcurl، أوStatic Library، أوLanguage Binding، أوطبقة Base Image، أوDependency في CI Runner، أوAgent أوVendor Appliance.

# هوية CLI والقدرات المضمّنة
curl --version

# جرد Packages الشائعة
dpkg-query -W 'curl' 'libcurl*' 2>/dev/null
rpm -qa | grep -Ei '(^|-)curl|libcurl'

# مستهلكو Shared Library الشائعون
ldconfig -p 2>/dev/null | grep libcurl
find /opt /usr/local -type f -perm -111 -exec sh -c '
  for f do ldd "$f" 2>/dev/null | grep -q libcurl && printf "%s\n" "$f"; done
' sh {} +

هذه أوامر Discovery وليست إثباتًا للاكتمال. لن تظهر Static Linkage في ldd، وقد تحذف Minimal Containers أدوات Packages، وقد يحمل البرنامج libcurl ديناميكيًا أويحتفظ بنسخة خاصة. أضف Software Composition Analysis واستعلامات SBOM وإثباتات الموردين، ثم تحقق من Running Processes وContainer Digests.

سجل على الأقل: مالك الخدمة، Executable أوImage Digest، إصدار curl/libcurl، مصدر Build، دعم HTTP/2، وجهات الرفع، نموذج التزامن، TLS Backend وReplicas. إصدار curl على Host واحد لا يثبت ما ينفذه Container أوتطبيق مضمّن.

هل الإصدار مصحح فعلًا؟

النطاق Upstream واضح: تتأثر 8.12.0 حتى 8.22.0؛ ولا تتأثر إصدارات أقل من 8.12.0 ولا8.23.0 فأحدث بهذه CVE. ويسجل المشروع أيضًا الإصدارات المصححة 8.20.2 و8.16.2 و8.14.3 ضمن الفروع المصانة.

قد تحتفظ Distribution برقم Upstream يبدو قديمًا مع تطبيق Backport. لا تصف Package من Vendor بأنها متأثرة من الرقم الأول وحده. اطلب Security Advisory أوPackage Changelog من نظام التشغيل أوAppliance يربط Revision المثبتة بـCVE-2026-92392. عبارة «آخر إصدار في Repository» ليست دليلًا ما لم ينشر المستودع هذا الربط.

في Source Builds قارن Fixed Commit كدليل مساعد فقط. قد تعتمد Patch محلية على تغييرات محيطة وتغطية اختبارات في Branch. فضّل Release رسمية أوBackport مدعومة على Cherry-pick يدوي داخل شجرة غير مصانة.

حدّث Hosts وContainers والتطبيقات المضمّنة

1. ثبّت Snapshot للجرد بتاريخ واضح وعيّن Owner لكل عنصر.
2. اختر curl 8.23.0 أوBackport موثقة من Vendor.
3. أعد بناء كل Application وContainer يضمّن libcurl أويربطها Static.
4. أعد Multi-stage Images من Inputs نظيفة ومثبتة؛ لا تنسخ libcurl قديمة من Builder Stage.
5. نفذ Canary لـUpload واقعية عبر HTTP/1.1 وHTTP/2 بخوادم محكومة وFixtures آمنة.
6. استبدل كل Workers وJobs وAgents العاملة بدل تغيير الملفات تحت Process.
7. تحقق من Process وPackage وImage Digest وقدرة Protocol على كل Replica.
8. احذف Images وAutoscaling Templates الضعيفة حتى لا يعيد Rollback إدخالها.

في Kubernetes حدّث Image Reference ثابتة، ونفذ Rollout، ثم استعلم Pod Image IDs لاTags القابلة للنقل. أدرج CronJobs وJobs الموقوفة لأنها قد تبدأ لاحقًا من Template قديمة. في Serverless وManaged Agents اطلب تصريح Fixed Runtime من المزود وأعد النشر عندما تحمل Artifact نسخة libcurl خاصة بها.

تحقق من Binary التي تنفذ الرفع

يجب أن يجيب التحقق عن أربعة أسئلة مختلفة:

للتطبيق وفر Operations Diagnostic محمية تسجل إصدار libcurl الخاص بها وميزات TLS/HTTP، أوأرسلها عند Startup إلى Telemetry موثوقة. لا تنشر Version Endpoint عامة. افحص كل Replica خلف Load Balancer، واحتفظ بـDeployment Digest بجوار النتيجة.

بعد ذلك نفذ Canaries وظيفية: HTTP/2 Upload طبيعي، ومسار Fallback يطلبه الخادم، وCancellation وTimeout وRetry وConcurrent Transfer. الهدف إثبات أن Build المصححة لا تزال تحقق سلوك المنتج. لا ترسل Exploit Payloads إلى Production.

احتواء مؤقت عند تعذر التصحيح

يسجل تنبيه Upstream تعطيل HTTP/2 كتوصية بديلة. استخدم ذلك كإجراء قصير العمر فقط؛ فهو لا يزيل الكود المتأثر وقد يتجاوزه Caller لم يخضع للمراجعة.

في CLI افرض HTTP/1.1 صراحة على Workflows المتأثرة. وفي libcurl طبّق Protocol Policy في كود التطبيق واختبر أن Redirects أوConnection Reuse لا تعيد تفعيل HTTP/2. قيّد Outbound Destinations، وثبت Origins المتوقعة بسياسة Egress، وامنع المستخدم غير الموثوق من تقديم Upload URL اعتباطية.

لا تعتبر WAF أمام Inbound Application تخفيفًا؛ فالخلل يصل إليه curl client عند معالجة Control Frame من Remote Server. قد يحد Outbound Proxy من الوجهات، لكنه لا يثبت أن Client المتأثرة لا تفاوض HTTP/2 أوتصل إلى Origin مسموحة لكنها خبيثة.

الكشف ومراجعة الحوادث

طبّق Patch حتى إن كانت Logs هادئة. وللمراجعة الرجعية احتفظ بـ:

• Process Crashes وCore Dumps وAllocator Diagnostics حول HTTP/2 Uploads؛
• Outbound Destination وNegotiated Protocol وTransfer Correlation ID؛
• أسباب RST_STREAM عندما تعرضها Library أوProxy؛
• Retry Bursts وشذوذ REFUSED_STREAM أوHTTP_1_1_REQUIRED؛
• Container Restarts وKernel Events وChild Processes غير المتوقعة؛
• Image Digest وLibrary Identity المنفذة وقت الحدث.

قد يبرر Reset مطابق مع Crash رفع مستوى التحقيق، لكنه ليس تلقائيًا دليل Code Execution. اربطه مع Process Ancestry وتغييرات Files واستخدام Credentials وOutbound Connections وWorkload Identity. إذا احتُمل Memory Corruption، فاحفظ Evidence قبل Restart حيث تسمح السياسة، وأعد البناء من Artifacts موثوقة، ودوّر Credentials بحسب الأسرار التي تستطيع Process الوصول إليها.

Best practices

• تتبع curl وlibcurl كلًا على حدة داخل SBOM وRuntime Inventory.
• سجل Artifact Digests وإصدارات Libraries في Deployment Telemetry.
• عامل Outbound Upload Destinations كـSecurity Boundary.
• ضع حدودًا للتزامن وRetries وBody Size وTransfer Time.
• استهلك تنبيهات Upstream وDistribution لاVersion Strings وحدها.
• اجعل Rollback يشير إلى Artifact ثابتة ومصححة.
• احتفظ بمفتاح مختبر لتقييد HTTP Protocol Versions في الطوارئ.

Anti-patterns

• فحص أمر curl على Workstation المطور فقط.
• افتراض أن نجاح Package Update استبدل Processes طويلة العمر.
• اعتبار Reverse Proxy أوInbound WAF إصلاحًا لـlibcurl من جهة العميل.
• ادعاء الاختراق من Version Scan متأثرة.
• ادعاء الأمان لأن التنبيه لم يذكر استغلالًا عامًا.
• Rebuild من Floating Base Tag دون تسجيل Digest النهائية.
• Cherry-pick لـCommit واحدة في Branch غير مدعومة دون Regression Tests.

الخلاصة التنفيذية

تقع CVE-2026-92392 في Dependency واسعة الانتشار لكنها مخفية غالبًا. الاستجابة الصحيحة ليست ذعرًا وليست تحديث CLI فقط. اعثر على كل نسخة curl وlibcurl منفذة، وحدد إن كانت HTTP/2 Uploads تصل إلى خوادم يمكن للمهاجم التأثير فيها، وانتقل إلى 8.23.0 أوBackport مدعومة، وأعد بناء Artifacts التابعة واستبدل Fleet، واحتفظ بـTelemetry تميز Vulnerability عن Attempted Exploitation وعن Confirmed Compromise.

تابع عبر مركز Cloud وDevOps وKubernetes، ودليل تحديث Node.js في أكتوبر 2026، ودليل تحديث Apache Tomcat في أكتوبر 2026، وتقوية تشغيل Docker.

المراجع الأساسية

• مشروع curl — CVE-2026-92392: HTTP/2 upload Use-After-Free
• مشروع curl — إعلان تنبيهات curl 8.23.0 الأمنية
• مشروع curl — قائمة الثغرات المنشورة
• مشروع curl — Fixed Commit 8b0744af5b1b631da5b938ca31c
• مشروع curl — دليل Command Line
• Wikimedia Commons — Back of server
• Creative Commons Attribution-ShareAlike 4.0

إعداد: Noor Yasser