استشارة Nuxt Image: هجمات غير مصادق عليها عبر مسار /_ipx الافتراضي

@nuxt/image يسجل مسار تحويل الصور /_ipx افتراضياً على نشرات الخادم ويقدمه عبر ipx. تقول استشارة GitHub إن ipx يحتوي على تجاوز عدد صحيح (GHSA-qf89-6xm4-66wm) عند فك ترميز الصور متعددة الصفحات، لذا يمكن لصورة مصدر مُعدّة خصيصاً أن تُفسد الذاكرة أثناء الفك. قد يستخدم مهاجم يتحكم في صورة مصدر طلباً واحداً غير مصادق عليه لتعطيل عملية الخادم، وقد يسمح فساد الذاكرة بتنفيذ تعليمات برمجية عن بُعد بامتيازات تلك العملية.

النشرات والنسخ المتأثرة

تؤثر المشكلة على النشرات التي يعمل فيها الموقع كخادم مع موفر ipx الافتراضي، لذا يُسجّل /_ipx بدون إعداد؛ ويمكن أن تصبح بايتات الصورة التي يتحكم بها المهاجم مصدراً لـ IPX؛ و/_ipx متاح بدون مصادقة، وهو الوضع الافتراضي. لا حاجة إلى أي معدّل خاص، وطلب واحد يكفي. النسخ المتأثرة من @nuxt/image هي >= 2.0.0 و < 2.2.1، و >= 1.0.0 و < 1.11.2، و >= 0.6.0 و < 1.0.0. النشرات التي تستخدم موفر صور على مستوى منصة غير متأثرة طالما لم يُضبط image.ipx أيضاً؛ ولا تسجل بيئة وقت تشغيل الحافة أو العامل، مثل Cloudflare Workers، المسار، ولا تسجل البناءات الثابتة أيضاً. في إعادة الإنتاج المبلّغ عنها، عملت عملية الخادم كـ root داخل حاوية قياسية، مما وضع الأسرار وشفرة المصدر والبيانات المرفوعة في الحاوية في متناول المهاجم.

الإصدارات المصححة

تم الإصلاح في @nuxt/image 2.2.1 و 1.11.2، اللتين تتطلبان إصدارات ipx المصححة 4.1.0 و 2.1.2 على التوالي. قبل فك ترميز جميع صفحات صورة متعددة الصفحات، مثل TIFF أو GIF أو WebP أو AVIF، تتحقق تلك الإصدارات من إجمالي ارتفاع الصورة وترفض الطلب برمز 400 إذا كان كبيراً جداً. كما يحد الإصدار 2.2.1 مسار /_ipx افتراضياً إلى تنسيقات صور الويب الشائعة: يُرفض برمز 403 قبل فك ترميزه كل مصدر لا يكون تنسيقه المكتشف JPEG أو PNG أو WebP أو GIF أو SVG أو AVIF أو HEIC. لقبول تنسيقات أخرى، اضبط image.ipx.allowedInputFormats. إذا لم تكن المصادر موثوقة بالكامل، توصي الاستشارة أيضاً بتمكين image.ipx.restrictDecoders، الذي يمنع مفككات كل تنسيق آخر؛ وهو ينطبق على كل استخدام لـ sharp في عملية الخادم. هذان الخياران غير متوفرين في 1.x. وصل Nuxt Image 0.x إلى نهاية الدعم ولن يتلقى إصلاحاً. ipx تبعية اختيارية، لذا بعد الترقية تحقق من أن ipx تُحلّ إلى إصدار مصحّح، مثلاً بالأمر npm ls ipx، وقم بترقيتها مباشرة إذا كان المشروع يعتمد عليها أيضاً.

الحلول المؤقتة والشدّة

إذا لم تتمكن من الترقية بعد، سجّل معالج خادم خاص بك على مسار /_ipx، مثلاً معالجاً يعيد 404؛ تكتشف الوحدة وجود معالج ولا تُثبّت معالجها. يمكنك أيضاً حظر /_ipx/** في الخادم العكسي إذا لم تكن بحاجة إلى المسار. تأكد من أن البايتات التي يتحكم بها المهاجم لا يمكن أن تصبح مصدراً لـ IPX: احتفظ بالمرفوعات خارج المسارات العامة المقدمة، وقيّد image.domains إلى المضيفات التي تتحكم بها. فحص امتداد الملف أو Content-Type للمرفوعات لا يكفي، لأن المفكك يُختار من محتويات الملف. ولا يفيد تقييد المعدّلات عبر allowedModifiers، لأن المشكلة يمكن الوصول إليها دون أي معدّل. درجة خطورة الاستشارة عالية، والنتيجة الإجمالية لنظام CVSS هي 8.1. تسرد مقاييس CVSS v3 الأساسية متجه هجوم عبر الشبكة، وتعقيد هجوم مرتفع، ودون امتيازات مطلوبة، ودون تفاعل من المستخدم، ونطاقاً غير متغيّر، وتأثيراً مرتفعاً على السرية والسلامة والتوافر. لا يوجد CVE معروف. الضعف هو CWE-20، التحقق غير السليم من المدخلات. الفضل يعود إلى @l8BL على التقرير المفصّل وإعادة الإنتاج والإفصاح المنسّق. نُشرت الاستشارة في 30 أكتوبر 2026 تحت GHSA-p5vf-pjf5-ggj3.

المصادر: استشارة GitHub · استشارة IPX · Cloudflare · GitHub