La alerta de Imunify360
El 19 de abril de 2026 Imunify360 detectó y limpió automáticamente varios archivos en un servidor que administro. Los avisos fueron estos:
/modules/autoupgrade/ajax-upgradetabconfig.php
SMW-INJ-CLOUDAV-php.bkdr.upldr-25997-0 → Limpiado
[19/04/2026 22:41] DETECTADO
/modules/autoupgrade/views/index.php
SMW-BLKH-20053939-autoast → Contenido eliminado
[20/04/2026 12:04] DETECTADO
/crm.dominio.com/adminer.php
SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 → Contenido eliminado
[20/04/2026 12:04] DETECTADO
/crm.dominio.com/encrypt.php
SMW-BLKH-SA-CLOUDAV-php.admin.tool.db.adminer-NP118-3 → Contenido eliminado
Lo que más me llamó la atención fue que los dos últimos archivos —adminer.php y encrypt.php— estaban en el subdominio del CRM, no en PrestaShop. Alguien había colocado esos archivos ahí. Yo nunca los puse.
¿Falso positivo o infección real? El módulo Update Assistant (antes «1-Click Upgrade») acaba de actualizarse y algunos usuarios han reportado que Imunify lo detecta como sospechoso. Para confirmarlo, revisa la fecha y el tamaño del archivo ajax-upgradetabconfig.php. Si tiene fecha reciente y pesa menos de 200 bytes, es un backdoor, no el módulo original.
El origen: CVE-2024-37821 en Dolibarr
Analizando los logs del servidor aparecieron peticiones muy reveladoras. El servidor tenía Dolibarr 19.0.1 instalado en un subdominio CRM, y esa versión tiene una vulnerabilidad crítica documentada:
CVE-2024-37821 — Vulnerabilidad de subida arbitraria de archivos en la función «Upload Template» de Dolibarr ERP CRM hasta la versión 19.0.1. Permite ejecutar código arbitrario subiendo un archivo .SQL manipulado. Corregido en la versión 19.0.2.
Un atacante aprovechó esta vulnerabilidad para subir adminer.php al servidor. A partir de ahí tuvo acceso directo a la base de datos y capacidad de escribir archivos en cualquier parte del hosting — incluyendo el directorio de PrestaShop.
Cronología del ataque (reconstruida desde los logs)
Revisando los logs de acceso del servidor pude reconstruir exactamente lo que pasó y cuándo:
Septiembre de 2025: Una IP realiza un escaneo masivo probando decenas de variantes de adminer. La URL /adminer.php devuelve HTTP 200. El archivo existe y es accesible sin contraseña.
Octubre de 2025: Dos IPs distintas acceden directamente a adminer.php. Tienen acceso completo a la base de datos del CRM.
Abril–Junio de 2025: IPs del rango de Microsoft Azure acceden repetidamente con el parámetro ?db=stealth. Esa firma es característica de herramientas de explotación automatizada.
19 de abril de 2026: Imunify360 detecta y limpia los archivos infectados. El módulo Update Assistant falla con error 500 porque sus archivos han sido modificados.
Cómo lo resolví paso a paso
1. Verificar que la infección era real
El archivo ajax-upgradetabconfig.php del módulo tenía fecha del 19 de abril de 2026 y pesaba solo 123 bytes. El resto del módulo tenía fecha de octubre de 2025. Era un backdoor de subida de archivos, no parte del módulo legítimo.
2. Eliminar los archivos maliciosos
rm /var/www/vhosts/dominio.com/crm.dominio.com/adminer.php
rm /var/www/vhosts/dominio.com/crm.dominio.com/encrypt.php3. Reinstalar el módulo Update Assistant
Descargué la última versión desde el marketplace oficial de PrestaShop y lo reinstalé desde el panel de administración. Esto sustituyó los archivos infectados por los originales limpios.
4. Cambiar todas las contraseñas
Contraseña de la base de datos de Dolibarr (y actualizar conf/conf.php), contraseña de la base de datos de PrestaShop (y limpiar /var/cache/* a mano), y contraseña del panel de administración.
Ojo con la caché de PrestaShop: Si cambias la contraseña de la BD y aparece un error 500, borra la caché a mano desde SSH: rm -rf /ruta/prestashop/var/cache/*. No basta con el botón del panel de administración.
5. Actualizar Dolibarr para cerrar el CVE
# Backup previo — obligatorio antes de tocar nada
tar -czf /root/backup_dolibarr_$(date +%Y%m%d).tar.gz /ruta/al/crm/
mysqldump -u usuario -p nombre_bd > /root/backup_db_$(date +%Y%m%d).sql
# Copiar archivos nuevos manteniendo configuración y documentos
rsync -av --exclude='conf/conf.php' --exclude='documents/' \
dolibarr-21.0.1/htdocs/ /ruta/al/crm/
# Borrar install.lock para acceder al asistente de actualización
find /ruta/al/crm/documents/ -name "install.lock" -deleteLuego accede a https://crm.tudominio.com/install/ para completar la migración de la base de datos. Al terminar, vuelve a crear el archivo install.lock:
touch /ruta/al/crm/documents/install.lock
chmod 444 /ruta/al/crm/documents/install.lockLecciones aprendidas
Nunca dejes adminer.php accesible en producción. Si lo necesitas para gestionar una base de datos, súbelo, úsalo y bórralo inmediatamente. Nunca lo dejes en el servidor.
Mantén Dolibarr actualizado. El CVE-2024-37821 estaba publicado desde junio de 2024 y la versión 19.0.2 ya lo corregía. Un año sin actualizar fue suficiente para que los bots lo encontraran.
Imunify360 detecta pero no investiga. La herramienta limpió los archivos infectados, pero no indica de dónde vino el atacante. La revisión de los logs de acceso es imprescindible para cerrar el vector real.
Cuando Imunify limpia archivos de PrestaShop, revisa también el CRM. En este caso el vector de entrada no estaba en PrestaShop sino en Dolibarr. La infección se propagó entre aplicaciones del mismo hosting.
¿Te ha pasado algo similar?
Si has recibido alertas de Imunify360 en el módulo Update Assistant de PrestaShop y no tienes claro si es un falso positivo o una infección real, puedo ayudarte a investigarlo. Trabajo como consultor web independiente con más de 26 años de experiencia gestionando servidores y tiendas PrestaShop.
