Dentro de un wp2shell WordPress : compromiso y recuperación

En julio de 2026, dos sitios de WordPress con cuentas de InMotion Hosting fueron vulnerados en un intervalo de dos horas. Uno de ellos se limpió cuatro días después, pero volvió a infectarse seis días más tarde. Esto es lo que descubrieron nuestros equipos: las capas de persistencia que crean los atacantes tras el acceso inicial, los indicadores específicos que puedes comprobar hoy mismo en tus propios sitios y por qué eliminar las cuentas de administrador maliciosas no pone fin a la vulnerabilidad.

La mayoría de los artículos sobre wp2shell se han quedado en lo básico. La cadena de ataques permite que un atacante se cuele. Lo que realmente importa a cualquiera que se encargue de un sitio web de WordPress es lo que pasa en los minutos y días siguientes, y esa parte se ha documentado mucho menos.

Nuestros equipos investigaron dos casos distintos de vulnerabilidades en las cuentas de clientes a principios de agosto de 2026. Ambos sitios ya se han solucionado y han vuelto a estar operativos. Hemos eliminado de este texto los nombres de cuenta, dominios, identificadores de servidor y rutas de directorios. Sin embargo, no hemos eliminado los detalles sobre el comportamiento, ya que son los que ayudan a otros propietarios de sitios a detectar el mismo problema en sus propias instalaciones.

La cadena de vulnerabilidades es el punto de entrada, no el incidente Te cuento

wp2shell hace referencia a la cadena de vulnerabilidades del núcleo de WordPress CVE-2026-63030 y CVE-2026-60137, que, en conjunto, permiten a un atacante no autenticado ejecutar código de forma remota en una instalación estándar de WordPress . La primera vulnerabilidad es un problema de confusión de rutas en el punto final REST de procesamiento por lotes. La segunda es una inyección SQL en WP_Query. Al encadenarlas, hacen que una solicitud HTTP anónima termine en una cuenta de administrador creada por un atacante, sin necesidad de plugins, ni credenciales, ni que tengas que hacer nada.

Los límites entre versiones son importantes a la hora de clasificar los problemas. El análisis técnico de Patchstack sobre las notas de la versión señala que la vulnerabilidad de inyección SQL se remonta a WordPress 6.8, mientras que la confusión en el gestor de lotes —que la convierte en un ataque sin autenticación y accesible de forma remota— solo se introdujo en la versión 6.9. Un sitio de la rama 6.8 tiene la vulnerabilidad de inyección, pero no se puede llegar a la ejecución remota completa de código por esta vía.

WordPress El 17 de julio de 2026 se lanzaron las versiones de emergencia 6.9.5, 7.0.2 y 6.8.6 y se activaron las actualizaciones automáticas forzadas. La CISA añadió la vulnerabilidad a su catálogo de «Vulnerabilidades explotadas conocidas» el 21 de julio. A las pocas horas de darse a conocer, ya se notificaron casos de explotación en el mundo real, y en cuestión de días circularon docenas de implementaciones de prueba de concepto que funcionaban.

Los dos sitios que investigamos fueron atacados en las primeras 48 horas tras la aplicación del parche, desde redes no relacionadas entre sí, con un intervalo de unas dos horas. Vale la pena destacar ese intervalo. Nadie estaba atacando a estas empresas a propósito. Se trataba de tráfico de escaneo que detectaba cualquier sistema que aún no se hubiera parcheado.

Ninguna de las dos investigaciones pudo demostrar de forma concluyente cuál fue exactamente la falla de autorización utilizada en la primera solicitud. Esa limitación es estructural, más que local. Los registros de acceso estándar de Apache y NGINX registran la línea de solicitud, el código de estado y el User-Agent, y ningún formato de registro ampliamente utilizado conserva los cuerpos de las solicitudes, los encabezados de cookies, los encabezados de autorización ni los nonces REST. Esos campos son precisamente los que identificarían el mecanismo, y ningún servidor que utilice una pila de registro convencional los conserva.

Lo que sí conservan los registros, y lo que nuestros equipos han reconstruido a partir de ellos, es la secuencia. En ambos casos, se produjo una ráfaga de peticiones POST dirigidas a la ruta REST por lotes WordPress , que devolvieron un código de estado HTTP 207, seguida, en cuestión de segundos, por la creación de una cuenta de administrador. En uno de los sitios, las peticiones incluían una cadena «User-Agent» que coincidía con el nombre publicado de la cadena de exploits. En ese mismo sitio, no se registró ningún inicio de sesión correcto de la cuenta de administrador original en el momento en que se realizaron las acciones en su nombre, lo que encaja más con un exploit sin autenticación que con una contraseña robada.

Las pruebas concuerdan con wp2shell. No cumplen los requisitos para una atribución definitiva, y no vamos a hacerla. Afirmar que un CVE concreto ha provocado un incidente específico, sin pruebas a nivel de solicitud que lo respalden, es la forma en que acaban registrándose causas raíz erróneas y se da prioridad a medidas correctivas equivocadas.

La primera carga útil aterrizó en menos de medio minuto

La secuencia en la primera página web, reconstruida a partir de los registros de acceso y de los registros de actividad de WordPress , fue la siguiente:

1. Una solicitud llegó a la ruta REST de procesamiento por lotes y devolvió un código HTTP 207.
2. Dos segundos después, se registró una acción realizada desde la IP del atacante con la cuenta de administrador original del sitio, en la que se modificó un registro interno inusual de una publicación.
3. Un segundo después, ese mismo contexto creó una nueva cuenta de administrador con un nombre pensado para que pareciera una cuenta de servicio.
4. Ocho segundos después, la nueva cuenta se conectó sin problemas.
5. Once segundos después, subió un archivo ZIP con un plugin.
6. Tres segundos después, el plugin ya estaba instalado y activado.
7. Un segundo después, el atacante borró el archivo ZIP de la biblioteca multimedia.

De principio a fin, unos 24 segundos. El segundo sitio siguió el mismo patrón y completó la misma secuencia en unos 28 segundos.

El plugin aparecía en el panel de control de WordPress como una herramienta de seguridad con un nombre y un número de versión bastante creíbles. El nombre de su directorio parecía el de un plugin de rendimiento legítimo al que se le había añadido un sufijo hexadecimal aleatorio. Cualquiera que echara un vistazo rápido a la lista de plugins lo habría pasado por alto sin más.

Trece segundos después de la instalación, el atacante solicitó directamente el archivo PHP principal del plugin y lo ejecutó id && uname -a && hostname && pwd. Devolvió un código de estado HTTP 200. A partir de ahí, el atacante pudo ejecutar comandos de shell con los privilegios de la cuenta cPanel .

La investigación saca a la luz la campaña del hacker

Lo que el atacante comprobó a continuación dice más sobre sus intenciones que cualquier parte del malware. Al leer esos comandos en orden, nuestro equipo pudo determinar cuál era el objetivo de esta campaña. En rápida sucesión, se utilizó el webshell para comprobar:

• La ubicación y el tipo del binario «sendmail» del sistema
• Ya sea que PHP… mail() la función estaba disponible
• Ya sea que proc_open() estaba disponible
• El contenido de la lista de funciones desactivadas de PHP
• Si se podía acceder al SMTP saliente en el puerto 25
• Resolución de registros DNS y MX
• Si el entorno de correo se comportaba como una configuración de «trap», «discard» o «blackhole»

Esa última comprobación es la más interesante. El atacante estaba comprobando específicamente si el correo saliente se entregaba realmente o si el servidor lo retenía sin avisar. Se trata de un reconocimiento de la infraestructura de spam. A partir de las pruebas que hemos revisado, no se ha confirmado ninguna campaña de correo saliente que haya tenido éxito, pero la intención no deja lugar a dudas.

La segunda página apuntaba en otra dirección. Tenía programas de «cloaking» para SEO que mostraban contenido diferente según el User-Agent, la página de referencia, el idioma, la dirección IP, el servidor y la URI de la solicitud, y permitían reescribir robots.txt. Eso es lo que se conoce como «manipulación de resultados de búsqueda», que es una forma de monetización distinta del reenvío de spam. Los sitios WordPress que han sido pirateados suelen reutilizarse para redirecciones, scripts inyectados y robo de credenciales dirigidos a los visitantes, y no solo para lo que el atacante quiera del propio servidor.

La persistencia se ha desarrollado en nueve capas independientes

Noventa segundos después de conseguir acceso de comando, el atacante del primer sitio creó una tarea programada de cron que se ejecutaba cada cinco minutos. Su objetivo era restaurar un archivo de plugin malicioso a partir de una copia de seguridad guardada en el directorio «uploads» en caso de que el archivo principal desapareciera.

Esa era la primera de las nueve capas. El conjunto completo, recuperado durante la investigación:

• Varias cuentas de administrador creadas por el atacante, desde distintas direcciones IP a lo largo de los días siguientes
• Plugins estándar maliciosos, tres directorios adicionales además del original, cada uno con webshells que funcionan
• Un plugin imprescindible, «Guardian», que te permite recuperar archivos borrados y que no se puede desactivar desde el panel de control de WordPress
• PHP copia en wp-content/uploads, con nombres que se asemejan a los de los archivos de clases principales de « WordPress »
• Cargas útiles codificadas en la tabla de opciones, almacenadas con nombres que imitan los archivos transitorios legítimos de estado del sitio
• Bloques de carga inyectados en wp-config.php, que leía esas opciones de la base de datos, descodificaba el código PHP almacenado y escribía archivos ejecutables en el disco
• Archivos ejecutables en el directorio temporal CageFS de la cuenta, cinco en total
• Tareas cron adicionales: cinco entradas independientes de 30 minutos cada una para realizar autocomprobaciones y comprobaciones de restauración
• Lógica para recrear la cuenta de administrador preferida del atacante y destruir los tokens de sesión de los demás usuarios

Vuelve a leer esa lista pensando en la limpieza. Si eliminas el plugin, queda la tarea de cron. Si eliminas la tarea de cron, queda el contenido de la base de datos. Si eliminas el contenido de la base de datos, queda el wp-config.php un cargador que lo volviera a crear. Al eliminar la cuenta de administrador, se mantiene el webshell que lo creó.

Solo dos de esas nueve capas se encuentran en los lugares donde busca un escáner de malware convencional. Para encontrar el resto, hubo que leer la lógica de la carga útil descodificada y relacionarla con el crontab y la tabla de opciones.

La segunda página web añadió una variante que vale la pena conocer: un plugin imprescindible camuflado como un componente de limitación de intentos de inicio de sesión que se integraba en wp_authenticate, capturaba el nombre de usuario y la contraseña en texto plano de cada intento de inicio de sesión, determinaba su dirección de destino mediante un contrato inteligente de blockchain en lugar de un dominio predefinido y transmitía las credenciales a un punto final remoto. Además, se eliminaba a sí mismo de la lista de plugins imprescindibles para que no apareciera en el panel de control.

Cualquier contraseña que se haya introducido en ese formulario de inicio de sesión mientras el archivo estaba activo está comprometida. No se ha cifrado. No se ha adivinado. Se ha leído sin cifrar.

Los seis días entre la limpieza y la reinfección

El 20 de julio, una actividad procedente de una dirección IP diferente borró todas las cuentas de administrador creadas por los atacantes en el primer sitio. Las cuatro. Ese mismo día se actualizó el núcleo de WordPress a una versión parcheada.

Parece que la limpieza ha sido todo un éxito. Las cuentas no autorizadas han desaparecido, se ha solucionado la vulnerabilidad y la web vuelve a funcionar con normalidad.

El webshell original nunca se eliminó.

El 26 de julio, una dirección IP que no se había visto antes solicitó ese archivo de plugin que aún estaba ahí. El atacante lo usó para escribir un script auxiliar temporal en PHP, que cargó el entorno WordPress , localizó el webshell existente, lo copió en el directorio «uploads», creó un plugin de protección imprescindible, comprobó si la cuenta de administrador preferida del atacante seguía existiendo, la recreó, destruyó los tokens de sesión de otros usuarios y se borró a sí mismo.

WordPress Lo interpretó como el registro de un nuevo usuario. Pero no era un registro. Era PHP ejecutándose con todos los privilegios de la aplicación, haciendo exactamente lo que el propio código de la web está autorizado a hacer.

La página web se ha renovado por completo. La actualización del núcleo del 20 de julio cerró la puerta de seguridad que el atacante había utilizado el 18 de julio, aunque para entonces ya había dejado de usarla.

Las copias de seguridad ya estaban comprometidas

Recuperar los datos a partir de una copia de seguridad es lo primero que se te ocurre cuando hay un problema de seguridad. Ambas investigaciones revelaron que esa reacción habría fallado.

Una cuenta contenía un archivo de puerta trasera que procedía de un proveedor de alojamiento anterior. Estaba presente en una copia de seguridad de migración importada a la cuenta, con marcas de tiempo de modificación de agosto de 2025 y una segunda copia a nivel de cuenta de octubre de 2025. Ese malware es anterior en unos once meses al historial de la cuenta en nuestra infraestructura, y se detectó porque la investigación analizó los árboles de copias de seguridad importadas en lugar de limitarse únicamente a la raíz de documentos activa.

Las pruebas disponibles no demuestran si la campaña de julio de 2026 volvió a usar ese punto de apoyo anterior, y nosotros tampoco dimos por hecho que lo hiciera. Lo que sí queda claro es que el archivo de copia de seguridad no estaba limpio, y que no lo había estado desde antes de que se creara la web.

Los datos de restauración del plugin de mantenimiento de esa misma cuenta contenían un directorio del plugin con un nombre aleatorio que albergaba código correspondiente al periodo del ataque. El material de restauración no se podía usar como fuente de restauración limpia. Lo que permitió detectarlo fue revisar el árbol de restauración, en lugar de confiar ciegamente en él.

Los puntos de restauración recogen todo lo que había en la página en ese momento, incluso lo que ya estaba oculto allí. Restaurar a una fecha anterior a la de la intrusión conocida es una suposición sobre cuándo empezó la intrusión, y en ambos casos esa suposición habría sido errónea.

Las actualizaciones automáticas no llegaron a uno de estos sitios

WordPress.org impuso actualizaciones automáticas para esta versión, una medida que solo se aplica en el caso de fallos muy graves. El primer sitio web seguía utilizando una versión vulnerable 28 horas después.

Durante la reparación, nuestro equipo encontró un plugin de gestión de actualizaciones configurado para bloquear las actualizaciones del núcleo, de los plugins y de los temas, y lo desactivó. Esa configuración es una explicación plausible de por qué no se aplicó la actualización de emergencia, aunque los registros de actualización no eran lo bastante concluyentes como para afirmarlo con certeza.

Para las agencias, este es el hallazgo más útil desde el punto de vista operativo de toda la investigación. Bloquear las actualizaciones es una opción normal y justificable en una web en la que una versión de Core ya ha fastidiado alguna vez el proceso de pago. También es una decisión que, sin que nadie se dé cuenta, excluye a la web de las actualizaciones de seguridad de emergencia, y nadie vuelve a revisarla. Si tu sistema de mantenimiento incluye un gestor de actualizaciones, alguien tiene que hacerse cargo de la cuestión de qué pasa cuando WordPress lanza una actualización de seguridad obligatoria.

Cómo comprobar si tus propios sitios web presentan estos indicadores

Las rutas que aparecen a continuación se refieren a la raíz de documentos de WordPress . Ninguna de ellas requiere un acceso al servidor más allá del que ofrece una cuenta normal de cPanel o SFTP. Los nombres de los archivos de las campañas cambian, así que considera que estos patrones son más duraderos que cualquier nombre de archivo concreto.

Nombres de los directorios de plugins y temas

Ambas cuentas tenían directorios que seguían estas convenciones de nomenclatura en wp-content/plugins:

Patrón	Cómo se ve
wp2shell_*	Se han añadido 8 caracteres hexadecimales, que coinciden con el nombre público de la cadena de exploits
wp2up_*, nx_up_*, h2ok_up_*	Programas independientes para subir archivos, con 8 caracteres hexadecimales añadidos
galex_*	Paquetes de webshell, con 8 caracteres hexadecimales añadidos
Un nombre creíble más un sufijo hexadecimal	Un nombre de plugin que parece legítimo, con una cadena hexadecimal aleatoria añadida al final

Ese último patrón es el que se te escapa en un vistazo rápido. Un plugin malicioso usaba un «slug» que se parecía al de una herramienta de distribución de contenidos y aparecía en el panel de control como «Security Headers Manager 2.1.4», con número de versión y todo. Los directorios de temas con nombres aleatorios se usaban de la misma manera.

Plugins imprescindibles

Archivos en wp-content/mu-plugins No aparecen en la lista habitual de plugins y no se pueden desactivar desde el panel de control. Entre los archivos maliciosos que se encontraron allí había un programa para robar credenciales cuyo nombre se parecía al de un componente de limitación de inicios de sesión, un «guardián de recuperación» cuyo nombre se parecía al de una herramienta de reparación de sitios web, y un par de archivos PHP cortos que cargaban una carga útil comprimida desde un archivo adjunto .gz archivo.

Abre ese directorio y revisa todos los archivos que hay en él por su nombre. En la mayoría de las páginas, la lista debería ser corta o estar vacía.

Archivos camuflados como clases principales de « WordPress »

Los archivos auxiliares se guardaron en los directorios de los complementos con nombres que siguen las convenciones del núcleo:

• class-wp-rest-compat-*.php
• class-wp-http-compat-*.php
• class-wp-cache-helper-*.php
• class-wp-widget-core-*.php

Los cargadores ocultos usaban un punto al principio, seguido de doce caracteres hexadecimales y un .php extensión. Los archivos que sigan estos patrones no forman parte de WordPress y no deben ir en un directorio de plugins. Un poliglota de JPEG y PHP llamado 1.php también aparecía en una cuenta, junto con una puerta trasera más antigua llamada wp-mytrack.php que crea una cuenta de administrador cuando se ejecuta.

Indicadores de la base de datos

Las cargas maliciosas se almacenaban en la tabla de opciones con nombres diseñados para aparecer junto a las entradas legítimas sobre el estado del sitio, utilizando el prefijo _site_transient_health_ seguido de 8 caracteres hexadecimales. Tu prefijo de tabla será diferente del predeterminado. « WordPress » sí que crea transientes reales de estado del sitio, así que busca la cadena hexadecimal final en lugar de solo el prefijo.

Indicadores de configuración

Bloques etiquetados WP_Core_Integrity se inyectaron en wp-config.php. Su función era leer los datos de la base de datos mencionados anteriormente, descodificarlos y guardar código PHP ejecutable en el directorio temporal de la cuenta. Abrir wp-config.php y léetelo de principio a fin. Todo lo que venga después del comentario «fin de la edición» merece tu atención.

Entre las cadenas de código recurrentes que se observaron en las cargas útiles se encontraban: _nx_auth, _NX_PERSISTEDy feature=selftest.

Cargas útiles en directorios temporales

Se encontraron cinco cargas ejecutables en el directorio temporal de una cuenta, siguiendo la convención de nomenclatura de archivos temporales propia de PHP: los caracteres php seguido de seis caracteres alfanuméricos aleatorios. Es el mismo patrón que usa PHP para las subidas de archivos normales, y precisamente por eso pasaba desapercibido. Los archivos temporales normales de subida se borran cuando termina la solicitud. Cualquier archivo que coincida con ese patrón y que lleve días ahí merece la pena investigarlo.

Entradas de Cron

Comprueba el crontab de la cuenta, no solo el cron de WordPress . Una cuenta tenía una tarea de cinco minutos que restauraba un archivo de plugin borrado desde una copia de seguridad en la carpeta «uploads», además de cinco tareas independientes de treinta minutos cada una que realizaban autocomprobaciones. Una entrada legítima en el cron de WordPress llama a wp-cron.php y nada más. Cualquier otra llamada recurrente a PHP o curl en tu propia web debe tenerse en cuenta.

Cuentas de usuario y tokens

• ID de administrador secuenciales. Una cuenta tenía 38 administradores no autorizados en un bloque continuo de ID de usuario. La creación secuencial es un indicio estructural.
• Patrones de nombres de usuario. Entre los prefijos observados se encontraban wpsvc_ y wp2_ seguidas de un código hexadecimal, además de cuentas creadas a partir del nombre del sitio con sufijos como _dev, _editory _suporte.
• Contraseñas de las aplicaciones. Ve a «Usuarios», luego a cada perfil y, a continuación, a «Contraseñas de aplicaciones». Los tokens creados por el atacante tenían nombres como, por ejemplo: auto-bootstrap y bot-token. Estas se mantienen aunque cambies la contraseña y no necesitas el formulario de inicio de sesión.

Firmas de registro

En los registros de acceso, busca las solicitudes POST dirigidas a /?rest_route=/batch/v1 o /wp-json/batch/v1 que devolvían el código HTTP 207, sobre todo en ráfagas. En una de las cuentas, las peticiones incluían las cadenas «User-Agent» wp2shell y wp2shell-uploader. Lo que tienes que buscar es que se cree un administrador a los pocos segundos de que se produzca ese pico de actividad.

Ambas cuentas mostraban el mismo patrón: una rápida sucesión de solicitudes por lotes, seguida de una solicitud para wp-login.php, luego un inicio de sesión correcto, y después subir un plugin a través de update.php con el action=upload-plugin parámetro. Esa subida es una acción normal de un administrador de WordPress y, por sí sola, no parecerá nada rara. Lo que sí resulta raro es que se produzca justo después de una ráfaga de solicitudes por lotes procedentes de la misma IP.

Ten en cuenta que las cadenas de User-Agent se modifican fácilmente y es posible que las variantes posteriores ya no las utilicen. Las solicitudes de ruta por lotes que devuelven un código HTTP 207 son la señal más fiable. Si tu servidor rota o comprime los registros de acceso con frecuencia, recupera los registros archivados correspondientes a mediados y finales de julio de 2026 antes de que caduquen.

Comprobación de la respuesta del servidor para las subidas

Solicita un archivo PHP en wp-content/uploads directamente, sin caché, y comprueba la respuesta. El código HTTP 403 es correcto. Se devuelve un código HTTP 200 con content-type: application/octet-stream significa que el archivo se está mostrando como código fuente legible en lugar de ejecutarse.

El modo «Serving» es el más seguro de los dos modos de fallo, ya que el código no se ejecuta, pero sigue exponiendo el contenido de ese archivo a cualquiera que solicite la URL. Ambas cuentas necesitaban una regla de denegación explícita que cubriera las extensiones ejecutables en la carpeta «uploads», y ambas la recibieron. Lo detectamos haciendo pruebas desde fuera del servidor con peticiones que anularan la caché, usando un User-Agent de navegador normal, Googlebot y otros, porque algunas configuraciones responden de forma diferente según el cliente. Si hubiéramos hecho las pruebas solo con un navegador, no lo habríamos detectado.

Valores de endurecimiento que hay que confirmar

• wp-config.php permisos configurados en 0600
• Cualquier archivo PHP válido de la carpeta «uploads» con permisos de 0600
• DISALLOW_FILE_EDIT y DISALLOW_FILE_MODS se define como verdad
• FORCE_SSL_ADMIN se define como verdad
• Que no haya archivos en los que todos puedan escribir, ni archivos que pertenezcan a otra cuenta, ni enlaces simbólicos inesperados en la raíz de documentos

En qué consiste realmente una limpieza certificada

La corrección en ambos casos siguió la misma estructura. Así es como funciona el proceso, y es un punto de referencia razonable para evaluar cualquier corrección, ya sea que la hagas tú mismo o que la haga un proveedor.

Lo primero es contenerlo. Durante la investigación, se bloqueó el primer sitio con un error HTTP 403. Limpiar un sitio al que todavía se puede acceder significa ir a contrarreloj contra los mecanismos de restauración que se activan cada cinco minutos.

Guárdalo antes de borrarlo. Todos los archivos maliciosos, la carga útil de las bases de datos, los registros de usuarios, las entradas de crontab y los archivos de configuración se han archivado y se les ha aplicado un hash antes de eliminarlos. Si borras el malware sin guardarlo primero, ya no podrás responder a preguntas más adelante, como por ejemplo si la limpieza ha funcionado.

Quita todas las capas y, a continuación, comprueba cada una por separado. Sistema de archivos, opciones de la base de datos, wp-config.php Las inyecciones, las entradas de cron, los directorios temporales, los plugins imprescindibles, las subidas de archivos y los registros de usuarios se revisaron uno por uno y se verificaron por separado.

Comprueba la integridad del Core y de los paquetes comparándolos con las sumas de comprobación oficiales. En ambos sitios se verificó el Core. En el primero, se investigó una discrepancia en la suma de comprobación de un plugin y se reinstaló el plugin desde un paquete de confianza; además, se sustituyeron dos temas con archivos modificados por paquetes oficiales, en lugar de aplicarles parches directamente.

Gira todo lo que el atacante pudiera leer. Al poder ejecutar comandos PHP y acceder a la base de datos, el atacante podría leer wp-config.php, la tabla de opciones y cualquier credencial almacenada en cualquiera de ellas. Eso incluye WordPress contraseñas de administrador, cPanel, FTP y SFTP, SSH, bases de datos, SMTP, claves de procesadores de pago y todos los tokens de API de terceros que tenga el sitio. Ambos informes indicaban que la rotación era obligatoria, no solo recomendada.

Reduce y confirma la lista de administradores. En una de las páginas web se pasó de 38 administradores no autorizados a tres cuentas que ya existían. El propietario de la página tiene que confirmar, por su nombre, que cada una de las cuentas restantes está autorizada.

Elimina las sesiones y las contraseñas de las aplicaciones. Las contraseñas de la aplicación WordPress creadas por los atacantes, con nombres que sugieren que son tokens de automatización, permitían acceder con autenticación sin tener que pasar por el formulario de inicio de sesión. La mayoría de los propietarios de sitios web nunca han abierto esa pantalla en su perfil. Y esta contraseña se mantiene incluso después de cambiarla.

Establece una referencia después. La referencia posterior a la remediación del primer sitio registraba hash de más de 36 000 archivos ejecutables y de configuración. Sin una referencia válida, la siguiente investigación vuelve a empezar desde cero.

Lo que las agencias y los desarrolladores deberían cambiar esta semana

Tres medidas concretas, ordenadas según el grado de reducción del riesgo que suponen:

Comprueba la versión instalada de « WordPress » en cada uno de los sitios que gestionas, uno por uno. No te fíes del panel de actualizaciones y no des por hecho que la actualización forzada se haya aplicado. Los investigadores de seguridad han señalado en repetidas ocasiones que los sitios en los que las actualizaciones automáticas estaban desactivadas o no se habían realizado correctamente pueden seguir estando expuestos. Comprueba la cadena de versión y, a continuación, comprueba si hay algún elemento de la pila de plugins configurado para bloquear las actualizaciones.

Revisa las cuentas de administrador y las contraseñas de las aplicaciones a la vez. Un administrador malintencionado se nota fácilmente. Una contraseña de aplicación vinculada a una cuenta legítima no se nota, y es el mecanismo que más probabilidades tiene de pasar desapercibido en una limpieza hecha a toda prisa. Revisa ambas cosas en cada sitio y, después, echa un vistazo al directorio de plugins imprescindibles, que no aparece en absoluto en la lista normal de plugins.

Trata cualquier violación de seguridad confirmada como un caso de rotación completa de credenciales. Si un atacante ha conseguido ejecutar código PHP en la cuenta, todos los secretos a los que se pueda acceder desde esa cuenta quedan expuestos. Una rotación parcial deja una clave que sigue funcionando.

La reinfección es el resultado normal de una limpieza parcial, no algo inusual. El intervalo en el primer sitio fue de seis días, y durante esos seis días el sitio parecía limpio, funcionaba con normalidad y superó una inspección superficial.

Lo que realmente supone este tipo de investigación

Ambas investigaciones las llevaron a cabo los propios equipos de InMotion Hosting, utilizando la infraestructura que tenemos y gestionamos en tres regiones de centros de datos. No se subcontrató nada a ningún proveedor de análisis, ni se cedió ninguna parte del análisis a terceros.

Esto es importante por el lugar donde se ocultaba el malware. Un escáner de malware comercial detecta archivos, pero no descifra las cargas útiles almacenadas en la tabla de opciones bajo nombres que imitan a los datos transitorios legítimos del estado del sitio. Tampoco rastrea los bloques de carga inyectados en wp-config.php a los archivos ejecutables que vuelven a compilar en el directorio temporal de la cuenta. No se da cuenta de que cinco archivos que siguen la convención de nomenclatura habitual de PHP para archivos subidos deberían haberse eliminado al final de una solicitud hace tres semanas y no se han eliminado.

Esos hallazgos se obtuvieron tras analizar el código y cruzar las marcas de tiempo de los registros de acceso archivados, los registros de actividad de « WordPress » y el crontab de la cuenta. Todos los ingenieros de nuestros equipos de soporte completan más de 280 horas de formación antes de atender solicitudes de nivel 1, y la antigüedad media en el equipo de soporte supera los cinco años. Estos mismos equipos están disponibles las 24 horas del día, los 7 días de la semana, y las investigaciones en las que se basa este artículo las llevaron a cabo personas con las que puedes contactar por teléfono.

Esto también concuerda con cómo gestionamos las amenazas en la capa de infraestructura. Cuando en abril de 2026 se reveló una vulnerabilidad crítica previa a la autenticación en cPanel y WHM, nuestro equipo de operaciones de red bloqueó la exposición en el perímetro de la red en las tres regiones de centros de datos en cuestión de horas y, a continuación, aplicó los parches a los servidores uno por uno. WordPress Las actualizaciones del núcleo se instalan dentro de tu aplicación en lugar de en la pila del servidor, por lo que una vulneración como esta requiere una respuesta diferente y un tipo de investigación distinto.

Si gestionas sitios web de WordPress para clientes y no estás seguro de que una limpieza anterior se haya hecho a fondo, esa incertidumbre es la clave. Tráenos la cuenta y revisaremos cada capa, no solo el sistema de archivos.

Habla con nuestro equipo o echa un vistazo a nuestros servicios de alojamiento gestionado.