CVE-2026-67598

Emlog Pro — Validación de certificados TLS deshabilitada en el asistente de IA

MITM adyacente a la red → robo de clave de API del proveedor de LLM e inyección de respuestas de IA

Resumen · Flujo del ataque · Código afectado · Prueba · Mitigación · Cronología · Referencias

📋 Resumen rápido

🔎 Resumen

Emlog Pro incluye un asistente de IA orientado al administrador (admin/ai.php + include/service/ai.php) que realiza llamadas HTTPS salientes a un proveedor de LLM configurado — chat, streaming, generación de imágenes — además de un ayudante de scraping de Bing para el comando @em-help.

Todos los ayudantes de solicitudes salientes deshabilitan incondicionalmente la validación del certificado TLS:

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

La verificación está desactivada independientemente de la URL del proveedor configurada o de la ruta de red, por lo que cualquier atacante adyacente a la red / intermediario (MITM) situado entre el servidor Emlog y la api_url puede interceptar de forma transparente la sesión TLS con un certificado falsificado y:

• 🔑 Robar la cabecera Authorization: Bearer <apiKey> — la clave de API de pago del proveedor de LLM del sitio.
• 💉 Inyectar una respuesta de IA maliciosa de vuelta en el asistente, que impulsa un LLM con acceso a las herramientas query_database y update_config.

Se trata de un defecto puramente de seguridad del transporte: no está condicionado por la interfaz de confirmación de llamadas a herramientas de IA.

🧭 Flujo del ataque

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;

💥 Impacto

• Divulgación de la clave de API — robo y abuso económico de la clave de pago del proveedor de LLM del sitio.
• Inyección de respuestas — el contenido controlado por el atacante entra en el flujo del asistente de IA.
• Baja barrera de explotación — cualquier posición adyacente a la red (alojamiento compartido, Wi-Fi hostil, router comprometido, proxy de salida malicioso) es suficiente; no se requieren credenciales en la instalación de Emlog.

📂 Código afectado

include/service/ai.php — las llamadas a CURLOPT_SSL_VERIFYPEER / CURLOPT_SSL_VERIFYHOST en:

🧪 Prueba / Verificación

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

🛠️ Mitigación

Habilita la verificación TLS en todas las llamadas salientes de 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);

Los endpoints autoalojados o compatibles con OpenAI que utilicen una CA privada deberían admitirse mediante un paquete de CA personalizado (CURLOPT_CAINFO) — nunca deshabilitando la verificación de forma global.

🔗 Nota relacionada (misma función, endurecimiento aparte)

Al auditar la misma función de IA, se descubrió que Ai::queryDatabase() bloquea específicamente las escrituras SQL directas en la tabla blog, pero no en la tabla user (que contiene role / password). Combinado con la vía de inyección indirecta de prompts a través de @em-help (resultados en vivo de Bing + preguntas frecuentes extraídas que se alimentan a un modelo con acceso a las herramientas query_database / update_config), esto merece un endurecimiento consistente en enrutar las escrituras de user / options a través de herramientas de alcance limitado, tal como write_article ya gestiona las publicaciones del blog. Todos los detalles en REPORT.md (se trata por separado del CVE anterior).

🗓️ Cronología

📚 Referencias

• 🆔 Registro CVE — https://www.cve.org/CVERecord?id=CVE-2026-67598
• 🛡️ NVD — https://nvd.nist.gov/vuln/detail/CVE-2026-67598
• 📢 Aviso de GitHub — GHSA-hf85-99vj-m4c5
• 📦 Proveedor — https://github.com/emlog/emlog
• 📝 Informe completo — REPORT.md

_{Publicado con fines educativos y de seguridad defensiva como parte de una divulgación coordinada.
Descubierto y reportado por Ilhomjon Rustamov (@IlhomjonR) · CNA: VulnCheck}