romain-deperne/cve-2026-27825ثغرة اجتياز المسار في mcp-atlassian عبر استخراج ملفات zip في upload_attachment — درجة CVSS 9.3
الخطورة: حرجة (CVSS 9.3)
CWE: CWE-22 — اجتياز المسار
المتأثر: sooperset/mcp-atlassian >= 0.17.0 (التوأم المتماثل لجهة القراءة لـ GHSA-xjgw-4wvw-rgm4)
الإشعار الأمني: GHSA
NVD: https://nvd.nist.gov/vuln/detail/CVE-2026-27825
أداة MCP confluence_upload_attachment تمرر وسيط file_path مباشرة إلى open(file_path, "rb") دون أي تحقق من المسار. يمكن للمهاجم الذي يستطيع استدعاء الأداة قراءة ملفات عشوائية من نظام ملفات الخادم وتسريبها عبر رفع متعدد الأجزاء إلى نقطة نهاية Confluence يتحكم بها المهاجم. النقل الافتراضي streamable-http يربط 0.0.0.0 دون مصادقة، مما يجعل هذا قابلاً للاستغلال عن بُعد دون بيانات اعتماد.
هذا هو التوأم المتماثل لجهة القراءة للإشعار الأمني المُعالج سابقًا GHSA-xjgw-4wvw-rgm4 — إصلاح الإصدار v0.17.0 غطى مسار الكتابة/التنزيل فقط. مسار الرفع تُرك دون حماية.
كان mcp-atlassian قد تلقى بالفعل إصلاحًا لاجتياز المسار في الإصدار v0.17.0 (GHSA-xjgw-4wvw-rgm4)، والذي عالج مسار الكتابة — تنزيل المرفقات إلى القرص المحلي. فرضيتي: عندما يُطبَّق إصلاح على اتجاه واحد من عملية متماثلة، غالبًا ما يُغفل الاتجاه الآخر.
فتحت attachments.py وبحثت عن جميع استدعاءات open(. مسار التنزيل (السطر 223، 272) كان يحتوي على validate_safe_path(local_path) المُضاف قبل open(). مسار الرفع (السطر 477) لم يكن يحتوي على أي شيء. نفس الملف، نفس النمط، معالجة غير متسقة — إصلاح غير مكتمل بامتياز.
تعريف الأداة أكد ذلك: file_path: Annotated[str, Field(description="Absolute path to the file to upload")] دون قيد pattern=، دون مُتحقق، دون أي شيء. الحقل موثق حرفيًا على أنه يقبل مسارًا مطلقًا دون أي تقييد.
أعدت إنتاج المشكلة من البداية إلى النهاية: شغّلت عملية خادم mcp-atlassian الحقيقية، وقُدتها بعميل MCP stdio (mcp.ClientSession)، ووجهتها إلى نموذج محلي لخادم Confluence HTTP وهمي، واستدعيت confluence_upload_attachment مع file_path=/etc/passwd. سجّل الخادم الوهمي محتوى /etc/passwd الكامل في جسم الطلب متعدد الأجزاء. تشغيلان كاملان لإعادة الإنتاج، كلاهما مسجل في ملفات PoC.
الربط الافتراضي HOST=0.0.0.0 دون مصادقة يجعل هذا قابلاً للاستغلال عن بُعد دون بيانات اعتماد في النشر الافتراضي.
الملف: src/mcp_atlassian/confluence/attachments.py، السطر 477
with open(file_path, "rb") as fp: # ← file_path يتحكم به المهاجم
files = {"file": (filename, fp, content_type)}
response = self.confluence.session.post(url, files=files, ...)
تعريف الأداة (src/mcp_atlassian/servers/confluence.py:1307):
file_path: Annotated[str, Field(description="Absolute path to the file to upload")]
# لا pattern=، لا مُتحقق، لا validate_safe_path()
عدم التماثل مع مسار التنزيل المُعالج:
# attachments.py:223 — مُعالَج (مسار التنزيل)
validate_safe_path(local_path) # ← الحماية أُضيفت في v0.17.0
open(local_path, "wb")
# attachments.py:477 — ثغرة (مسار الرفع)
open(file_path, "rb") # ← لا حماية، أُغفل في v0.17.0
إصلاح v0.17.0 لـ GHSA-xjgw-4wvw-rgm4 أضاف استدعاءات validate_safe_path() على جهة الكتابة (تنزيل المرفقات إلى القرص المحلي) لكنه لم يدقق جهة القراءة (رفع الملفات المحلية إلى Confluence). مُزيّن check_write_access غير مرتبط — فهو يقيّد READ_ONLY_MODE فقط.
التعرض الشبكي الافتراضي (src/mcp_atlassian/__init__.py:151):
HOST = "0.0.0.0" # يربط جميع الواجهات
# لا طبقة مصادقة في نقل streamable-http
أُعيد إنتاج المشكلة بالكامل من البداية إلى النهاية ضد نموذج HTTP محلي يحاكي واجهة برمجة تطبيقات Confluence. انظر mcp_client.py، وmock_confluence.py، وpoc_run1.sh.
# poc_run1.sh — يقرأ /etc/passwd عبر confluence_upload_attachment
# 1. تشغيل نقطة نهاية Confluence الوهمية
python mock_confluence.py &
# 2. استدعاء أداة MCP مع حمولة اجتياز المسار
python mcp_client.py \
--tool confluence_upload_attachment \
--page-id 123456 \
--file-path /etc/passwd \
--filename passwd.txt
# → يظهر محتوى /etc/passwd في سجل mock_confluence.py
/etc/passwd، مفاتيح SSH، .env، أسرار التطبيق)streamable-http يربط 0.0.0.0، دون مصادقة؛ أي مهاجم يمكنه الوصول عبر الشبكة يمكنه استدعاء أدوات MCP مباشرة