CVE-2026-67598

Emlog Pro — Validation des certificats TLS désactivée dans l'assistant IA

MITM adjacent au réseau → vol de clé API du fournisseur LLM & injection de réponse IA

Résumé · Déroulement de l'attaque · Code affecté · Preuve · Correctif · Chronologie · Références

📋 En un coup d'œil

🔎 Résumé

Emlog Pro est fourni avec un assistant IA destiné à l'administration (admin/ai.php + include/service/ai.php) qui effectue des appels HTTPS sortants vers un fournisseur LLM configuré — chat, streaming, génération d'images — ainsi qu'un utilitaire de scraping Bing pour la commande @em-help.

Chaque utilitaire de requête sortante désactive inconditionnellement la validation des certificats TLS :

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

La vérification est désactivée quelle que soit l'URL du fournisseur configuré ou le chemin réseau ; par conséquent, tout attaquant adjacent au réseau / homme du milieu situé entre le serveur Emlog et le api_url peut intercepter de manière transparente la session TLS à l'aide d'un certificat forgé et :

• 🔑 Voler l'en-tête Authorization: Bearer <apiKey> — la clé API payante du fournisseur LLM du site.
• 💉 Injecter une réponse IA malveillante dans l'assistant, qui pilote un LLM disposant de l'accès aux outils query_database et update_config.

Il s'agit d'un pur défaut de sécurité du transport — il n'est pas conditionné par l'interface de confirmation des appels d'outils de l'IA.

🧭 Déroulement de l'attaque

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;

💥 Impact

• Divulgation de la clé API — vol et abus financier de la clé payante du fournisseur LLM du site.
• Injection de réponse — du contenu contrôlé par l'attaquant s'introduit dans le flux de l'assistant IA.
• Exploitation à faible barrière — toute position adjacente au réseau (hébergement mutualisé, Wi-Fi hostile, routeur compromis, proxy de sortie malveillant) suffit ; aucun identifiant sur l'installation Emlog n'est requis.

📂 Code affecté

include/service/ai.php — les appels CURLOPT_SSL_VERIFYPEER / CURLOPT_SSL_VERIFYHOST dans :

🧪 Preuve / Vérification

# 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.

🛠️ Correctif

Activez la vérification TLS pour tous les appels sortants dans 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);

Les points de terminaison auto-hébergés / compatibles OpenAI avec une AC privée devraient être pris en charge via un bundle d'AC personnalisé (CURLOPT_CAINFO) — jamais en désactivant la vérification globalement.

🔗 Note connexe (même fonctionnalité, durcissement distinct)

Lors de l'audit de la même fonctionnalité IA, Ai::queryDatabase() s'est avéré bloquer spécifiquement les écritures SQL directes dans la table blog mais pas la table user (qui contient role / password). Combiné au vecteur d'injection indirecte par invite via @em-help (résultats Bing en direct + FAQ scrapée injectées dans un modèle disposant de l'accès aux outils query_database / update_config), il vaut la peine de durcir le système en acheminant les écritures user / options via des outils à portée étroite — comme write_article le fait déjà pour les articles de blog. Détails complets dans REPORT.md (suivi séparé du CVE ci-dessus).

🗓️ Chronologie

📚 Références

• 🆔 Enregistrement CVE — https://www.cve.org/CVERecord?id=CVE-2026-67598
• 🛡️ NVD — https://nvd.nist.gov/vuln/detail/CVE-2026-67598
• 📢 Avis GitHub — GHSA-hf85-99vj-m4c5
• 📦 Éditeur — https://github.com/emlog/emlog
• 📝 Rapport complet — REPORT.md

_{Publié à des fins éducatives et de sécurité défensive dans le cadre d'une divulgation coordonnée.
Découvert & signalé par Ilhomjon Rustamov (@IlhomjonR) · CNA : VulnCheck}