En resumen: Si quiere eliminar el malware de su sitio web, borrar archivos sueltos rara vez es suficiente. Primero aseguramos el estado encontrado, localizamos webshells, puertas traseras y tareas ocultas, reconstruimos desde fuentes de confianza y cerramos la puerta de entrada. Solo entonces la limpieza es fiable.
Cómo reconocer el malware en un sitio web
El código malicioso en los sitios web suele notarse solo de forma indirecta. Son típicas las redirecciones a sitios ajenos, los contenidos de spam visibles solo para los buscadores o los dispositivos móviles, un aviso de Google en los resultados de búsqueda, quejas de clientes o un bloqueo por parte del proveedor de hosting por envío de spam. En el servidor aparecen archivos PHP desconocidos, cuentas de administrador nuevas, archivos .htaccess modificados o tareas cron inexplicables.
Tras PHP2Shell se añade otra preocupación: mediante CVE-2026-109618 y CVE-2026-109619, los atacantes pueden ejecutar código sin autenticarse. No hay indicadores de compromiso (IOC) confirmados y publicados; la detección se basa en el análisis del comportamiento. Cómo suelen ser las webshells y dónde se encuentran se describe en Reconocer y eliminar webshells.
Eliminar el malware de un sitio web: por qué es más importante hacerlo a fondo que rápido
Los atacantes rara vez dejan un solo archivo. Lo habitual son varias puertas traseras en lugares distintos: en carpetas de cargas, en plugins o temas, en plugins must-use, en la base de datos, en tareas cron o en cuentas de usuario adicionales. Si solo se borra el archivo más llamativo, el código malicioso vuelve.
Al mismo tiempo, el estado infectado es una prueba. Quien limpia con precipitación pierde la posibilidad de determinar si se han visto afectados datos de clientes. Por eso lo aseguramos todo antes de cualquier cambio. Cuesta poco tiempo y le mantiene todas las vías abiertas, también una posterior notificación a la autoridad de control o a la aseguradora.
Una actualización de PHP o del CMS no elimina el software malicioso que ya esté en el servidor. Y un sitio web limpiado volverá a infectarse mientras la puerta de entrada siga abierta.
Dónde suele esconderse el código malicioso
Revisamos los siguientes lugares en cada limpieza, porque en la práctica resultan afectados una y otra vez:
| Lugar | Hallazgo típico |
|---|---|
| Carpetas de cargas | archivos PHP con nombres de apariencia inofensiva o camuflados como imagen |
| Plugins, temas, módulos | archivos adicionales o archivos originales modificados |
| Configuración | líneas introducidas en .htaccess, .user.ini o archivos de entrada |
| Base de datos | cuentas de administrador ajenas, scripts en contenidos u opciones |
| Sistema | tareas cron, claves SSH adicionales, procesos sin finalidad reconocible |
| Cachés y carpetas temporales | copias de código malicioso que reaparecen tras borrarlas |
Lo importante es el conjunto: un hallazgo aislado rara vez explica todo el incidente. Solo la visión de conjunto muestra cómo procedió el atacante y si se llevó credenciales.
¿Cómo ayuda PHP SOS en concreto?
- Asegurar: creamos una copia de archivos, base de datos y registros en el estado infectado. Se conserva para una evaluación posterior.
- Buscar: comparamos los archivos del programa con los originales del fabricante, revisamos las carpetas de cargas en busca de código ejecutable y examinamos la base de datos, las tareas cron, las cuentas de usuario y la configuración del servidor. En entornos WordPress procedemos como se describe en Encontrar puertas traseras en WordPress.
- Limpiar: reinstalamos el núcleo, las extensiones y los temas desde fuentes de confianza, en lugar de remendar uno a uno los archivos sospechosos. Los contenidos propios y las cargas los revisamos por separado y solo conservamos lo que no ofrece dudas.
- Cerrar la causa: parcheamos PHP y la aplicación, eliminamos cuentas ajenas y cambiamos todas las credenciales y claves que el atacante pudiera haber visto.
- Control posterior: vigilamos el sitio web tras la limpieza por si aparecen nuevas modificaciones y le ayudamos a que se revise un aviso de Google a través de la Search Console. Más información en Eliminar el aviso de Google.
Para administradores, una primera mirada inofensiva a los archivos PHP modificados recientemente:
# Archivos PHP del directorio web modificados en los últimos 10 días
find /var/www -type f -name "*.php" -mtime -10 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort
El resultado es un indicio, no una prueba: los atacantes pueden modificar las marcas de tiempo.
Lo que recibe y lo que necesitamos
Recibirá un informe con los componentes maliciosos encontrados y dónde estaban, las medidas de limpieza, la lista de credenciales cambiadas y la probable puerta de entrada. Separamos claramente lo que está demostrado, lo que es probable y lo que se desconoce.
De usted necesitamos:
- acceso al servidor o al panel de hosting, al backend del CMS y a la base de datos
- una persona de contacto que pueda autorizar cambios de contraseña y desconexiones
- información sobre la agencia, el desarrollador o el proveedor de hosting y sobre las adaptaciones propias del sistema
- las copias de seguridad existentes con su fecha, para que podamos valorar qué estado podría estar limpio
- acceso a Google Search Console, si se muestra un aviso
Lo que no prometemos
No prometemos que se encuentre con seguridad toda puerta trasera en todo sistema si faltan registros o si la infección es antigua. Si la situación no está clara, recomendamos reconstruir en un servidor nuevo al que solo se transfieran contenidos revisados. Es más laborioso, pero a menudo es el camino más fiable. Tampoco predecimos cuándo Google u otros servicios retirarán un aviso; eso lo deciden esos proveedores.
Si hay que esclarecer con validez ante los tribunales qué ha ocurrido exactamente y qué datos se han visto afectados, incorporamos el análisis forense informático con socios especializados. En un ataque agudo y todavía en curso, el trabajo empieza con la ayuda de emergencia ante un sitio web hackeado.
Preguntas frecuentes
¿Basta con un plugin antimalware para limpiar mi sitio web?
Un escáner encuentra patrones conocidos, pero no todas las puertas traseras. Las webshells suelen estar ofuscadas, ocultas en imágenes, cachés o en la base de datos, o ancladas como tarea cron. Un escáner es una herramienta de apoyo, no una limpieza completa.
¿Puedo simplemente restaurar una copia de seguridad antigua?
Solo si es seguro que la copia es anterior a la intrusión y si después se cierra la puerta de entrada. De lo contrario, el sitio web queda limpio un momento y vuelve a infectarse por el mismo camino.
¿Por qué el malware reaparece una y otra vez tras borrarlo?
Casi siempre hay una segunda puerta trasera, una tarea cron, una cuenta de administrador manipulada, o la vulnerabilidad sigue abierta. Solo cuando se han encontrado todos los mecanismos de persistencia y se ha eliminado la causa, la limpieza se mantiene.
¿Elimina una actualización de PHP el malware existente?
No. Un parche cierra la vulnerabilidad, pero no elimina el software malicioso ya introducido. Son dos pasos de trabajo distintos.