Introducción

wp2shell es una cadena de ejecución remota de código (RCE) sin autenticación en WordPress Core, divulgada en julio de 2026 por Searchlight Cyber y asignada como CVE-2026-63030 y CVE-2026-60137. Explota el endpoint batch de la REST API de WordPress (/wp-json/batch/v1) para inyectar SQL, sin requerir autenticación, sin requerir plugins. Desde ahí, los atacantes escalan a acceso de administrador, instalan webshells, suben plugins maliciosos y crean cuentas admin fraudulentas. Los proof-of-concept públicos aparecieron horas después de la divulgación.

Pero wp2shell no es la única amenaza para un sitio de WordPress desactualizado. Es simplemente la más reciente en una larga lista de vulnerabilidades que afectan instalaciones olvidadas. Cuando un sitio corre una versión de core varias versiones mayores atrás, la superficie de ataque es enorme. Este es el relato de un caso real donde un cliente nos llamó porque su sitio de WordPress se estaba comportando de forma extraña. Lo que encontramos fue un servidor comprometido con webshells, administradores fantasma y todos los indicadores de un ataque estilo wp2shell.

La llamada

El cliente nos contactó un lunes por la mañana. Venía notando problemas desde hacía unos días, pero finalmente decidió que algo andaba mal cuando su proveedor de hosting le marcó un volumen de tráfico inusual.

Los síntomas eran de manual para una instalación de WordPress comprometida:

Picos de actividad en el servidor: El uso de CPU y memoria estaba consistentemente alto, con ráfagas periódicas que no correlacionaban con tráfico legítimo.
Archivos nuevos apareciendo: Archivos PHP que nadie había visto antes surgían en wp-content/cache/ y otros directorios.
Usuarios admin fantasma: Se habían creado nuevas cuentas de administrador con nombres aleatorios en la base de datos de WordPress.
Consultas a la API de WordPress: Los logs de acceso mostraban peticiones repetidas a /wp-json/batch/v1 y /wp-json/wp/v2/users, consistentes con la cadena de exploit wp2shell y la enumeración post-explotación.
Logs extraños: Había peticiones con User-Agent: cve-2026-63030/1.0 y marcadores similares en los logs del servidor.

El cliente no sabía qué era wp2shell. Solo sabía que su sitio estaba roto y que algo andaba mal.

Contención

La primera regla de respuesta a incidentes es simple: no toques el servidor comprometido en vivo. Cualquier acción en el entorno de producción puede destruir evidencia forense, detonar un payload destructivo, o alertar al atacante de que estás investigando.

Descargamos el sitio completo, archivos y base de datos, a un entorno aislado sin acceso a internet. Esto implicó:

Copia del filesystem: Una copia recursiva completa del web root, incluyendo todos los subdirectorios de wp-content/, plugins, temas, uploads y directorios de cache.
Dump de la base de datos: Un mysqldump completo de la base de datos de WordPress, incluyendo la tabla wp_users (donde vivían los admins fantasma) y la tabla wp_options (donde suelen esconderse mecanismos de persistencia).
Preservación de logs: Logs de acceso, logs de error y logs de error de PHP del servidor.
Aislamiento de red: El entorno copiado se colocó en una máquina sin acceso a red. Sin conexiones salientes, sin conexiones entrantes. Si el código malicioso intentaba llamar a casa, fallaba silenciosamente.

Esta copia aislada se convirtió en nuestro laboratorio forense. El servidor de producción se dejó corriendo pero monitoreado, para que el atacante no notara actividad inmediatamente y disparara una respuesta destructiva.

Diagnóstico

Una vez que el sitio estuvo en el laboratorio, comenzamos el análisis sistemático.

Versión de WordPress Core: El sitio corría WordPress 5.x. No 5.9, no 5.8. Versión 5, y nada más. Estaba varias versiones mayores atrás de la versión actual. La última actualización de seguridad para la rama 5 de WordPress fue hace años. Cualquier vulnerabilidad divulgada desde entonces era potencialmente explotable en este sitio.

Auditoría de plugins: La mayoría de plugins instalados estaban igual de desactualizados. Algunos tenían vulnerabilidades conocidas. Unos cuantos habían sido abandonados por sus desarrolladores.

Escaneo del filesystem: Comparamos cada archivo de la instalación contra una lista de checksums de un WordPress core limpio y conocido. Cualquier archivo que no correspondiera se marcó para revisión. Los resultados fueron contundentes:

Webshells en wp-content/cache/: Múltiples archivos PHP con nombres aleatorios (por ejemplo, 94uh9ubh6e1x.php) fueron encontrados en el directorio de cache. Eran webshells clásicos estilo wp2shell: devolvían una página 404 falsa a menos que se accediera con el parámetro de contraseña correcto, y luego ejecutaban comandos arbitrarios vía system(), passthru(), exec(), shell_exec(), popen() o ejecución con backticks.
Plugins maliciosos: Varios directorios de plugins bajo wp-content/plugins/ no correspondían a ningún plugin legítimo del repositorio de WordPress. Contenían archivos PHP que registraban endpoints de la REST API para ejecución remota de comandos.
Archivos core modificados: Dos archivos del core habían sido modificados para incluir includes de PHP adicionales que cargaban payloads externos.
Admins fantasma: La tabla wp_users contenía tres cuentas de administrador con nombres de usuario aleatorios que el cliente nunca había creado.

Análisis de logs de acceso: Los logs confirmaron la cadena de ataque. Podíamos ver las peticiones iniciales de probing a /?rest_route=/batch/v1 con payloads de inyección SQL en los parámetros, seguidas por la creación de los archivos webshell y las cuentas de administrador fantasma.

Remediación

Con un panorama claro de la intrusión, procedimos a limpiar y reconstruir.

Paso 1: Eliminar archivos maliciosos. Todos los archivos marcados durante el escaneo se eliminaron de la copia aislada. Esto incluyó los webshells en el directorio de cache, los plugins maliciosos y los archivos core modificados. No intentamos "limpiar" archivos individuales. Cualquier cosa que no fuera parte de una instalación legítima de WordPress o un plugin verificado se eliminó.

Paso 2: Eliminar admins fantasma. Las tres cuentas de administrador no autorizadas se eliminaron de la tabla wp_users. También revisamos wp_usermeta buscando hooks de persistencia que pudieran haber dejado.

Paso 3: Actualizar WordPress Core. Como el sitio corría versión 5, una actualización directa a la última versión no era posible por el actualizador integrado. Hicimos un reemplazo limpio del core: descargamos la última versión de WordPress, reemplazamos todos los archivos core y ejecutamos la rutina de actualización de base de datos. El esquema de base de datos necesitaba migrar a través de varias versiones mayores.

Paso 4: Actualizar todos los plugins. Cada plugin se actualizó a su última versión. Los plugins abandonados que no tenían actualizaciones recientes se eliminaron por completo y se reemplazaron con alternativas mantenidas activamente donde la funcionalidad fuera necesaria.

Paso 5: Reparar el frontend. El tema había sido modificado durante la intrusión. Restauramos los archivos originales del tema desde el backup de control de versiones del cliente y reaplicamos sus personalizaciones sobre la base limpia del tema. Se repararon layouts rotos y assets faltantes.

Paso 6: Redesplegar. El sitio limpio, actualizado y verificado se desplegó al servidor de producción. Reemplazamos todos los archivos en el servidor con las copias limpias del laboratorio, importamos la base de datos limpia y verificamos que el sitio funcionara correctamente.

Hardening

La remediación sin hardening es solo una invitación para el próximo ataque. Implementamos varias capas de protección para prevenir reincidencias.

Herramientas de seguridad a nivel servidor: Instalamos monitoreo de integridad de archivos (FIM) para alertar sobre cambios no autorizados, y un firewall de aplicación web (WAF) configurado con reglas para bloquear patrones de ataque conocidos, incluyendo peticiones sospechosas al endpoint batch de la REST API.

Políticas de actualización: Configuramos actualizaciones automáticas de versiones menores para WordPress Core y monitoreo para actualizaciones de plugins. El cliente ahora recibe un reporte mensual listando todas las actualizaciones disponibles y su prioridad.

Controles de acceso: Las cuentas de administrador se auditaron y se redujeron al mínimo necesario. Se forzó la autenticación de dos factores para todas las cuentas admin. El archivo wp-config.php se aseguró con permisos de filesystem apropiados.

Monitoreo: Configuramos monitoreo de logs con alertas para los indicadores de compromiso (IOCs) específicos de la campaña wp2shell, incluyendo peticiones a /batch/v1 con patrones de inyección SQL, creación de nuevos archivos en wp-content/cache/ y creación de nuevas cuentas de administrador.

Backups: Se configuraron backups automáticos diarios con almacenamiento off-site y pruebas periódicas de restauración. Si el sitio se vuelve a comprometer, se puede restaurar rápidamente desde un backup conocido y limpio.

Lecciones aprendidas

Este caso reforzó varios principios que todo equipo de ingeniería y CTO debería interiorizar.

WordPress desactualizado es el riesgo número uno de seguridad. WordPress alimenta más de 500 millones de sitios. Su superficie de ataque está bien documentada y es escaneada activamente por investigadores y atacantes. Correr una versión varias versiones mayores atrás significa que estás expuesto a cada vulnerabilidad divulgada desde tu última actualización. En este caso, el cliente estaba en WordPress 5, una versión que no ha recibido parches de seguridad en años. El sitio era un blanco sentado.

Las actualizaciones no son opcionales. La vulnerabilidad wp2shell se divulgó el 17 de julio de 2026. Los proof-of-concept públicos aparecieron en horas. La explotación activa se observó el mismo día. Los sitios que estaban en la última versión parchada no fueron afectados. Los que no, fueron comprometidos en horas. La ventana entre divulgación y explotación se mide en minutos, no en días.

Aislamiento antes de remediación. El instinto de "arreglarlo ya" en el servidor en vivo es comprensible y peligroso. Trabajar en una copia aislada preserva evidencia, evita que el atacante observe tus acciones y te da un entorno seguro para experimentar con fixes sin arriesgar más daño al sitio en producción.

El monitoreo a nivel servidor importa. El monitoreo de integridad de archivos y el análisis de logs detectaron los indicadores iniciales de esta intrusión. Si el cliente hubiera tenido estas herramientas instaladas antes del ataque, los webshells y las cuentas admin fantasma se habrían detectado en horas, no en días.

¿Corrés un sitio de WordPress desactualizado? Nuestro equipo puede ayudarte con auditoría y remediación.

Detección y Remediación de wp2shell en WordPress: Un Caso Real