- Monsta FTP presentaba una vulnerabilidad RCE (CVE-2025-34299) explotable sin autenticación a través de su API.
- El fallo permitía descargar desde un SFTP malicioso y escribir archivos en rutas arbitrarias del servidor web.
- La vulnerabilidad se ha corregido en la versión 2.11.3, pero muchas instancias siguen desactualizadas.
- Actualizar, restringir el acceso a la API y reforzar la segmentación y monitorización es clave para mitigar el riesgo.
Si administras servidores o te encargas de la parte técnica de una web, te interesa conocer muy bien qué está pasando con Monsta FTP y su grave fallo de ejecución remota de código. Esta vulnerabilidad se ha convertido en un problema serio porque afecta a un cliente FTP/SFTP muy extendido y, lo peor de todo, permite a un atacante tomar el control de la máquina sin necesidad de iniciar sesión.
En las siguientes líneas vamos a desgranar con detalle qué es Monsta FTP, cómo funciona el CVE-2025-34299 de ejecución remota, qué relación guarda con fallos anteriores (como los CVE de 2022), cómo se explota en la práctica y, sobre todo, qué medidas concretas puedes aplicar para proteger tus sistemas. La idea es que tengas una visión completa y muy práctica, sin quedarnos en la teoría ni repetir al pie de la letra lo que ya se ha publicado.
Qué es Monsta FTP y por qué es tan atractivo para los atacantes
Monsta FTP es un cliente FTP/SFTP basado en web que se instala en un servidor y permite gestionar ficheros a través del navegador, sin necesidad de usar herramientas de escritorio como FileZilla. Es especialmente popular en entornos empresariales, organizaciones financieras y usuarios avanzados que quieren editar, subir y descargar archivos desde cualquier sitio usando solo el navegador.
Una de sus particularidades es que, en muchas instalaciones, se despliega bajo la ruta por defecto /mftp/ en el servidor web. Este detalle, que parece menor, provoca que un gran número de instancias de Monsta FTP queden parcialmente “ocultas” de los escaneos masivos típicos en Internet, lo que complica que los administradores detecten rápidamente dónde lo tienen expuesto.
Su interfaz permite operar cómodamente sobre un servidor remoto: navegar directorios, subir archivos, descargar datos, modificar permisos o gestionar contenidos de forma muy parecida a como trabajarías con un gestor de ficheros del sistema operativo. Todo ello se traduce en que, si alguien logra abusar de estas capacidades, puede usar Monsta FTP como palanca para manipular el propio servidor web.
Además, Monsta FTP está desarrollado en PHP, un lenguaje muy extendido en el mundo web. Aunque PHP no es inseguro por sí mismo, su enorme flexibilidad hace que pequeños errores de validación de entrada se conviertan en vulnerabilidades críticas si el código no está bien diseñado o revisado.
Origen y contexto del fallo CVE-2025-34299 en Monsta FTP
El fallo de seguridad bautizado como CVE-2025-34299 fue identificado por el equipo de investigación WatchTowr Labs durante una revisión de seguridad de versiones previas de Monsta FTP. Inicialmente, su objetivo era reproducir vulnerabilidades conocidas (N-day) en versiones como la 2.10.3 y 2.10.4, pero durante este proceso acabaron destapando una debilidad adicional de tipo ejecución remota de código en versiones mucho más recientes.
El problema central está en cómo Monsta FTP maneja la entrada de usuario cuando se le pide que descargue ficheros desde un servidor SFTP remoto. En concreto, el endpoint de la API /mftp/application/api/api.php acepta peticiones con un parámetro llamado request, que encapsula en JSON todos los detalles de la operación a realizar.
Dentro de ese JSON se incluyen parámetros como connectionType, configuration, actionName y context. Entre ellos, context permite indicar tanto la ruta remota del fichero a descargar (remotePath) como la ruta local en el propio servidor donde se va a guardar ese archivo (localPath). Y aquí es donde se abre la puerta al desastre: la validación de estas rutas resultó ser insuficiente.
Los investigadores detectaron que, pese a la introducción de un módulo de validación de entradas llamado inputValidator.php en versiones más modernas (como la 2.11), la ruta donde realmente se producía la escritura insegura no estaba protegida correctamente. Se habían añadido controles y filtros por todo el código, pero no en el punto exacto donde se necesitaban para bloquear la explotación.
Relación con vulnerabilidades anteriores en Monsta FTP
Monsta FTP ya arrastraba un historial complicado en materia de seguridad. Versiones como la 2.10.3 y 2.10.4 aparecían vinculadas en bases de datos de vulnerabilidades a varios CVE relevantes: CVE-2022-31827, CVE-2022-27469 y CVE-2022-27468.
Entre estos fallos destacaban principalmente dos tipos de problemas: por un lado, vulnerabilidades de tipo SSRF (Server-Side Request Forgery), que permitían hacer que el servidor ejecutase peticiones HTTP arbitrarias hacia otros destinos, y por otro, una vulnerabilidad de subida de archivos arbitrarios que podía desembocar en ejecución de código.
WatchTowr montó dos entornos de prueba, uno con la versión 2.10.3 y otro con la 2.10.4, para comprobar si se había corregido algo entre ambas. La sorpresa fue que, comparando el código, apenas encontraron cambios relevantes más allá de pequeños retoques cosméticos, por lo que las vulnerabilidades documentadas en 2.10.3 seguían presentes en 2.10.4.
Reprodujeron las pruebas de concepto disponibles públicamente, por ejemplo para el SSRF (CVE-2022-31827), enviando peticiones POST contra api.php con datos especialmente formados, y comprobaron que el comportamiento vulnerable se mantenía sin dificultad. Esto apuntaba a un problema de fondo: las versiones supuestamente más recientes seguían arrastrando las mismas debilidades.
Posteriormente, al analizar la rama 2.11, comprobaron que se habían añadido funciones de validación muy completas: controles de longitud de rutas, detección de patrones de directory traversal, prohibición de rutas absolutas cuando no se permiten y normalización de paths. Sin embargo, al lanzar de nuevo las pruebas para el SSRF y para el vector que daba lugar a la ejecución de código, la explotación seguía siendo posible, lo que indicaba que los parches no estaban colocados en los puntos críticos del flujo de ejecución.
CVE-2025-34299: ejecución remota sin autenticación
El núcleo del CVE-2025-34299 es un escenario de ejecución remota de código (RCE) preautenticada. Es decir, el atacante no necesita credenciales reales de acceso a Monsta FTP para explotar el fallo, lo que aumenta enormemente el riesgo para cualquier servidor expuesto a Internet.
Todo parte del endpoint /mftp/application/api/api.php, que recibe un parámetro request con un JSON. En este JSON, el atacante puede indicar que el tipo de conexión será SFTP mediante connectionType: «sftp», y detallar en el bloque configuration el host SFTP remoto, usuario, contraseña, puerto y directorio inicial, que en este caso serán un servidor SFTP malicioso controlado por el propio atacante.
El parámetro actionName determina qué operación debe ejecutar Monsta FTP una vez que se ha conectado al servidor remoto. Para explotar la vulnerabilidad, se usa la acción downloadFile, que hace que la aplicación intente descargar un archivo desde el servidor SFTP señalado en configuration.
Dentro de context se establecen dos valores esenciales: remotePath, que es la ruta del fichero a descargar desde el servidor SFTP malicioso (por ejemplo, un script PHP diseñado para abrir una shell), y localPath, que indica en qué ruta del propio servidor web se va a guardar ese archivo descargado.
La clave está en que localPath es controlado íntegramente por el atacante y no se valida ni se restringe adecuadamente a una zona segura o a un conjunto de directorios permitidos. Como consecuencia, es posible indicar rutas como /var/www/html/mftp/index3.php o cualquier otra ubicación que sea accesible por el servidor web, lo cual habilita al atacante para plantar código ejecutable donde más le convenga.
Detalles técnicos de la explotación a través de la API
El flujo interno de Monsta FTP, una vez que recibe la petición maliciosa, pasa por una serie de funciones que terminan ejecutando la descarga del archivo remoto. En el caso concreto de una conexión SFTP, la operación downloadFile delega en un manejador específico definido en SFTPConnection.php.
En este fichero, la lógica relevante se concentra en una función encargada de descargar el archivo. Primero construye una URL de tipo ssh2.sftp:// combinando el identificador de la conexión SFTP con la ruta remota (remotePath) recibida desde el JSON. Ese valor se pasa a la función nativa de PHP copy(), que copia el contenido de ese recurso hacia la ruta local especificada.
La parte peligrosa reside en que la ruta de destino de esa copia es, precisamente, el valor de localPath controlado por el usuario. El código no fuerza a que el destino se encuentre dentro de un directorio restringido, ni impone comprobaciones adicionales sobre rutas absolutas o sobre si realmente debería permitirse escribir en esa ubicación concreta.
Por tanto, si el atacante hace que Monsta FTP se conecte a un servidor SFTP que él controla, puede colocar allí un archivo PHP malicioso (por ejemplo, un webshell) y ordenar al sistema que lo descargue hacia un directorio publicado por el servidor web. El resultado final es que el servidor web acaba alojando y ejecutando un script que el atacante ha introducido sin necesidad de autenticación previa.
Una vez copiado el archivo al directorio público, basta con que el atacante acceda mediante una petición HTTP normal a la ruta que acaba de crear (por ejemplo, /mftp/index3.php) para ejecutar su código con los permisos del usuario del servidor web (típicamente www-data) u otro usuario similar con permisos para leer y escribir en determinados directorios.
Ejemplo práctico de petición maliciosa y resultado
Para ilustrar el ataque, los investigadores enviaron una petición HTTP POST contra /mftp/application/api/api.php indicando en el cuerpo un JSON dentro del parámetro request, donde se definía una conexión SFTP hacia un servidor bajo control del atacante y se seleccionaba la acción downloadFile.
En ese JSON, el bloque de configuración incluía campos como «host», «remoteUsername», «password» y «port» apuntando al servidor SFTP malicioso, mientras que en el bloque context se fijaba remotePath a un fichero llamado, por ejemplo, shell.php y localPath a una ruta como /var/www/html/mftp/index3.php. De esta forma, Monsta FTP se veía obligado a copiar el archivo desde el servidor remoto hacia esa ruta concreta en el servidor local.
Tras enviar la petición, al realizar un GET contra /mftp/index3.php se comprobó que el archivo se había creado y que, al ejecutarse, devolvía un resultado que demostraba que el proceso de PHP estaba corriendo con los privilegios del usuario del servidor web. Esto confirmaba que, en la práctica, se había conseguido una ejecución remota de código completa y funcional.
La explotación es especialmente preocupante porque no requiere disponer de credenciales válidas de Monsta FTP. Mientras la API esté expuesta y se pueda enviar la petición con el formato esperado, el atacante puede orquestar todo el flujo: conexión a un SFTP propio, descarga de un payload y escritura en una ubicación elegida a voluntad dentro del sistema de ficheros del servidor.
Esto permite desde la instalación de webshells persistentes hasta la exfiltración de datos, despliegue de malware adicional, creación de puertas traseras o incluso el movimiento lateral hacia otros sistemas internos, dependiendo de cómo esté segmentada la red y de los permisos efectivos del proceso del servidor web.
Versiones afectadas, parche y asignación del CVE
La vulnerabilidad fue detectada inicialmente en versiones como 2.10.3, 2.10.4 y 2.11, que ya arrastraban otros fallos históricos. A pesar de los esfuerzos por introducir validaciones adicionales mediante el fichero inputValidator.php, el flujo de descarga de archivos seguía permitiendo escribir en rutas arbitrarias.
WatchTowr informó de manera responsable del problema al equipo de desarrollo de Monsta FTP a mediados de agosto de 2025, iniciando un proceso de coordinación para corregir el fallo. La respuesta fue relativamente rápida, y en cuestión de pocos días comenzaron las labores de solución y análisis de impacto.
El 26 de agosto de 2025 se publicó la versión 2.11.3 de Monsta FTP, que incorpora el parche que cierra la brecha de seguridad. En esta versión se implementaron controles adecuados sobre las rutas de escritura, se reforzaron las comprobaciones sobre los parámetros de la API y se limitó de forma mucho más estricta el comportamiento de las operaciones de descarga de ficheros.
Posteriormente, el 4 de noviembre de 2025, se asignó oficialmente el identificador CVE-2025-34299 a la vulnerabilidad descubierta (referenciada internamente por WatchTowr como WT-2025-0091). Dos días después, el laboratorio de investigación publicó un informe detallando todo el proceso de descubrimiento, análisis, explotación y mitigación.
Aunque el parche ya está disponible, los investigadores estiman que miles de instancias de Monsta FTP siguen potencialmente vulnerables en Internet porque muchos administradores aún no han actualizado o ni siquiera son conscientes de que lo tienen expuesto en producción.
Medidas de mitigación y estrategias de defensa
La primera y más importante de las medidas es actualizar Monsta FTP a la versión 2.11.3 o superior. Esta versión contiene las correcciones necesarias para evitar que se puedan escribir archivos arbitrarios mediante la operación de descarga desde SFTP, y cierra los vectores de ataque asociados a CVE-2025-34299.
Además del parche, es recomendable limitar el acceso a la API /mftp/application/api/api.php únicamente a redes de confianza o a direcciones IP concretas. Esto puede hacerse mediante reglas de firewall, listas de control de acceso en el servidor web, filtros específicos a nivel de proxy inverso o configuraciones de red para gestionar los puertos FTP, SSH y HTTP, de forma que no esté disponible abiertamente para cualquiera en Internet.
Otra capa de defensa importante es la segmentación de red. Mantener los servicios web de cara al público separados de los sistemas internos más críticos reduce el impacto de una posible intrusión. Aunque un atacante consiga comprometer un servidor con Monsta FTP, el daño potencial será menor si no puede pivotar fácilmente hacia bases de datos sensibles, sistemas de respaldo u otros recursos clave.
También conviene desplegar y ajustar un WAF (Web Application Firewall) que aplique reglas de validación de entrada, detección de patrones de travesía de directorios y bloqueo de peticiones sospechosas hacia la API de Monsta FTP. Un buen conjunto de reglas puede ayudarte a mitigar tanto este problema concreto como futuros fallos que sigan patrones similares.
Por último, es fundamental reforzar la configuración de permisos en el servidor: reducir al mínimo los privilegios del usuario bajo el que corre el servidor web, deshabilitar permisos de escritura allí donde no sean necesarios y revisar periódicamente qué directorios son realmente públicos y, si es necesario, instalar y configurar un servidor FTP siguiendo buenas prácticas. Cuanto menos pueda escribir el proceso de PHP en el sistema de ficheros, más difícil será materializar un RCE de este tipo.
Detección, monitorización y buenas prácticas complementarias
Además de parchear, merece la pena implantar mecanismos de monitorización orientados a detectar comportamientos anómalos. En el caso concreto de esta vulnerabilidad, el vector de ataque implica que el servidor Monsta FTP se conecte a un host SFTP externo controlado por el atacante.
Por ello, una medida eficaz consiste en vigilar tráfico saliente inusual en puertos de SFTP/SSH (normalmente el 22) y revisar la configuración de puertos HTTP, HTTPS y FTP. Si un servidor web que no debería establecer conexiones SFTP hacia el exterior empieza a hacerlo, es una señal de alerta que conviene investigar.
La ejecución de auditorías de vulnerabilidades y escaneos periódicos ayuda a localizar instancias de Monsta FTP olvidadas o mal configuradas. Muchas organizaciones instalan este tipo de herramientas en su día a día, y con el paso del tiempo se quedan sin mantenimiento, convirtiéndose en un blanco perfecto para atacantes que buscan software desactualizado.
Tener un proceso sólido de gestión de parches, con inventario actualizado de activos y aplicaciones expuestas, reduce el tiempo que pasa entre la publicación de una actualización de seguridad y su despliegue efectivo en todos los entornos (desarrollo, pruebas y producción).
Por último, adoptar un enfoque de seguridad de tipo zero-trust ayuda a mitigar este tipo de problemas a largo plazo. Este modelo parte de la idea de no confiar en ningún componente por defecto, exigiendo verificación continua de identidades, accesos y comportamientos, incluso dentro de la red interna. Aunque no evita que aparezcan vulnerabilidades, sí limita en gran medida el impacto que pueden tener.
Todo lo ocurrido con Monsta FTP pone de manifiesto que la validación de entradas y la aplicación rigurosa de parches son tareas continuas, no actividades puntuales. En un entorno donde nuevas vulnerabilidades críticas aparecen con frecuencia —como se ha visto también en otros productos muy extendidos, por ejemplo con fallos de tipo «Type Confusion» en motores JavaScript de navegadores—, mantener una disciplina estricta de actualización y defensa en profundidad marca la diferencia entre un incidente controlado y una brecha grave.
Queda claro que este fallo en Monsta FTP no es un suceso aislado sino un ejemplo más de cómo una combinación de validaciones incompletas, exposición innecesaria de servicios y retrasos en la actualización puede acabar abriendo la puerta a una ejecución remota de código sin autenticación. Conocer a fondo este caso y aplicar las medidas descritas permite reforzar la postura de seguridad y evitar que una herramienta pensada para facilitar la gestión de ficheros se convierta en el punto de entrada a todo tu servidor.
