Cómo transformar un CRM corriente en un panel de control de servidores en un par de minutos: la historia de EspoCRM

En el popular sistema para la gestión de clientes EspoCRM se encontró una vulnerabilidad que convierte el acceso administrativo en control total sobre el servidor. Basta con seis peticiones para recorrer el camino desde el panel de administración hasta la ejecución de comandos en el sistema.

El problema identificado como CVE-2026-33656 afecta a la versión EspoCRM 9.3.3. La vulnerabilidad se detectó al analizar la imagen estándar con el servidor web Apache, donde la aplicación se ejecuta con la identidad del usuario www-data.

EspoCRM es un sistema de código abierto para la gestión de clientes, que a menudo eligen las empresas pequeñas y medianas. Incluye automatización de procesos, gestión de oportunidades, correo e incluso su propio motor de scripts. Precisamente ese motor fue el punto de partida del ataque.

EspoCRM incluye el llamado «motor de fórmulas», un lenguaje de scripting con el que el administrador puede modificar datos, lanzar procesos y probar la lógica a través de una interfaz separada. El acceso a ese motor está limitado a la cuenta de administrador, y en principio ese enfoque parece seguro. Pero se descubrió que el motor elude las restricciones internas a nivel de campos individuales.

En la interfaz habitual y mediante la API, parte de los campos están protegidos. Por ejemplo, algunos valores se marcan como «solo lectura» y no cambian incluso al enviar una solicitud. Pero el motor de fórmulas sigue otro camino y escribe los datos directamente, sin comprobar esas restricciones. Como resultado, el administrador puede modificar campos que, según la lógica del sistema, no deben tocarse.

Clave resultó ser el campo sourceId de los adjuntos. Es responsable de la ruta al archivo en el disco. Normalmente el sistema establece el valor y no permite cambiarlo. Pero a través del motor de fórmulas la restricción se elude. Tras eso, el atacante puede insertar cualquier ruta — por ejemplo, indicar un archivo fuera de la carpeta de cargas.

A partir de ahí empieza lo más interesante. El sistema forma la ruta al archivo mediante una concatenación simple de cadenas sin validación. Sin ninguna limpieza, sin restricciones. Como resultado, se abren inmediatamente dos posibilidades.

Primero: lectura de archivos arbitrarios. Basta con sustituir la ruta para obtener, por ejemplo, la configuración de la aplicación o el archivo con las credenciales de la base de datos.

Luego: escritura de archivos en cualquier ubicación. EspoCRM admite la carga de archivos por partes. Si se modifica la ruta antes de la carga, el sistema guardará los datos donde indique el atacante. Así se puede escribir un archivo propio, incluso en un directorio accesible desde el navegador.

Queda un último detalle. En una instalación estándar el servidor no siempre ejecuta esos archivos como código. Pero se evita el obstáculo mediante el archivo de configuración .htaccess. Añadiendo la regla necesaria, el atacante obliga al servidor a ejecutar el archivo subido como un script. Tras eso basta abrir una URL específica y el servidor comienza a ejecutar comandos. En la demostración del ataque, el sistema respondía con los permisos del usuario www-data con el que funciona el servidor web.

La vulnerabilidad no solo afecta la escritura y lectura de archivos. El mismo mecanismo permite leer campos ocultos en la base de datos. Entre ellos están los hashes de las contraseñas de los usuarios y los tokens de sesión activos. Ese acceso abre la puerta a un mayor desarrollo del ataque dentro del sistema.

La corrección se publicó con rapidez. En la versión EspoCRM 9.3.4 el desarrollador añadió la limpieza del nombre de archivo mediante la función basename, que corta cualquier intento de salir de los límites del directorio permitido. Los cambios se aplicaron de inmediato en varios puntos donde se forman las rutas a archivos. Tras eso la cadena de ataque deja de funcionar.

Sin embargo, no se modificó el propio motor de fórmulas. El autor del proyecto considera que la ausencia de comprobaciones a nivel de campos es una decisión intencionada, no un error. No obstante, precisamente la combinación de ese comportamiento con el tratamiento de archivos dio lugar a una vulnerabilidad crítica. El desarrollador publicó la actualización en el plazo de un día tras el informe del problema. Ahora se recomienda a los usuarios que actualicen lo antes posible a la versión 9.3.4 o superior.