CVE-2026-38361: ثغرات متعددة لحجب الخدمة (DoS) دون مصادقة في dash-uploader

ثغرات متعددة لحجب الخدمة (Denial of Service - DoS) دون مصادقة في fohrloop/dash-uploader (Python، PyPI)، بما في ذلك (على سبيل المثال لا الحصر) انهيار العملية بسبب نفاد الذاكرة (OOM)، واقتطاع الملفات إلى صفر بايت، واستنزاف القرص بشكل دائم، والالتفاف الكامل على حد max_file_size الموثق. توجد مسارات إضافية لإساءة استخدام الموارد عبر نفس مجموعة المعاملات غير المعقّمة.

⚠️ لا يتوفر تصحيح، ولن يُصدر أي تصحيح على الإطلاق

تمت أرشفة المستودع في 2025-07-19 دون وجود مشرف نشط. جميع الإصدارات المنشورة (من 0.1.0 حتى 0.7.0a2) متأثرة وستظل كذلك. لا تزال الحزمة تحقق ما يقارب 28,000 تحميل شهريًا.

يجب على أي شخص يشغّل dash-uploader في بيئة الإنتاج تطبيق إجراء تخفيف بنفسه. الإصلاح الموصى به هو الانتقال إلى مكوّن dcc.Upload المدمج في Plotly Dash. راجع التخفيف للاطلاع على الخيارات الكاملة.

الوصف

يستقبل معالج HTTP الخاص بـ dash-uploader طلبات POST غير مصادق عليها تحتوي على معاملات يتحكم فيها المهاجم وتتدفق إلى تخصيص الذاكرة وعمليات الملفات وإنشاء الدلائل دون أي فحوصات للحدود أو حدود لمعدل الطلبات أو آلية تنظيف. توجد أربع مشكلات مستقلة في نفس مسار الكود:

1. انهيار OOM (مُتحقَّق منه)

تم التحقق على نظام بسعة 7.7 جيجابايت: 5 طلبات POST متزامنة مع resumableTotalChunks=30000000 أدت إلى تفعيل مُنهي OOM في Linux خلال ثانيتين. يؤكد سجل النواة:

Out of memory: Killed process 24203 (python3) total-vm:8302276kB, anon-rss:7068012kB

يخصص كل طلب ما يقارب 2.9 جيجابايت عبر فهم القائمة (list comprehension) على range(1, resumableTotalChunks + 1). يتم إنهاء عملية الخادم ويصبح التطبيق غير متاح تمامًا حتى إعادة التشغيل اليدوية.

2. اقتطاع الملف (مُتحقَّق منه)

تم تقليص ملف يحتوي على 42 بايت من البيانات إلى 0 بايت عبر طلب POST واحد مع resumableTotalChunks=0. السبب الجذري هو أن دالة all() في Python تُرجع True للمتكرّرات الفارغة، مما يخدع معالج الرفع لاعتبار صفر شظايا عملية رفع مكتملة. يتم حذف الملف الموجود عبر os.unlink() واستبداله بملف فارغ.

3. تراكم عمليات الرفع المتروكة (مُتحقَّق منه)

تم إنشاء 10 دلائل مؤقتة يتيمة تحتوي على ملفات شظايا وبقيت مخزنة على القرص إلى أجل غير مسمى. بحث شامل في جميع ملفات المصدر عبر قاعدة الكود عن cleanup وttl وexpire وgarbage وpurge وcron وschedule وperiodic لم يُرجع أي نتائج. استدعاء التنظيف الوحيد (shutil.rmtree) يتم تنفيذه حصريًا على عمليات الرفع المكتملة. لا توجد أي آلية لاستعادة مساحة القرص من الجلسات غير المكتملة.

4. الالتفاف على max_file_size (مُتحقَّق منه)

قبل الخادم شظية بحجم 5 ميجابايت لملف يدّعي resumableTotalSize=999999999999 (~999 جيجابايت) مع استجابة HTTP 200. يتم تمرير معامل max_file_size فقط إلى مكوّن React JavaScript. لا يقوم الخادم أبدًا بفحص حجم الملف أو حجم الشظية أو Content-Length أو MAX_CONTENT_LENGTH الخاص بـ Flask. المطوّر الذي يضبط max_file_size=10 لا يحصل على أي حماية من جانب الخادم.

الكود المعرض للثغرة

# dash_uploader/httprequesthandler.py
def _post(self):
    resumableTotalChunks = request.form.get("resumableTotalChunks", type=int)   # attacker-controlled, no bounds
    ...
    chunk_paths = [
        os.path.join(temp_dir, get_chunk_name(resumableFilename, x))
        for x in range(1, resumableTotalChunks + 1)                              # unbounded; e.g. 30M -> ~2.9 GB -> OOM
    ]
    upload_complete = all([os.path.exists(p) for p in chunk_paths])              # all([]) is True -> truncation when chunks=0
    if upload_complete:
        target_file_name = os.path.join(temp_root, resumableFilename)
        if os.path.exists(target_file_name):
            os.unlink(target_file_name)                                          # existing file deleted
        with open(target_file_name, "ab") as target_file:
            for p in chunk_paths:                                                # empty list -> empty file written
                ...

ينتج مسار الكود نفسه كلًا من انهيار OOM (قيمة resumableTotalChunks كبيرة) وأولية اقتطاع الملف (resumableTotalChunks=0).

ناقلات الهجوم

يرسل المهاجم طلبات POST غير مصادق عليها إلى نقطة النهاية /API/resumable.

• انهيار OOM: 5 طلبات متزامنة مع resumableTotalChunks=30000000 تخصص ~2.9 جيجابايت لكل طلب، مما يؤدي إلى تفعيل مُنهي OOM.
• استنزاف القرص: بدء عمليات رفع دون إكمالها أبدًا؛ تتراكم الملفات المؤقتة اليتيمة إلى الأبد.
• اقتطاع الملف: إرسال resumableTotalChunks=0؛ تخدع all([])=True في Python الخادم لاستبدال الملف الهدف بمحتوى فارغ.
• الالتفاف على الحجم: أي حد للحجم يضبطه المطوّر يُفرض فقط في JavaScript الخاص بالعميل، لذا فإن طلب HTTP مباشر يلتف حوله تمامًا.

لا تتطلب أي مصادقة أو صلاحيات.

التأثير

• انهيار عملية الخادم عبر مُنهي OOM في Linux الناتج عن تخصيص ذاكرة غير محدود من معامل POST واحد يتحكم فيه المستخدم (resumableTotalChunks)
• استنزاف القرص الدائم عبر جلسات الرفع المتروكة التي لا يتم تنظيفها أبدًا (لا يوجد TTL ولا جمع قمامة ولا آلية انتهاء صلاحية في قاعدة الكود)
• استنزاف inodes نظام الملفات عبر إنشاء دلائل بعمق تعسفي من خلال os.makedirs() مع resumableIdentifier غير معقّم
• تدمير البيانات عبر اقتطاع الملف إلى صفر بايت الناتج عن إرجاع all() في Python القيمة True للمتكرّرات الفارغة عندما يكون resumableTotalChunks=0
• الالتفاف على جميع قيود حجم الملف لأن max_file_size يُطبَّق فقط في JavaScript من جانب العميل بينما لا يقوم المعالج من جانب الخادم بأي تحقق من الحجم ولا يضبط أبدًا MAX_CONTENT_LENGTH الخاص بـ Flask

المكونات المتأثرة

• dash_uploader/httprequesthandler.py (طريقة BaseHttpRequestHandler._post)
• dash_uploader/upload.py (دالة Upload، معامل max_file_size)
• dash_uploader/configure_upload.py (غياب MAX_CONTENT_LENGTH)

التخفيف

⚠️ لا يتوفر تصحيح، والمشروع مؤرشَف

الخيارات المتاحة للمستخدمين الذين لديهم نشر قائم حاليًا، حسب الأولوية:

1. الانتقال إلى dcc.Upload، مكوّن الرفع الرسمي المرفق مع Plotly Dash. لا يحتوي على معامل لعدد الشظايا، ولا حالة مؤقتة على القرص، ويلتزم بـ MAX_CONTENT_LENGTH الخاص بـ Flask. لا تنطبق أي من المشكلات الأربع هنا. الأنسب للملفات الصغيرة والمتوسطة. بالنسبة لعمليات الرفع الكبيرة جدًا، راجع البند 2.
2. إعداد معالج رفع صغير بـ Flask مع فرض صريح للحجم لكل طلب (MAX_CONTENT_LENGTH)، وحدود على أي عدد شظايا يقدمه العميل، وقائمة مسموح بها لأسماء الملفات المقبولة.
3. إذا استمريت في استخدام dash-uploader، اضبط MAX_CONTENT_LENGTH الخاص بـ Flask على مستوى التطبيق (المكتبة لا تفعل ذلك)، وارفض المدخلات على طبقة التطبيق أو الوكيل العكسي عند تحقق أي مما يلي:
   • resumableTotalChunks <= 0
   • تجاوز resumableTotalChunks لحد معقول (مثل 10,000)
   • تجاوز resumableTotalSize لقيمة max_file_size التي ضبطها المطوّر
4. أضف حدًا لمعدل الطلبات على نقطة نهاية الرفع في طبقة الوكيل العكسي أو جدار الحماية للتطبيقات (WAF) للتخفيف من ناقل OOM الناتج عن الطلبات المتزامنة.
5. نظّف الدلائل المؤقتة اليتيمة دوريًا عبر مهمة cron خارجية، نظرًا لعدم وجود تنظيف داخلي في المكتبة.

الجدول الزمني للإفصاح

سياق الحزمة

• ما يقارب 28,000 تحميل شهري على PyPI (27,756 في الأيام الثلاثين السابقة لـ 2026-05-07، مع حجم يومي مستمر على الرغم من أرشفة المستودع). المصدر: pypistats.org.
• أحدث إصدار منشور: 0.6.1 (خط الإصدار المستقر). تمتد الإصدارات الأولية إلى 0.7.0a2.
• الاعتمادية المطلوبة: dash. الاعتمادية الاختيارية: pyyaml. الترخيص: MIT.
• 11 حزمة تابعة و6 مستودعات تابعة.
• 153 نجمة على GitHub.
• تمت أرشفة المستودع في 2025-07-19 (Issue #153).
• لا توجد CVEs سابقة (تم التحقق من ذلك مقابل NVD وGitHub Advisory Database وSnyk وOSV في 2026-03-19).

المراجع

• https://www.cve.org/CVERecord?id=CVE-2026-38361
• https://nvd.nist.gov/vuln/detail/CVE-2026-38361
• https://github.com/fohrloop/dash-uploader
• https://github.com/fohrloop/dash-uploader/blob/stable/dash_uploader/httprequesthandler.py
• https://github.com/fohrloop/dash-uploader/issues/153
• https://pypi.org/project/dash-uploader/
• https://pypistats.org/packages/dash-uploader
• https://libraries.io/pypi/dash-uploader
• https://pepy.tech/project/dash-uploader
• https://cwe.mitre.org/data/definitions/400.html
• https://cwe.mitre.org/data/definitions/670.html
• https://docs.python.org/3/library/functions.html#all

المكتشف

Muhammad Fitri Bin Mohd Sultan