OpenWrt قامت بشحن الإصدار 24.10.8 لإغلاق تجاوز سعة مكدس DHCPv6 الحرج ومجموعة أكبر من العيوب التي يمكن تشغيلها عن بعد في خدمات الشبكة التي يتم تمكينها افتراضيًا.
القضية الحاسمة، تعقبها CVE-2026-53921 وتصنيفه 9.8 على CVSS 3.1 في استشارة GitHub الخاصة بـ OpenWrt، يتيح لمهاجم غير مصادق قادر على الوصول إلى خادم DHCPv6 الكتابة فوق المخزن المؤقت للمكدس في odhcpd من خلال طلب DHCPv6 المُعد.
يعمل odhcpd كجذر، وتشير النصائح الاستشارية إلى أن الأجهزة المضمنة تفتقر عادةً إلى خوارزميات المكدس والتوزيع العشوائي لتخطيط مساحة العنوان (ASLR)، مما يجعل تنفيذ التعليمات البرمجية نتيجة واقعية على الأجهزة النموذجية.
يتضمن الاستشارة تعليمات برمجية عامة لإثبات مفهوم Python لكلا المسارين الفائضين الموثقين. يجب على المستخدمين على الفرع 24.10 تثبيت 24.10.8، بينما يجب على المستخدمين على 25.12 تثبيت 25.12.5؛ تتوفر صور البرامج الثابتة من خلال محدد البرامج الثابتة OpenWrt.
اعتبارًا من 28 يوليو، لم تُبلغ مواد OpenWrt التي تمت مراجعتها عن الاستغلال في البرية. كان الخلل أيضًا غائبًا عن إصدار كتالوج الثغرات الأمنية المعروفة (KEV) الخاص بـ CISA رقم 2026.07.27، على الرغم من أن غياب KEV لا يثبت عدم حدوث الاستغلال.
وصل الإصدار جنبًا إلى جنب مع تدقيق منفصل بمساعدة الذكاء الاصطناعي أجراه Hacker House والذي حدد نقاط الضعف في حقن الأوامر واجتياز المسار والبرمجة النصية عبر المواقع (XSS) في مكونات LuCI الاختيارية. عثر OpenWrt على مشكلة XSS مخزنة منفصلة وحماية تزوير الطلب عبر المواقع (CSRF) مفقودة أثناء إعداد الإصلاحات.
لم تكن إصلاحات LuCI المنفصلة هذه جزءًا من OpenWrt 24.10.8 وظلت قيد المراجعة في 28 يوليو.
حزمة إلى خادم DHCP الافتراضي
يوثق الاستشارة المرتبطة بـ CVE-2026-53921 موقعين مستقلين لتجاوز السعة في مسار معالجة طلب DHCPv6. في كليهما، تترك خيارات IA المعدة مساحة غير كافية في مخزن مؤقت مكدس ثابت يبلغ 512 بايت قبل أن يقوم الكود بإلحاق بيانات رد إضافية دون التحقق من الحدود الكافية.
المشغل الأخير هو طلب DHCPv6 غير مصادق تم إرساله إلى منفذ UDP رقم 547. يقوم إثبات المفهوم للمسار الأول بإنشاء خمسة روابط IA_NA مع SOLICIT سابق؛ يتم تشغيل الثاني من خلال طلب واحد معد.
يسرد التحذير odhcpd master عند الالتزام e432dd6 وجميع الإصدارات السابقة التي تحتوي على dhcpv6_ia_handle_IAs() وbuild_ia() باعتبارها متأثرة. يسرد OpenWrt الإصدارين 24.10.8 و25.12.5 كإصدارات مدعومة تحمل التحديث الأمني odhcpd ذي الصلة.
يربط الاستشارة موقعيه الموثقين بـ CVE-2026-53921، لكن ملاحظات إصدار 24.10.8 تسرد تجاوز سعة RECONF_ACCEPT بشكل منفصل كمشكلة عالية الخطورة بدون CVE. قام OpenWrt بإصلاح عمليات الكتابة الأساسية عن طريق التحقق من سعة المخزن المؤقت للاستجابة المتبقية قبل إلحاق البيانات المتأثرة.
تقوم مجموعة OpenWrt الاستشارية بجمع كلا الموقعين الفائضين تحت CVE-2026-53921، بينما تسرد ملاحظات الإصدار RECONF_ACCEPT بشكل منفصل بدون CVE. التعيين الدقيق لا يزال غير واضح.
تصف ملاحظات إصدار OpenWrt الخلل بأنه يمكن الوصول إليه بواسطة مهاجم غير مصادق عليه ومجاور للشبكة. يستخدم ناقل CVSS 3.1 الخاص بالاستشارة AV:N (الشبكة)، وليس AV:A (المجاور)، ولا يوضح أي من المصدرين الفرق. لا يزال المهاجم بحاجة إلى الوصول إلى الشبكة لخدمة DHCPv6. يمكن أن يمنح الاستغلال الناجح للمهاجم التحكم في جهاز التوجيه بدلاً من مجرد تعطل الخدمة.
يعالج الإصدار 24.10.8 أيضًا نقاط الضعف الأخرى في المصادقة المسبقة في odhcpd، بما في ذلك الكتابة خارج الحدود، والاستخدام بعد الاستخدام المجاني، والكشف عن الذاكرة، ورفض الخدمة، والقراءة الزائدة للمكدس، وانتحال وكيل اكتشاف الجوار. تغطي إصلاحات الخدمة الافتراضية الأخرى ثلاثة أخطاء تتعلق بتهريب طلب HTTP في uhttpd وثغرة في حقن اسم مضيف DHCPv6، يتم تتبعها كـ CVE-2026-62948، والتي يمكن أن تنتج XSS مخزنًا عندما يفتح المسؤول صفحة تأجير LuCI.
يتضمن الإصدار نفسه CVE-2026-62947 في cgi-io، والذي يمكنه الكشف عن الملفات العشوائية القابلة للقراءة من خلال اجتياز المسار. تتطلب هذه المشكلة جلسة مصادق عليها مع إذن تنزيل cgi-io ومنحة قابلة للتطبيق لقراءة ملف أحرف البدل. إنه ليس عيبًا مجهولاً في قراءة الملفات.
OpenWrt 24.10 يخضع لصيانة أمنية، ومن المتوقع أن تنتهي صلاحيته في سبتمبر 2026. ويوصي المشروع بالانتقال إلى سلسلة 25.12 قبل ذلك الحين. قد تتطلب الحزم المثبتة بشكل منفصل عن صورة البرنامج الثابت أيضًا تحديثات منفصلة.
التصحيحات لا تزال قيد المراجعة
قال ماثيو هيكي، المعروف أيضًا باسم Hacker Fantastic والمدير التنفيذي للتكنولوجيا والمؤسس المشارك لشركة Hacker House، علنًا أنه تم إصدار إصلاحات لمشكلات تنفيذ التعليمات البرمجية عن بعد واجتياز المسار التي أبلغ بها OpenWrt.
نشر Hauke Mehrtens، مشرف OpenWrt، طلب سحب LuCI رقم 8878 في 26 يوليو، ونسب الفضل بشكل صريح إلى Hickey وHacker House. وجد فحص أجرته The Hacker News في 28 يوليو أن طلب السحب لا يزال مفتوحًا وغير مدمج.
 |
| مصدر الصورة: هاكر هاوس |
قالت شركة Hacker House إنها قامت بمراجعة الفروع الرئيسية لكل من LuCI وuhttpd، باستخدام التزام LuCI 3b4f44d8e3d9d5de35127b42dd449babe2d19fe5 من 27 مايو والتزام uhttpd 7b1bec45826bd78c8afc993435bdc0f1df2fe399 من 13 يونيو.
ووصفت ثلاثة مسارات للمصادقة المسبقة لتسوية الجهاز: اجتياز الدليل في luci-app-bmx7، وXSS المخزن في luci-app-olsr، وحقن الأوامر في أوامر luci-app. الأربعة المتبقية تتطلب بيانات اعتماد LuCI ويمكن استخدامها لتنفيذ الأوامر على الجهاز.
وقالت الشركة إن خمس نتائج تم التعامل معها في البداية كمسارات لتنفيذ أوامر ما بعد المصادقة، لكن اختبار OpenWrt أظهر أن حالة واحدة من أوامر luci-app يمكن أن تعمل بدون جلسة عندما يقوم المسؤول بتكوين أمر على أنه عام ومحدد. يمكن أيضًا إدخال حمولة OLSR بدون بيانات اعتماد LuCI، على الرغم من أنها لا يتم تنفيذها إلا عندما يفتح المسؤول صفحة الجيران.
لا يحدد طلب السحب الخاص بـ OpenWrt التزامًا واحدًا بكل من طلبات Hacker House السبعة. ضمن طلب السحب رقم 8878، تتوافق ستة التزامات مع تقرير Hacker House، ويعالج اثنان نقاط ضعف أمنية إضافية اكتشفها OpenWrt أثناء إعداد الإصلاحات، ويصحح واحد مشكلة اسم ملف غير أمني. يحدد طلب السحب أيضًا نتيجتين من نفس مجموعة التقارير التي تم إصلاحها بالفعل في التقرير الرئيسي، لذا لا تقوم عمليات الإرسال السبعة بتعيين واحد مقابل واحد إلى التزاماته التسعة.
لا تزال Hacker News تنتظر رد OpenWrt بشأن تعيين CVE والإصدارات المتأثرة وحالة التصحيح.
تتضمن التغييرات الأمنية في طلب السحب رقم 8878 ما يلي:
- أوامر تطبيق luci: اجتاز حرف الأنبوب المجرد القائمة المسموح بها لوسيطة التطبيق وسمح للأوامر بالعمل كجذر. وجد OpenWrt أن المسار يعمل أيضًا بدون ملف تعريف ارتباط الجلسة أو رمز CSRF المميز عندما قام المسؤول بتكوين أمر باستخدام كل من “1” العام والمعلمة “1”.
- لوسي-التطبيق-ddns: يمكن لإعداد ddns_dateformat إدخال الأوامر في عملية يتم تشغيلها بواسطة الجذر، بينما يسمح Service_name باجتياز المسار. عثر OpenWrt على مشكلة XSS مخزنة منفصلة أثناء إعداد الإصلاحات.
- لوسي بروتو openvpn: يمكن أن تصل قيم التكوين التي يتحكم فيها المهاجم إلى أوامر الصدفة من خلال نوع المفتاح، بينما تكشف معلمات الدليل الرئيسي عن ظروف اجتياز المسار.
- لوسي-التطبيق-olsr: يمكن أن تعلن عقدة شبكية ضارة عن اسم مضيف معد ينفذ برنامجًا نصيًا في المتصفح عندما يعرض المسؤول صفحة جيران OLSR.
يحتوي مسار أوامر luci-app غير المصادق عليه على شروط مسبقة مادية. يجب تثبيت التطبيق الاختياري، ويجب أن يكون المسؤول قد كشف عمدًا عن أمر ذي معلمات باعتباره أمرًا عامًا. تتطلب مسارات تنفيذ الأوامر الأخرى وصولاً موثقًا إلى LuCI وأذونات التكوين ذات الصلة. يعمل الاستغلال الناجح على تشغيل الأوامر كجذر. إنها ليست عيوبًا شاملة للمصادقة المسبقة تؤثر على كل جهاز توجيه OpenWrt.
يعالج طلب سحب نصوص ddns المنفصلة نفس إعداد ddns_dateformat غير الآمن خارج LuCI. يمكن لمشغل DDNS المفوض وضع بناء جملة shell في القيمة، مع حدوث التنفيذ عند بدء تشغيل المحدث بعد ذلك، بما في ذلك بعد إعادة التكوين أو إعادة التشغيل. وجد نفس الفحص الذي تم إجراؤه في 28 يوليو أن طلب السحب كان مفتوحًا وغير مدمج.
تم بالفعل إصلاح نتيجتين أخريين من نفس مجموعة التقارير في الفرع الرئيسي لـ LuCI: اجتياز مسار قراءة الملف غير المصادق عليه في luci-app-bmx7 وحقن الأوامر من خلال ttyd_start في luci-app-dockerman. قال OpenWrt إن كلاهما لا يزالان بحاجة إلى backports لتحرير الفروع.
قال Hacker House إن اجتياز BMX7 تم تضمينه في كشفه الصادر في 8 يوليو ووصفه بأنه مسار المصادقة المسبقة لتسوية الجهاز. يصف الاستشارة العامة لـ OpenWrt التأثير بشكل أكثر تحديدًا على أنه الوصول غير المصادق إلى الملفات التي يمكن قراءتها بواسطة عملية CGI وينسب الفضل إلى nebusecurity كمراسل. وقالت شركة Hacker House إنها لا تعرف ما إذا كانت التقارير مكررة أو سبب اختلاف الاعتماد.
الذكاء الاصطناعي في الاكتشاف ومراجعة التصحيح
وصف Hacker House تدقيق OpenWrt بأنه عملية من أربع مراحل لتشويش الاستدلال تبدأ بنموذج التهديد. تقوم الطريقة بفحص التعليمات البرمجية بشكل متكرر لإنشاء مجموعة واسعة من الثغرات الأمنية المحتملة.
ونظرًا لأن هذا المجمع يحتوي على العديد من النتائج الإيجابية الخاطئة، فإن المرحلة النهائية تستخدم نموذجًا عالي الدقة لتصفية النتائج. يقوم الباحثون بعد ذلك بتأكيد النتائج المتبقية في الكود يدويًا، وإذا كان ذلك ممكنًا، على نظام قيد التشغيل قبل الإبلاغ عنها.
قال Hacker House إن Qwen 3.6 35B Heretic يُستخدم في مرحلة الاستدلال والتشويش التي تركز على الاستدعاء. بالنسبة لفرز المرحلة الرابعة في المشاريع مفتوحة المصدر، فإنه يستخدم نموذجًا حدوديًا مثل Anthropic’s Claude Opus 4.6. يمكن استبدال Qwen 3.5 115B عندما يجب أن تتم عملية التدقيق دون الاتصال بالإنترنت بشكل كامل، مما يسمح لكود المصدر الخاص بالبقاء داخل بيئة العميل.
بعد الفرز، يقوم الباحثون بفحص الكود يدويًا، وحيثما يكون ذلك عمليًا، يؤكدون المشكلة في وقت التشغيل باستخدام اختبار أمان التطبيقات الديناميكي القياسي (DAST). وقالت Hacker House إنها تقدم فقط النتائج التي أكدت أنها ثغرات أمنية، على الرغم من أن حمولات الاستغلال قد تتطلب التعديل أثناء التحقق اليدوي.
وقالت الشركة إنها تمنح المشاريع مفتوحة المصدر من سبعة إلى 10 أيام عمل للإقرار بالتقرير ثم تعمل مع المشرفين على الجدول الزمني للإصلاح المفضل لديهم. إذا لم يصل أي إقرار، فقد ينشر تفاصيل محدودة لتشجيع المشروع على الاستجابة أو معالجة النتائج.
استخدم OpenWrt الذكاء الاصطناعي أثناء أجزاء من عملية المعالجة أيضًا. تحمل العديد من الالتزامات المقترحة مقطعًا دعائيًا بمساعدة: Claude: claude-opus-5، وتشير المراجعة الآلية لطلب سحب LuCI إلى أنه تم إنشاؤه باستخدام Claude Code. وبالتالي ساهمت النماذج في اكتشاف المرشحين وفرزهم ومراجعة التصحيح، بينما قام الباحثون والمشرفون بالتحقق يدويًا من النتائج والإصلاحات.
بالنسبة للإصلاحات التي تم شحنها، يجب على المستخدمين تثبيت OpenWrt 24.10.8 أو 25.12.5 وتحديث الحزم المثبتة بشكل منفصل. يجب على المسؤولين أيضًا مراجعة أذونات LuCI المفوضة، وإزالة التطبيقات الاختيارية التي لا يستخدمونها، والتحقق مما إذا كانت أي أوامر في أوامر luci-app عامة وذات معلمات.
اعتبارًا من 28 يوليو، لم يتضمن طلبا السحب قائمة CVEs، أو نتائج CVSS، أو نطاقات الإصدار المتأثرة الكاملة، أو إصدارات الحزمة الثابتة الثابتة. ولم يتم الإبلاغ عن أي استغلال في البرية.
