ilhomjonr/cve-2026-67598CVE-2026-67598 — Emlog Pro: deaktivierte TLS-Zertifikatsprüfung im KI-Assistenten (MITM → Diebstahl von API-Schlüsseln). CWE-295, CVSS 9.1. Gemeldet von @IlhomjonR.
| CVE ID | CVE-2026-67598 |
| Produkt | emlog/emlog — Emlog Pro |
| Betroffen | Emlog Pro bis einschließlich 2.6.23 |
| Schwachstelle | CWE-295: Unsachgemäße Zertifikatsprüfung |
| CVSS v4.0 | 9.1 — Kritisch |
| CVSS v3.1 | 7.4 — Hoch |
| Angriffsvektor | Netzwerknaher Angreifer · Keine Berechtigungen · MITM |
| CNA | VulnCheck · GHSA-hf85-99vj-m4c5 |
| Reserviert / Veröffentlicht | 2026-07-29 / 2026-08-03 |
| Forscher | Ilhomjon Rustamov (@IlhomjonR) |
Emlog Pro enthält einen für Administratoren gedachten KI-Assistenten (admin/ai.php + include/service/ai.php),
der ausgehende HTTPS-Aufrufe an einen konfigurierten LLM-Anbieter durchführt — Chat, Streaming, Bild-
generierung — sowie eine Bing-Scraping-Hilfsfunktion für den @em-help-Befehl.
Jeder Helfer für ausgehende Anfragen deaktiviert bedingungslos die TLS-Zertifikatsprüfung:
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
Die Verifizierung ist unabhängig von der konfigurierten Anbieter-URL oder dem Netzwerkpfad deaktiviert,
sodass jeder netzwerknahe / Man-in-the-Middle-Angreifer, der sich zwischen dem Emlog-Server und der
api_url befindet, die TLS-Sitzung transparent mit einem gefälschten Zertifikat abfangen kann und:
Authorization: Bearer <apiKey>-Header stehlen — den bezahlten LLM-Anbieter-API-Schlüssel der Website.query_database und update_config steuert.Dies ist ein reiner Transportsicherheitsfehler — er wird nicht durch die Bestätigungs-UI für KI-Tool-Aufrufe abgesichert.
flowchart LR
A["🖥️ Emlog server<br/>AI assistant"] -->|"HTTPS request<br/>Bearer <apiKey>"| 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;include/service/ai.php — die CURLOPT_SSL_VERIFYPEER / CURLOPT_SSL_VERIFYHOST-Aufrufe in:
| Funktion | Zweck |
|---|---|
send() | LLM-Chatanfrage |
sendStream() | Streaming-Chatantwort |
sendImageRequest() | KI-Bildgenerierung |
fetchSearchHtml() | Bing-Scraping für @em-help |
# 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.
Screenshots der geprüften Emlog-Pro-2.6.23-Instanz befinden sich in
screenshots/ — Startseite und Admin-Login.
Aktivieren Sie die TLS-Verifizierung für alle ausgehenden Aufrufe in 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);
Selbst gehostete / OpenAI-kompatible Endpunkte mit einer privaten CA sollten über ein benutzerdefiniertes CA-Bundle (
CURLOPT_CAINFO) unterstützt werden — niemals durch globale Deaktivierung der Verifizierung.
Bei der Prüfung derselben KI-Funktion wurde festgestellt, dass Ai::queryDatabase() direkte
SQL-Schreibvorgänge auf die Tabelle blog gezielt blockiert, nicht jedoch auf die Tabelle
user (die role / password enthält). In Kombination mit dem Pfad der indirekten
Prompt-Injektion über @em-help (Live-Bing-Ergebnisse + gescrapte FAQ, die in ein Modell mit
query_database- / update_config-Toolzugriff eingespeist werden), lohnt sich eine Härtung,
indem user- / options-Schreibvorgänge über eng begrenzte Tools geleitet werden — so wie
write_article bereits Blog-Beiträge behandelt. Vollständige Details in
REPORT.md (getrennt von der obigen CVE verfolgt).
| Datum | Ereignis |
|---|---|
| 2026-07-24 | Schwachstelle bei der Prüfung von Emlog Pro 2.6.23 identifiziert (Commit ff5637e) |
| 2026-07-29 | CVE über VulnCheck reserviert |
| 2026-08-03 | CVE-2026-67598 veröffentlicht |
Veröffentlicht zu Bildungs- und Abwehrsicherheitszwecken im Rahmen koordinierter Offenlegung.
Entdeckt & gemeldet von Ilhomjon Rustamov (@IlhomjonR) · CNA: VulnCheck