Una infección de WordPress no siempre se queda en la página donde aparece el problema.
En este caso real, una empresa tenía cuatro instalaciones WordPress alojadas bajo una misma cuenta de hosting en IONOS. Una de ellas había sido comprometida con malware, pero la incidencia terminó obligando a revisar y asegurar también las otras tres.
El problema incluía archivos modificados, una cuenta de administrador que no debía existir y otra instalación WordPress antigua que también estaba contaminada.
La limpieza y recuperación necesitó 16 horas de trabajo.
Por privacidad, hemos eliminado cualquier dato que permita identificar a la empresa o sus dominios. Sí mencionamos IONOS porque el proveedor de alojamiento forma parte del contexto técnico del caso.
La empresa gestionaba varios proyectos web utilizando una única cuenta de alojamiento en IONOS.
Entre ellos había cuatro instalaciones independientes de WordPress. Una correspondía además a una tienda online, por lo que una pérdida de datos podía afectar no solamente al contenido de la página, sino también a clientes, usuarios y pedidos.
Cuando se analizó una de las instalaciones aparecieron indicios claros de que no se trataba simplemente de un plugin que había dejado de funcionar.
Había numerosos archivos que habían sido modificados o añadidos y que no correspondían con los que deberían estar en una instalación normal de WordPress.
También apareció algo especialmente preocupante: una cuenta de administrador no legítima.
Eso cambiaba completamente el diagnóstico.
No bastaba con actualizar un plugin o restaurar una página. Había que considerar que alguien había conseguido modificar la instalación.
Este tipo de incidente requiere un proceso distinto al de una avería normal. En nuestra guía sobre cómo recuperar y reforzar un WordPress tras un hackeo explicamos por qué recuperar la página es solo una parte del trabajo: también hay que revisar accesos, archivos modificados y posibles mecanismos que permitan una reinfección.
Durante la revisión aparecieron archivos PHP sospechosos en distintas zonas de la instalación.
Entre ellas:
wp-contentwp-content/uploadswp-adminwp-includesNo publicaremos los nombres originales de esos archivos.
El problema importante es otro: una infección de WordPress puede dejar archivos repartidos en distintas carpetas para mantener el acceso incluso después de eliminar el componente que inicialmente permitió entrar.
Por eso una limpieza no debería limitarse a borrar el primer archivo que detecte un antivirus.
Hay que comprobar qué archivos deberían existir, cuáles han cambiado y qué otros mecanismos pueden haber quedado dentro de la instalación.
La carpeta wp-content/uploads normalmente contiene las imágenes, documentos y otros archivos multimedia que se suben desde WordPress.
Encontrar allí determinados archivos PHP es una señal que merece investigación.
En esta intervención aparecieron archivos sospechosos precisamente en esa zona.
Eso no significa que cualquier archivo PHP encontrado en una instalación sea necesariamente malware. Pero sí significa que hay que comprobar su procedencia antes de eliminarlo o considerarlo legítimo.
Los archivos modificados no fueron el único indicio.
También apareció un usuario con permisos de administrador que no correspondía a ninguna persona autorizada.
Este detalle es especialmente importante porque una infección puede sobrevivir aunque se eliminen los archivos inicialmente detectados si el atacante conserva otra forma de entrar.
Por eso, tras un incidente, hay que revisar al menos:
Una auditoría de usuarios es una parte básica de cualquier recuperación de WordPress comprometido.
Aquí estaba una de las particularidades del caso.
La empresa tenía otras tres instalaciones WordPress dentro de la misma cuenta de alojamiento.
Según la documentación de la intervención, IONOS había aplicado determinados bloqueos sobre el resto de los sitios para evitar que el problema pudiera propagarse.
Por tanto, aunque el malware se hubiera detectado inicialmente en una instalación, no era razonable asumir automáticamente que las demás estaban limpias.
Las cuatro tuvieron que ser revisadas.
Este es uno de los riesgos de alojar numerosas webs independientes bajo una misma cuenta: administrativamente resulta cómodo, pero un incidente en una de ellas puede aumentar mucho el alcance del problema.
No significa que compartir hosting provoque una infección. Significa que, cuando se produce una incidencia, hay que entender cómo están aisladas las diferentes instalaciones y qué recursos comparten.
Durante la revisión del alojamiento apareció otro problema importante.
Existía un antiguo subdominio con una instalación WordPress que ya no era necesaria.
También estaba contaminada.
La solución en este caso no fue intentar recuperarla. Se eliminó completamente:
Es un ejemplo de un problema bastante habitual.
Una empresa puede renovar su web y dejar la antigua en una carpeta, crear páginas temporales para una campaña o instalar WordPress en un subdominio para realizar pruebas.
Meses después, nadie se acuerda de ellas.
Pero siguen estando conectadas a Internet.
Y si contienen una versión antigua de WordPress, un plugin vulnerable o un tema que ya no recibe mantenimiento, pueden acabar convirtiéndose en uno de los puntos más débiles del servidor.
La regla práctica es sencilla: si una instalación WordPress ya no tiene ninguna función, normalmente es más seguro eliminarla que abandonarla.
La recuperación no consistió en instalar un plugin de seguridad y pulsar un botón.
Hubo que actuar sobre distintos niveles.
Se revisaron los archivos identificados como modificados o sospechosos y se eliminaron los que no correspondían con una instalación legítima.
También se revisaron diferentes directorios de WordPress buscando restos de la infección.
Eliminar malware requiere especial cuidado.
Borrar el archivo equivocado puede romper la web. Mantener un archivo comprometido puede permitir que el atacante vuelva a entrar.
Por eso es importante distinguir entre archivos del propio WordPress, archivos de plugins y temas y elementos que no deberían estar allí.
La antigua instalación del subdominio se eliminó completamente porque no existía ninguna razón para mantenerla.
No tenía sentido invertir tiempo en asegurar una web abandonada que ya no cumplía ninguna función.
Además de reducir el riesgo, eliminar instalaciones innecesarias simplifica mucho el mantenimiento futuro.
Las otras webs alojadas bajo la misma cuenta también fueron revisadas y actualizadas.
Esta decisión es importante porque limpiar solamente el sitio donde inicialmente aparece el malware puede dejar sin resolver el verdadero alcance del incidente.
Cuando varias instalaciones comparten alojamiento hay que comprobar si el problema está realmente aislado.
Se renovaron las credenciales asociadas a las instalaciones.
Entre ellas, contraseñas de usuarios con permisos elevados y accesos relacionados con el servidor.
Cambiar contraseñas después de una infección no es una precaución exagerada.
Si una credencial ha podido quedar expuesta, mantenerla permitiría volver a entrar aunque toda la instalación hubiera sido limpiada correctamente.
Se activó autenticación de doble factor para usuarios con privilegios.
Con 2FA, conocer la contraseña deja de ser suficiente para acceder al panel de administración.
Se necesita además un segundo elemento de autenticación generado, por ejemplo, mediante una aplicación instalada en el teléfono.
No sustituye a una buena contraseña ni evita todas las formas de ataque, pero añade una barrera útil frente al robo de credenciales.
También se modificó la dirección utilizada para acceder a la administración de WordPress.
Conviene hacer aquí una precisión.
Cambiar /wp-admin o la URL habitual de inicio de sesión no convierte WordPress en seguro.
No debería considerarse una medida equivalente a actualizar WordPress, controlar usuarios o utilizar 2FA.
Sí puede reducir determinadas peticiones automatizadas y formar parte de una estrategia de endurecimiento, pero no sustituye a las medidas de seguridad realmente importantes.
Las distintas instalaciones tenían que quedar en un estado mantenible.
Se actualizaron:
También se eliminaron plugins que ya no eran necesarios.
Mantener componentes inutilizados tiene poco sentido. Aunque estén desactivados, siguen siendo archivos presentes en el servidor y pueden acabar olvidándose.
Cuantos menos componentes innecesarios tenga una instalación, menor será también la superficie que habrá que revisar y mantener.
Las actualizaciones son además una de las medidas básicas para reducir la exposición a vulnerabilidades conocidas. En nuestra guía sobre actualizar WordPress por seguridad explicamos cómo actualizar núcleo, plugins y temas de forma controlada y por qué conviene probar los cambios antes cuando se trata de una web importante para el negocio.
Las instalaciones utilizaban PHP 7.4 y fueron migradas a PHP 8.2.
La actualización se realizó dentro del proceso general de modernización del entorno.
Cambiar PHP tampoco debe hacerse a ciegas. Antes hay que comprobar que el tema y los plugins utilizados sean compatibles con la nueva versión.
En este caso, además, la actualización de distintos componentes provocó una incidencia de visualización relacionada con un plugin de traducción, que también tuvo que corregirse.
Es un buen ejemplo de por qué una recuperación de seguridad puede terminar descubriendo problemas adicionales de compatibilidad.
WordPress, PHP, los plugins y los temas evolucionan de forma conjunta. Mantener durante años una instalación sin revisar puede acabar creando una cadena de incompatibilidades que hace cada vez más difícil actualizarla. Es una de las razones por las que conviene plantear las actualizaciones de WordPress en una web de empresa como un proceso de mantenimiento y no como una tarea que se realiza únicamente cuando aparece un problema.
En las instalaciones se configuraron herramientas de seguridad, entre ellas Wordfence y Security Optimizer.
El objetivo no era considerar que instalar estos plugins resolvía por sí solo el problema.
La limpieza se había realizado antes.
Estas herramientas se incorporaron después como parte de las medidas para:
Un plugin de seguridad es mucho más útil como herramienta preventiva y de vigilancia que como sustituto de una limpieza técnica cuando la web ya ha sido comprometida.
Tras finalizar los trabajos se generaron copias de seguridad de las instalaciones.
Inicialmente también se configuraron backups periódicos.
Pero apareció otra conclusión importante: las copias críticas no deberían depender exclusivamente del mismo alojamiento que protege la web original.
Si el problema afecta al servidor completo, una copia almacenada únicamente dentro de ese mismo entorno puede verse también comprometida, eliminada o inaccesible.
Para una tienda online, además, la frecuencia importa mucho.
Si la última copia disponible tiene una semana y tienes que restaurarla, podrías perder una semana de:
Por eso en una web con actividad comercial puede tener sentido trabajar con copias diarias o incluso estrategias más frecuentes, dependiendo del volumen de cambios.
La frecuencia no es la única decisión importante. También hay que determinar qué se copia, cuántas versiones se conservan, dónde se almacenan y, sobre todo, comprobar que realmente pueden restaurarse. En nuestra guía de copias de seguridad para WordPress explicamos cómo plantear una estrategia de backup que no dependa exclusivamente del servidor donde está alojada la web.
La infección no fue lo único que apareció durante la intervención.
La cuenta de IONOS también había alcanzado el límite de archivos y carpetas permitido por el plan contratado.
Hubo que eliminar miles de archivos que ya no se utilizaban.
Este problema puede resultar confuso para el propietario de una web porque todavía puede quedar espacio disponible en disco y, aun así, el hosting impedir crear nuevos archivos.
Los proveedores pueden establecer otros límites además del almacenamiento total.
Por ejemplo, el número de archivos que puede contener una cuenta.
Las copias de seguridad acumuladas, instalaciones antiguas, cachés y archivos temporales pueden hacer crecer ese número de forma considerable.
Por eso conviene revisar periódicamente qué se está almacenando realmente en el servidor.
Tener cuatro WordPress bajo una misma cuenta resulta cómodo.
Solo hay que gestionar un proveedor y un único alojamiento.
Pero también crea dependencias.
Cuando una instalación queda comprometida, hay que valorar qué otras webs pueden verse afectadas y cómo está configurado el aislamiento entre ellas.
En este caso, el incidente llevó a recomendar que se revisara la estrategia de alojamiento y, cuando se acercara la renovación, considerar un hosting con mayores recursos y un soporte técnico más adecuado para el tipo de webs utilizadas.
No porque IONOS fuera la causa demostrada de la infección —la documentación disponible no permite afirmar cuál fue exactamente la puerta de entrada—, sino porque la capacidad de respuesta del alojamiento también importa cuando aparece un problema grave.
También conviene distinguir responsabilidades. El proveedor de hosting puede aplicar medidas sobre su infraestructura, bloquear determinados archivos o limitar una cuenta ante una incidencia, pero eso no equivale a mantener y supervisar cada instalación WordPress del cliente.
Para una pyme, confundir ambas cosas puede acabar dejando tareas importantes sin responsable. Es uno de los problemas que tratamos al analizar los problemas de WordPress que más afectan a las pymes.
Hay algo que conviene dejar claro.
La documentación de aquel trabajo permite saber qué se encontró y qué se hizo para solucionarlo, pero no identifica de forma concluyente el vector inicial de entrada.
No podemos afirmar que el ataque se produjera por un plugin vulnerable, una contraseña comprometida, una versión antigua de WordPress o cualquier otra vía concreta.
Sí sabemos que había:
Pero convertir cualquiera de esos elementos en la causa inicial sería ir más allá de lo que permite demostrar la documentación disponible.
Es una pregunta importante.
La web posiblemente habría vuelto a funcionar.
Pero eso no significa que estuviera limpia.
Si se hubiera mantenido:
el problema podría haber reaparecido.
Una limpieza de WordPress no debería medirse únicamente por que la página vuelva a cargar.
Hay que intentar eliminar también las vías que puedan permitir volver a comprometerla.
Por eso la recuperación de una web infectada no termina cuando desaparece el síntoma visible. Hay que revisar el entorno y reforzarlo para reducir el riesgo de reinfección.
Algunas señales justifican una revisión:
Una única señal no demuestra siempre que exista una infección, pero sí puede justificar una auditoría.
El proceso de recuperación fue correcto para la situación encontrada, pero el caso deja varias mejoras evidentes para una estrategia moderna de mantenimiento.
La principal sería no depender exclusivamente de copias almacenadas dentro del mismo servidor.
También separaría, cuando el proyecto lo justifique, instalaciones especialmente sensibles —por ejemplo un eCommerce— del resto de webs menos críticas.
Y establecería un inventario claro de instalaciones.
En realidad, muchas de las medidas que hubo que aplicar después del incidente deberían formar parte del mantenimiento habitual: actualizaciones, copias externas, control de usuarios, revisión de plugins, monitorización y comprobaciones periódicas.
En qué debe incluir el mantenimiento de WordPress en 2026 explicamos cómo organizar estas tareas y por qué mantener una web no consiste simplemente en instalar las actualizaciones que aparecen en el panel.
Una empresa debería poder responder fácilmente a estas preguntas:
Si esas preguntas no tienen respuesta, existe una deuda de mantenimiento aunque las páginas aparentemente funcionen bien.
Este caso empezó con malware en una instalación y terminó obligando a revisar cuatro WordPress, eliminar una instalación abandonada, renovar credenciales, actualizar PHP, asegurar accesos, configurar copias y limpiar miles de archivos del alojamiento.
Ese es precisamente el problema con muchas infecciones.
Lo que se ve inicialmente puede ser solo una parte.
Si tu web WordPress ha sido comprometida, recuperar la página es el primer objetivo. Pero después hay que responder a otra pregunta mucho más importante:
¿hemos eliminado realmente la infección y cualquier posibilidad de que el atacante siga teniendo acceso?
En Arreglo tu Web trabajamos en la reparación, limpieza y revisión de instalaciones WordPress comprometidas, pero también en el mantenimiento posterior necesario para que la web quede actualizada, monitorizada y con una estrategia de recuperación.
Si tienes una incidencia o sospechas que algo no funciona como debería, puedes contactarnos para revisar tu WordPress.
