Un análisis de aplicaciones web busca señales relacionadas con vulnerabilidades conocidas, configuraciones inseguras, componentes desactualizados, archivos sospechosos y comportamientos que podrían aumentar el riesgo de un sitio. El resultado es un punto de partida para investigar: una alerta no demuestra por sí sola que la aplicación haya sido atacada o comprometida.
Antes de eliminar archivos o modificar la configuración, hay que identificar qué detectó la herramienta, dónde lo encontró y qué evidencia ofrece. Actuar únicamente por el nombre de una detección puede romper el sitio, borrar información útil para el diagnóstico o dejar sin corregir la causa real.
Qué puede revisar un análisis de aplicaciones web
El alcance depende de la herramienta y del plan contratado. Algunos análisis observan solamente lo que un visitante puede consultar desde Internet; otros también revisan archivos del hosting, versiones instaladas, base de datos o cambios dentro de la cuenta.
- CMS, temas, plugins, módulos y bibliotecas con vulnerabilidades conocidas.
- Cabeceras HTTP ausentes o configuraciones que exponen información.
- Formularios, parámetros y rutas que requieren una revisión más profunda.
- Archivos modificados, código ofuscado o patrones asociados con malware.
- Páginas de phishing, redirecciones extrañas o contenido agregado sin autorización.
- Servicios públicos y paneles administrativos que aumentan la superficie expuesta.
Un análisis externo no puede confirmar todo lo que ocurre dentro del servidor. Del mismo modo, un análisis de archivos puede no detectar una falla lógica que solamente aparece al utilizar una función concreta de la aplicación.
Primero registrá la alerta completa
Guardá el nombre de la detección, la URL o ruta afectada, la fecha con zona horaria, el nivel de severidad, la evidencia disponible y la herramienta que la generó. Si aparece un identificador como CVE, comprobá a qué producto y versiones corresponde.
Tomá una captura o exportá el informe antes de cambiar el sitio. Estos datos permiten comparar el resultado después de corregirlo y facilitan el trabajo del soporte o desarrollador.
Confirmá que el hallazgo corresponda al sitio
Los escáneres pueden inferir versiones a partir de archivos, cabeceras o respuestas que no siempre reflejan la instalación real. También pueden asociar una ruta común con un componente que no está activo. Verificá el CMS, plugin, tema o módulo desde el panel y desde los archivos de la cuenta.
En servidores que incorporan correcciones del proveedor, el número visible puede no contar toda la historia. No descartes la alerta, pero contrastala con la documentación del fabricante y las actualizaciones instaladas antes de aplicar cambios incompatibles.
Diferenciá vulnerabilidad de compromiso
Una vulnerabilidad es una debilidad que podría aprovecharse. Un compromiso significa que alguien ya obtuvo acceso o modificó el sistema. Encontrar una versión vulnerable exige corregirla, pero no confirma automáticamente que haya sido explotada.
En cambio, usuarios administrativos desconocidos, redirecciones no autorizadas, tareas programadas extrañas, archivos recientemente modificados o envíos masivos de correo son indicios que requieren investigar un posible incidente.
Evaluá severidad, exposición e impacto
No todos los hallazgos tienen la misma prioridad. Considerá si la función está publicada, si requiere autenticación, qué permisos tendría un atacante, si existe una corrección disponible y qué información procesa el sitio.
Una falla crítica en un componente activo y accesible desde Internet suele requerir atención inmediata. Una recomendación de configuración en una función deshabilitada puede planificarse, siempre que se documente y se confirme que realmente no está expuesta.
Hacé un respaldo antes de intervenir
Conservá archivos y base de datos antes de actualizar, reemplazar o limpiar componentes. El respaldo debe almacenarse fuera del directorio público y no debe sobrescribir la última copia conocida como segura.
Un backup creado después de una posible intrusión puede contener archivos maliciosos, pero sigue siendo útil para investigar y comparar. Etiquetalo con fecha y no lo utilices automáticamente como punto de restauración.
Si necesitás generar una copia desde el panel, consultá cómo generar un backup del sitio desde cPanel.
Elegí la corrección apropiada
- Actualizar: instalá una versión corregida del CMS o componente desde una fuente oficial.
- Eliminar: retiralo si no se utiliza o dejó de recibir mantenimiento.
- Mitigar temporalmente: restringí la función o ruta mientras preparás la solución definitiva.
- Corregir el código: si es un desarrollo propio, solucioná el origen y agregá una prueba que evite su reaparición.
- Ajustar la configuración: aplicá únicamente el cambio necesario y documentá el valor anterior.
Un WAF puede bloquear ciertos intentos conocidos, pero no reemplaza una actualización ni una corrección de código. Para entender su función, revisá qué es ModSecurity y cómo funciona como firewall de aplicaciones web.
Si sospechás que el sitio fue comprometido
Preservá registros y copias antes de limpiar. Revisá usuarios del CMS y del hosting, claves de API, tareas programadas, cuentas FTP, archivos modificados, procesos de correo y cambios en la base de datos. Compará el sitio con una copia confiable o con el paquete original de la aplicación.
Cambiá las credenciales desde un dispositivo limpio, cerrá sesiones activas y activá autenticación de dos factores donde esté disponible. No alcanza con borrar el archivo detectado: una puerta de entrada sin corregir permite que el atacante vuelva a crearlo.
La guía qué hacer si un análisis detecta malware o virus web amplía los pasos para revisar una detección de archivos.
Volvé a analizar y comprobá el funcionamiento
Después de corregir, limpiá las cachés necesarias y repetí el análisis. Verificá tanto la desaparición de la alerta como el funcionamiento de formularios, compras, accesos, tareas automáticas y otras funciones relacionadas.
Si la herramienta continúa informando el hallazgo, comprobá que no esté viendo una copia en caché, otro subdominio, un archivo de respaldo público o una instalación olvidada. Enviá al proveedor la evidencia de la corrección si el informe no se actualiza.
Qué información enviar al soporte
- Dominio y URL exacta afectada.
- Fecha y hora de la detección con zona horaria.
- Nombre de la herramienta, regla, firma o CVE informado.
- Ruta del archivo, versión instalada y captura del mensaje.
- Cambios realizados antes y después de la alerta.
No envíes contraseñas, códigos de recuperación ni tokens dentro del ticket. El soporte puede ayudarte a revisar el entorno de hosting, mientras que la corrección de una aplicación o extensión puede requerir la intervención de su desarrollador.
El análisis debe ser periódico
Una revisión sin hallazgos significa que la herramienta no detectó problemas dentro de su alcance y en ese momento; no garantiza que el sitio sea invulnerable. Mantené inventariados los componentes, aplicá actualizaciones, eliminá lo que no uses y revisá usuarios, backups y registros.
Un proceso ordenado —registrar, validar, priorizar, respaldar, corregir y volver a comprobar— permite responder a una alerta sin improvisar y reduce tanto el riesgo de una intrusión como el de dañar un sitio legítimo durante la reparación.
