CVE-2026-67598

Emlog Pro — تعطيل التحقق من شهادة TLS في المساعد الذكي

هجوم MITM قريب من الشبكة → سرقة مفتاح API الخاص بمزوّد نماذج اللغة الكبيرة (LLM) وحقن استجابات الذكاء الاصطناعي

الملخص · مسار الهجوم · الكود المتأثر · الإثبات · المعالجة · الخط الزمني · المراجع

📋 نظرة سريعة

🔎 الملخص

يأتي Emlog Pro مزوّدًا بمساعد ذكاء اصطناعي موجّه للمشرف (admin/ai.php + include/service/ai.php) يُجري طلبات HTTPS صادرة إلى مزوّد نماذج لغوية كبيرة (LLM) مُهيأ — للمحادثة والبث وتوليد الصور — بالإضافة إلى أداة مساعدة تستخرج نتائج Bing لأمر @em-help.

كل أداة من أدوات الطلبات الصادرة تعطّل التحقق من شهادة TLS بشكل غير مشروط:

curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);

التحقق يكون مُعطّلًا بغض النظر عن عنوان المزوّد المُهيأ أو مسار الشبكة، لذا يمكن لأي مهاجم قريب من الشبكة / رجل في المنتصف (MITM) يقع بين خادم Emlog وapi_url اعتراض جلسة TLS بشفافية باستخدام شهادة مزوّرة، ومن ثم:

• 🔑 سرقة ترويسة Authorization: Bearer <apiKey> — مفتاح API المدفوع لمزوّد نماذج اللغة الكبيرة الخاص بالموقع.
• 💉 حقن استجابة ذكاء اصطناعي خبيثة مرة أخرى في المساعد، الذي يوجّه نموذجًا لغويًا كبيرًا يمتلك صلاحيات أدوات query_database وupdate_config.

هذا خلل نقي في أمان طبقة النقل — وهو ليس خاضعًا لواجهة تأكيد استدعاء أدوات الذكاء الاصطناعي.

🧭 مسار الهجوم

flowchart LR
    A["🖥️ Emlog server<br/>AI assistant"] -->|"HTTPS request<br/>Bearer &lt;apiKey&gt;"| M{"😈 MITM attacker<br/>(forged cert)"}
    M -->|"TLS verify DISABLED<br/>→ accepted"| P["☁️ LLM provider"]
    M -.->|"🔑 reads API key"| X["Key exfiltrated"]
    M -.->|"💉 forged response"| A
    A -->|"acts on injected<br/>AI output"| T["⚙️ query_database /<br/>update_config tools"]

    classDef bad fill:#7f1d1d,stroke:#ef4444,color:#fff;
    classDef ok  fill:#1e3a8a,stroke:#3b82f6,color:#fff;
    class M,X bad;
    class A,P,T ok;

💥 التأثير

• كشف مفتاح API — سرقة مفتاح مزوّد نماذج اللغة الكبيرة المدفوع الخاص بالموقع وإساءة استخدامه ماليًا.
• حقن الاستجابات — دخول محتوى يتحكم به المهاجم إلى بث المساعد الذكي.
• عتبة استغلال منخفضة — أي موقع قريب من الشبكة (استضافة مشتركة، شبكة Wi-Fi معادية، راوتر مخترق، وكيل خروج خبيث) يكفي؛ ولا تتطلب أي بيانات اعتماد على تثبيت Emlog.

📂 الكود المتأثر

include/service/ai.php — استدعاءات CURLOPT_SSL_VERIFYPEER / CURLOPT_SSL_VERIFYHOST في:

🧪 الإثبات / التحقق

# 1. Configure the AI assistant with any OpenAI-compatible provider URL + API key.
# 2. Put a MITM proxy with an UNTRUSTED CA between Emlog and the provider:
mitmproxy --mode reverse:https://api.provider.example -p 8443

# 3. Trigger any AI chat / image-gen / @em-help request from the admin panel.
# 4. Result: request succeeds despite the untrusted cert, and the
#    "Authorization: Bearer ..." header is readable in the proxy log
#    → certificate validation is confirmed disabled.

🛠️ المعالجة

فعّل التحقق من TLS لجميع الطلبات الصادرة في include/service/ai.php:

- curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
- curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
+ curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, true);
+ curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 2);

يجب دعم نقاط النهاية المستضافة ذاتيًا / المتوافقة مع OpenAI والتي تستخدم مرجع مصادقة (CA) خاصًا عبر حزمة مرجع مصادقة مخصصة (CURLOPT_CAINFO) — أبدًا عن طريق تعطيل التحقق عالميًا.

🔗 ملاحظة ذات صلة (نفس الميزة، تحصين منفصل)

أثناء تدقيق نفس ميزة الذكاء الاصطناعي، تبيّن أن Ai::queryDatabase() تحظر بشكل خاص عمليات الكتابة المباشرة في SQL إلى جدول blog لكن ليس جدول user (الذي يحتوي على role / password). وبدمج ذلك مع مسار حقن التعليمات غير المباشر عبر @em-help (نتائج Bing المباشرة + أسئلة شائعة مستخرجة تُغذَّى إلى نموذج يمتلك صلاحيات أدوات query_database / update_config)، يستحق هذا الأمر تحصينًا بتوجيه عمليات الكتابة إلى user / options عبر أدوات ضيقة النطاق — تمامًا بالطريقة التي يتعامل بها write_article مع منشورات المدونة. التفاصيل الكاملة في REPORT.md (مُتتبَّع بشكل منفصل عن CVE أعلاه).

🗓️ الخط الزمني

📚 المراجع

• 🆔 سجل CVE — https://www.cve.org/CVERecord?id=CVE-2026-67598
• 🛡️ NVD — https://nvd.nist.gov/vuln/detail/CVE-2026-67598
• 📢 استشارة GitHub — GHSA-hf85-99vj-m4c5
• 📦 البائع (Vendor) — https://github.com/emlog/emlog
• 📝 التقرير الكامل — REPORT.md

_{نُشر لأغراض تعليمية وأمنية دفاعية ضمن إطار الكشف المنسّق.
تم الاكتشاف والإبلاغ بواسطة Ilhomjon Rustamov (@IlhomjonR) · CNA: VulnCheck}