wp2shell: el exploit sin autenticación que lleva semanas comprometiendo sitios WordPress y cómo saber si el tuyo cayó

El 18 de julio llegó el caos tranquilito, sin que casi nadie lo notara. Dos vulnerabilidades en el core de WordPress, encadenadas, le dan a cualquier atacante acceso completo a tu servidor sin usuario, sin contraseña, sin plugin adicional instalado. Solo el WordPress pelón es suficiente para que entren. Y para el 20 de julio ya había explotación masiva confirmada en la naturaleza.

Esto es wp2shell. Si tienes un sitio en WordPress y no has actualizado en las últimas semanas, necesitas leer esto antes de hacer cualquier otra cosa.

Qué es wp2shell y por qué es diferente a todo lo que vino antes

La mayoría de los ataques a WordPress vienen por plugins vulnerables o contraseñas débiles. Este no. Wiz confirmó la explotación activa de wp2shell desde el 18-20 de julio y lo que hace diferente a este exploit es que afecta al core de WordPress sin importar qué plugins tengas instalados.

Son dos CVEs que por separado son manejables. Juntos son devastadores:

CVE-2026-63030 es un fallo lógico en el batch processor de la REST API de WordPress. La ruta /wp-json/batch/v1 permite enviar múltiples solicitudes en un solo request. El problema: la API valida y ejecuta en loops separados. Cuando wp_parse_url() falla en el path de una subrequest, el error se empuja al array de validación pero no al de matches. Los arrays se desincroniza y cada solicitud subsecuente se despacha bajo el handler equivocado.

CVE-2026-60137 es inyección SQL. El parámetro author__not_in se interpola directo en SQL crudo cuando se pasa como string escalar. Normalmente la validación previene esto, pero la desincronización del batch API la bypassa.

El resultado: SQL injection sin autenticación que da acceso administrativo completo. Crear usuarios admin, subir plugins maliciosos, ejecutar código en el servidor. Control total. Rapid7 documentó el exploit completo con toda la cadena técnica y no hay mucho margen de interpretación: es tan grave como suena.

Versiones afectadas: ¿estás en riesgo?

Versión WordPress	Estado
6.8.0 a 6.8.5	Vulnerable (solo SQL injection)
6.9.0 a 6.9.4	Vulnerable (RCE completo)
7.0.0 a 7.0.1	Vulnerable (RCE completo)
6.9.5	Parcheado
7.0.2 o superior	Parcheado

Si tienes cualquier versión entre 6.9.0 y 7.0.1, estás en la zona más crítica. WordPress activó actualizaciones automáticas forzadas, pero no todos los hostings las tienen habilitadas y hay sitios que las tienen desactivadas a propósito por compatibilidad con plugins viejos.

El timeline: de CVE publicado a explotación masiva en 72 horas

• 17 de julio: WordPress Security Team publica las CVEs. Aparecen en NVD. Los POCs empiezan a circular.
• 18-20 de julio: Wiz y CrowdSec detectan los primeros ataques reales. CrowdSec libera regla de detección el día 20.
• 21 de julio: CISA mete wp2shell a su catálogo de Known Exploited Vulnerabilities, confirmando explotación activa a escala global.
• 24 de julio: Deadline federal en EE.UU. para que todas las agencias gubernamentales parchen.

Al momento de publicarse las CVEs, el 60% de las organizaciones que usan WordPress tenían al menos una instancia vulnerable, y el 25% la tenían expuesta directo a internet. En las primeras 24-48 horas posteriores al lanzamiento de parches, se documentó un descenso significativo en instancias vulnerables conforme las organizaciones comenzaron a parchear. Pero “bajó” no significa “resuelto”.

El patrón siempre es el mismo: un CVE crítico se publica, hay POCs disponibles en horas, y los grupos de amenaza escanean internet antes de que la mayoría vea la noticia. Ya lo vimos con el zero-day CVSS 9.8 en FortiClient EMS que se explotó activamente en abril, y el patrón se repite sin excepción.

México y LATAM: los que más sitios tienen, los que menos actualizan

No hay desglose oficial de cuántos sitios mexicanos fueron comprometidos específicamente. Pero los números globales son suficientemente serios y México tiene contexto particular: es el país de LATAM con mayor densidad de sitios WordPress. Miles de PYMEs, restaurantes, despachos, tienditas online, portafolios de freelancers, todas en WordPress porque es lo que el diseñador del sobrino instaló hace tres años.

Ese mismo administrador probablemente no recibió ninguna alerta el 17 de julio. Y si el hosting no tiene auto-updates activados, el sitio sigue vulnerable hoy, el 11 de agosto.

Los atacantes lo saben. Los user agents más comunes en los ataques documentados son literalmente wp2shell y rezwp2shell, tan descarados que ni se molestaron en ofuscar nada.

Qué hicieron los atacantes una vez adentro

Wiz documentó el patrón post-explotación en sitios comprometidos:

1. Subida de plugins maliciosos vía /wp-admin/update.php?action=upload-plugin
2. Enumeración de usuarios por los endpoints de REST API
3. Local file inclusion para robar credenciales de base de datos desde wp-config.php
4. Despliegue de backdoors persistentes, webshells, en la carpeta de uploads

El webshell en uploads es al tiro la señal más fácil de detectar porque PHP no debería existir en una carpeta de imágenes.

Cómo detectar si ya entraron a tu sitio

No esperes a que tu hosting te mande un correo. Esto es lo que tienes que revisar ahorita:

Verifica la integridad del core desde WP-CLI:

wp core verify-checksums

Si hay archivos del core modificados, te lo dice directo.

Busca PHP en la carpeta de uploads:

find /ruta/wp-content/uploads -name "*.php" -o -name "*.php5"

Si hay archivos PHP ahí que tú no pusiste, ya entraron.

Revisa los logs del servidor: Busca requests a /wp-json/batch/v1 o /?rest_route=/batch/v1. Payloads de 10-50 KB en ese endpoint (lo normal es menos de 5 KB) es señal de explotación.

Audita cuentas de administrador: Entra a Usuarios en tu panel y busca admins que no reconoces. Cualquier admin creado entre el 18 y 30 de julio que no seas tú es señal de compromiso.

Plugins recientes no autorizados: Ordena tus plugins por fecha de instalación. Cualquier plugin instalado en ese rango de fechas que tú no hayas instalado es sospechoso.

Qué hacer ahorita mismo

SecurityWeek tiene el resumen completo de los vectores de ataque pero la acción básica es inmediata:

1. Backup primero, siempre: Antes de tocar nada. Si algo truena en la actualización, necesitas el respaldo.
2. Actualiza YA: Dashboard > Actualizaciones. Target: 6.9.5 si estás en la rama 6.x, 7.0.2 si estás en la 7.x. Si tienes 6.8.x, actualiza igual, la SQL injection sola es suficiente para hacer daño.
3. Bloquea el endpoint temporalmente: Si tienes acceso a nginx o Apache, agrega una regla para rechazar requests a /wp-json/batch/v1 desde usuarios no autenticados mientras terminas de parchear.
4. Cambia todas las contraseñas: Base de datos en wp-config.php, credenciales FTP, panel de hosting, y todas las cuentas de WordPress.
5. Si ya encuentras evidencia de compromiso: El parche solo no es suficiente. Tienes que hacer restore desde un backup limpio anterior al 18 de julio y luego parchear. Un sitio comprometido que solo parcheas sigue comprometido si el webshell sigue ahí.

El punto que no se puede ignorar

No es la primera vez que México queda expuesto en un ataque masivo por infraestructura desactualizada. Y como ya vimos cuando cubrimos cómo usaron IA para hackear el SAT, el INE y 7 agencias más con 150 GB de datos robados, el problema no es sofisticación del atacante sino higiene básica del defensor.

Las PYMEs mexicanas en WordPress son objetivo perfecto: sin sysadmin, sin WAF, con hosting barato que no activa updates automáticos. Los atacantes no necesitan ser genios cuando el 25% de los sitios expuestos a internet ni siquiera tienen el parche semanas después de que salió.

La pregunta no es si escanearon sitios WordPress mexicanos entre el 18 y 30 de julio. Lo hicieron. La pregunta es si el tuyo respondió al request de /wp-json/batch/v1.

Checa tu sitio. Ahorita.

Fuentes

• Wiz: Exploitation in the Wild of wp2shell
• Rapid7: CVE-2026-63030 wp2shell Technical Analysis
• SecurityWeek: WP2Shell WordPress Vulnerabilities Exploited in the Wild
• Tenable: wp2shell FAQ
• Picus Security: CVE-2026-63030 y CVE-2026-60137 Explicados
• GitHub Security Advisory: GHSA-ff9f-jf42-662q
• SeguridadenWordPress: wp2shell RCE guía de remediación