ثغرة PixelSmash في FFmpeg: تهديد أمني يطال ملايين خوادم الميديا حول العالم

أبرز النقاط

• ثغرة PixelSmash تحمل تصنيف خطورة 8.8 وتؤثر في مئات التطبيقات المعتمدة على مكتبة libavcodec
• الاستغلال يتم عبر ملفات فيديو بصيغ AVI أو MKV أو MOV دون تفاعل المستخدم أحياناً
• FFmpeg أصدرت الإصدار 8.1.2 لمعالجة الثغرة، وعلى المؤسسات التحديث فوراً

كشف باحثون في شركة JFrog المتخصصة في أمن سلاسل التوريد البرمجية عن ثغرة خطيرة في مكتبة FFmpeg أُطلق عليها اسم PixelSmash، تتيح للمهاجمين تنفيذ أكواد خبيثة عن بُعد على خوادم الوسائط المتعددة مثل Jellyfin، كما يمكنها إحداث حالة توقف عن العمل (DoS) في تطبيقات شائعة الاستخدام كـ Kodi وEmby وNextcloud وOBS Studio. الثغرة مُسجَّلة بالرقم CVE-2026-8461 وحصلت على درجة خطورة 8.8 من 10، ما يضعها في خانة التهديدات العالية التي تستوجب استجابة فورية.

ما الجذر التقني لثغرة PixelSmash؟

تكمن المشكلة في وحدة فك ترميز MagicYUV ضمن مكتبة libavcodec، وهي المكتبة الأساسية في FFmpeg لمعالجة الفيديو. وبحسب تحليل JFrog، تنشأ الثغرة من تناقض في طريقة حساب ارتفاعات مستويات الألوان (chroma planes) بين مُخصِّص الإطارات ووحدة فك الترميز، مما يؤدي إلى كتابة بيانات خارج حدود الذاكرة المُخصَّصة (heap out-of-bounds write) بمقدار صف واحد.

يُعالج MagicYUV إطارات الفيديو عبر تقسيمها إلى شرائح (slices) مستقلة يمكن فك ترميزها بشكل منفصل. هذا التصميم الذي يهدف لتحسين الأداء يصبح نقطة ضعف حين يختلف حساب الأبعاد بين مكوّنين في المكتبة ذاتها.

كيف يمكن استغلال الثغرة في الواقع؟

يمكن تفعيل ثغرة PixelSmash بعدة طرق: حين يفتح المستخدم ملف فيديو بصيغة AVI أو MKV أو MOV، أو حين يتصفح مجلداً يحتوي على الملف الخبيث (بسبب توليد الصور المصغّرة تلقائياً)، أو عبر أي سير عمل آلي لاستيعاب الوسائط.

• Kodi: مشغّل الوسائط مفتوح المصدر الأكثر انتشاراً
• OBS Studio: المعيار الفعلي للبث المباشر وتسجيل الشاشة
• PhotoPrism: منصة إدارة الصور ذاتية الاستضافة
• مولّدات الصور المصغّرة في بيئات GNOME وKDE وXFCE
• Jellyfin وEmby: خوادم وسائط ذاتية الاستضافة

كما أشار الباحثون إلى أن تطبيقات المراسلة مثل Slack وDiscord وTelegram وWhatsApp قد تكون عرضة للخطر لأنها تستخدم FFmpeg لتوليد معاينات الفيديو على الخوادم، لكنها لم تُختبر فعلياً.

تنفيذ أكواد خبيثة على Jellyfin: سيناريو الهجوم الكامل

أثبت الباحث الرئيسي في JFrog، يوفال مورافتشيك، إمكانية تنفيذ أكواد عن بُعد على خادم Jellyfin الإصدار 10.11.9، وهو ثاني أكثر خوادم الوسائط ذاتية الاستضافة شيوعاً بعد Plex. مسار الهجوم يسير كالتالي: يُحمَّل ملف AVI خبيث مُصمَّم بعناية إلى مكتبة الوسائط، فيُفعِّل Jellyfin تلقائياً أداة ffprobe لاستخراج البيانات الوصفية، مما يُطلق الكتابة خارج الحدود، ويُختطَف استدعاء AVBuffer.free ليُوجَّه إلى دالة system()، فتُنفَّذ أوامر المهاجم بصلاحيات حساب خدمة jellyfin.

يوجد سيناريو أخطر لا يتطلب أي تفاعل من المستخدم: يمكن للمهاجم زرع ملف فيديو خبيث كـ torrent، وحين يُحمِّله مستخدم Jellyfin إلى مجلد مكتبة الوسائط مباشرة، يرصد مراقب نظام الملفات في Jellyfin الملف الجديد ويُطلق فحص البيانات الوصفية تلقائياً، فيُنفَّذ الاستغلال دون أي نقرة.

ما الشروط اللازمة لنجاح الهجوم؟

أوضح مورافتشيك أن تنفيذ الأكواد عن بُعد يتطلب تعطيل حماية ASLR (التوزيع العشوائي لتخطيط مساحة العناوين)، وأن الثغرة CVE-2026-8461 وحدها لا تتجاوز هذه الحماية. نظرياً، يمكن ربط ثغرة كشف معلومات منفصلة في وحدة فك ترميز FlashSV مع PixelSmash لتجاوز ASLR.

حتى حين يكون تنفيذ الأكواد مستحيلاً، تبقى الثغرة كافية لإحداث حالة توقف عن العمل (DoS) على الأنظمة المستهدفة، مما يجعلها تهديداً جدياً في كل الأحوال.

لماذا نجا Plex من الثغرة؟

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

ما الإجراءات المتخذة والتحديثات المتاحة؟

اكتشفت JFrog الثغرة وأبلغت فريق أمان FFmpeg في 13 مايو 2026. عالج المطوّرون المشكلة في الإصدار 8.1.2 الذي صدر في 17 يونيو. كما حدّث Jellyfin نسخة FFmpeg المُضمَّنة، بينما يعمل فريق PhotoPrism على إضافة قائمة حظر لصيغ الملفات لمنع الاستغلال المحتمل.

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

البُعد الأخطر: مشكلة سلسلة التوريد

حذّر باحثو JFrog من أن PixelSmash تمتلك سطح هجوم ضخماً لأن وحدة MagicYUV موجودة في مئات المشاريع التي تثق في FFmpeg لمعالجة المدخلات غير الموثوقة بأمان. هذا يُحوِّل الثغرة من مشكلة تقنية محدودة إلى تهديد على مستوى سلسلة التوريد البرمجية بأكملها.

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

خطوات الحماية الفورية

• ترقية FFmpeg إلى الإصدار 8.1.2 أو أحدث على جميع الأنظمة
• تحديث Jellyfin وأي تطبيقات وسائط أخرى تستخدم FFmpeg مُضمَّناً
• مراجعة إعدادات ASLR والتأكد من تفعيلها على الخوادم
• تقييد صلاحيات حسابات الخدمة التي تُشغِّل تطبيقات الوسائط
• تطبيق قوائم سماح لصيغ الملفات المقبولة حيثما أمكن

الأسئلة الشائعة

هل خادم Plex الخاص بي معرّض لثغرة PixelSmash؟

لا، Plex يستخدم نسخة مُخصَّصة من FFmpeg عطّلت فيها وحدات فك الترميز غير الضرورية بما فيها MagicYUV، مما يحميه من هذه الثغرة تحديداً.

هل يمكن استغلال الثغرة عبر واتساب أو تيليغرام؟

نظرياً نعم لأنها تستخدم FFmpeg لمعاينات الفيديو، لكن الباحثين لم يختبروها فعلياً ولم يؤكدوا قابلية الاستغلال.

ما الفرق بين تنفيذ الأكواد عن بُعد وهجوم الحرمان من الخدمة في هذه الثغرة؟

تنفيذ الأكواد يتطلب تعطيل حماية ASLR أو ربط ثغرة إضافية، بينما هجوم الحرمان من الخدمة (DoS) ممكن في كل الحالات ويُوقف التطبيق عن العمل.

لماذا رفض Nextcloud معالجة الثغرة؟

لأن الثغرة تقع في مكتبة FFmpeg الخارجية وليس في كود Nextcloud ذاته، لكن هذا لا يعني أن مستخدمي Nextcloud في مأمن.

متى اكتُشفت الثغرة ومتى صدر التصحيح؟

اكتشفتها JFrog وأبلغت FFmpeg في 13 مايو 2026، وصدر التصحيح في الإصدار 8.1.2 بتاريخ 17 يونيو 2026.