Causa raíz

El panel de administración de emlog pro incluye un asistente de IA que puede ejecutar SQL en nombre del administrador mediante POST /admin/ai.php?action=execute_tool. Varios problemas se acumulan en este único endpoint:

1. Sin token CSRF. Todos los demás archivos de acciones destructivas en admin/ llaman a LoginAuth::checkToken() primero (p. ej. admin/media.php:140). admin/ai.php nunca lo hace.
2. La autenticación es solo por cookie de sesión (admin/ai.php:152, User::isAdmin()) — sin comprobación de Origin/Referer.
3. La barrera de confirmación de escritura es una cadena pública hardcodeada. include/service/ai.php:594: if (trim($confirm_code) !== 'confirm'). Cualquier solicitud falsificada simplemente envía confirm_code=confirm.
4. El SQL de solo lectura no necesita confirmación en absoluto (include/service/ai.php:578,589) — una solicitud autenticada simple puede hacer SELECT de cualquier tabla.
5. Solo la tabla blog está protegida contra escritura (include/service/ai.php:591) — user y todas las demás tablas son totalmente escribibles.
6. La redacción de contraseñas es evadible mediante alias. La redacción solo coincide con el nombre literal de columna de salida password (include/service/ai.php:822-828) — SELECT password AS pwd_hash FROM user devuelve el hash en bruto.
7. La cookie de autenticación no tiene atributo SameSite (include/lib/loginauth.php:99), dejando la ventana de gracia "Lax+POST" predeterminada de Chrome (aproximadamente los primeros dos minutos después del inicio de sesión) como la única barrera entre esto y una entrega cross-site fiable.

Encadenados: una sola solicitud falsificada desde el navegador de un administrador lee todas las tablas (incluidos los hash de contraseñas) y escribe en todas las tablas excepto blog, incluida la sobrescritura directa de user.password.

PoC

Parte 1 — cadena de impacto bruto (poc_raw_impact.sh)

Aísla la primitiva de bypass de SQL/autenticación de la cuestión de la entrega CSRF. Ejecutar contra una instancia local que controles:

Esto inicia sesión como admin, extrae los hash de contraseñas mediante el bypass de alias de columna, sobrescribe la contraseña del administrador directamente a través de la tabla user, y luego vuelve a iniciar sesión con la contraseña elegida por el atacante desde un almacén de cookies nuevo — demostrando la toma de control total de la cuenta una vez que una solicitud autenticada llega al endpoint.

Parte 2 — entrega CSRF cross-site real (poc_csrf.html)

Resuelve la cuestión de SameSite con un navegador real en lugar de asumirlo. Sirve poc_csrf.html desde cualquier origen distinto al objetivo (una IP diferente es suficiente — Chrome trata IPs literales distintas como sitios separados) y consigue que un administrador con sesión iniciada lo abra dentro de aproximadamente dos minutos después de iniciar sesión:

El formulario se autoenvía al cargar, enviando una llamada falsificada query_database con confirm_code=confirm de forma cross-site.

Verificado en vivo: el POST cross-site falsificado llevaba la cookie de autenticación real del administrador (sec-fetch-site: cross-site, cookie adjunta), devolvió 200 {"code":0,"msg":"ok",...}, y la fila inyectada se confirmó presente mediante una lectura autenticada de seguimiento. Repetir la solicitud idéntica ~48 minutos después contra el mismo almacén de cookies, ahora envejecido, falló — no se adjuntó cookie y el servidor devolvió una redirección no autenticada, confirmando que la ventana Lax+POST de aproximadamente dos minutos es la restricción real (reflejada en AC:H).

Impacto

• Lectura completa de la base de datos: todas las tablas/columnas, incluidos los hash de contraseñas y cualquier secreto en emlog_options (credenciales SMTP, claves API, etc.).
• Escritura completa de la base de datos en todas las tablas excepto blog, incluida user — sobrescritura de rol/contraseña/correo, demostrada de extremo a extremo como toma de control de cuenta.
• Limitado a cuentas con role=admin; writer/editor están bloqueados por User::checkRolePermission(). No es escalada de privilegios desde un rol inferior — convierte un clic en un enlace malicioso por parte de un administrador con sesión iniciada en un compromiso total y silencioso del sitio.

Corrección

Añadir LoginAuth::checkToken() a execute_tool, establecer SameSite=Strict en la cookie de autenticación, y reemplazar la cadena estática confirm_code por un token real de sesión única y de un solo uso. Detalle completo de la remediación en el aviso.

Cronología de divulgación

• 2026-07-31 — Reportado a través de GitHub Security Advisories siguiendo el propio SECURITY.md de emlog.
• 2026-08-01 — El mantenedor publicó el aviso y solicitó un CVE.
• 2026-08-16 — CVE-2026-73847 asignado por GitHub (CNA).

Nota sobre el crédito: GitHub-como-CNA publicó el registro CVE sin una entrada credits, a pesar de que el propio GHSA acredita y acepta al reportante. Se envió una solicitud de corrección a [email protected] el 2026-08-16; este README se actualizará si se corrige el registro.

Aviso legal

Publicado después de que el aviso fuera público y se asignara un CVE, para uso defensivo/educativo. No ejecutes esto contra una instancia de emlog que no poseas o para la que no tengas autorización explícita de pruebas.