El 17 de julio de 2026, WordPress publicaba un advisory de seguridad. Solo un commit en GitHub y un CVE en la base de datos de NVD: CVE-2026-63030, bautizado wp2shell por sus descubridores de Searchlight Cyber.

El 18 de julio, menos de 24 horas después, los primeros exploits públicos aparecían en GitHub.

72 horas entre el parche y el exploit funcional. Eso es lo que teníamos para actualizar los sitios de clientes (y propios) que gestionamos, como mi propio blog.

Qué es wp2shell (y por qué no es un exploit cualquiera)

wp2shell no es un plugin mal mantenido ni una configuración insegura. Es código del núcleo de WordPress, del core que actualizas cada tres meses sin pensártelo muchas veces.

La cadena de ataque combina dos vulnerabilidades, como explican tanto The Hacker News como el advisory oficial en GitHub (GHSA-ff9f-jf42-662q):

1. CVE-2026-63030: Confusión de rutas en el endpoint REST API /wp-json/batch/v1. El endpoint batch procesa varias subpeticiones en una sola llamada y mantiene dos arrays paralelos ($validation[] y $matches[]); un error WP_Error en una subpetición desplaza los arrays una posición, haciendo que una petición se ejecute bajo el handler de otra.
2. CVE-2026-60137: Inyección SQL en el parámetro author__not_in de WP_Query. Afecta a WordPress 6.8 y superiores.

Juntas, permiten ejecución de código remoto sin autenticación. Sin plugin. Sin usuario. Sin interacción. Solo una petición HTTP a un WordPress vulnerable. Tal como describe Rapid7 en su análisis, el atacante puede extraer hashes de contraseñas vía SQLi, crackear una cuenta de administrador, subir un plugin malicioso y ejecutar comandos.

La superficie de ataque es brutal: WordPress alimenta más de 500 millones de sitios web. Y el vector es el núcleo, no una extensión de terceros.

Nuestra cronología

Esto es lo que registraron nuestros logs durante esas primeras 72 horas:

Fecha	Hora (UTC)	Evento
17/jul	—	WordPress publica 6.9.5 y 7.0.2
18/jul	12:00	Primera petición masiva al endpoint /batch/v1.
19/jul	01:45	Intento explícito con user-agent «wp2shell» (sitio aún sin parchear).
19/jul	11:50	Revisión manual en todos los sitios tras la actualización automática.
19/jul	17:10	Nuevo intento con UA «wp2shell» (ya parcheado).
20/jul	03:15	Último intento registrado.

Durante la ventana de exposición (18-19/jul), registramos 15 IPs distintas intentando explotar el endpoint. No es un atacante dirigido: es escaneo automatizado masivo, exactamente el patrón que Rapid7 documenta en su reporte del 20 de julio, y que BleepingComputer atribuye a la publicación del PoC público.

El intento de las 01:47 del 19 de julio ocurrió antes de que parcheáramos (o se lanzase la actualización actuomática desde WordPress.org). Ese es el momento crítico.

¿Compromiso confirmado?

En nuestro caso: no.

• Checksums del núcleo: correctos
• Ficheros creados/modificados: ninguno
• Webshells: no detectadas
• Usuarios administradores nuevos: ninguno
• mu-plugins sospechosos: ninguno

Lo que no podemos descartar al 100%: que la inyección SQL (CVE-2026-60137) haya exfiltrado datos sin dejar rastro en disco. Como explica Penligent en su análisis técnico, la cadena SQLi puede extraer hashes de contraseñas de la base de datos sin tocar el sistema de ficheros. Por eso nuestra recomendación tras el incidente fue rotar contraseñas de administrador y SECRET_KEYS/SALTS, aunque no hubiera evidencia de shell.

Por qué el mantenimiento importa (y por qué importa ahora)

Aquí es donde quiero que nos fijemos.

El exploit público existía a las 18 horas del parche. Si hubiéramos esperado al ciclo de actualizaciones semanal (o al típico «parcheamos el primer martes de cada mes») habríamos estado expuestos durante todo el escaneo automatizado.

Nosotros tenemos actualizaciones menores de WordPress automáticas por defecto en todos los sitios. Pero además, el sábado por la mañana revisamos manualmente todos los sitios: verificamos versiones, comprobamos logs, confirmamos que no había alertas pendientes.

El mantenimiento no es solo «tener las versiones al día». Es:

• Monitorización activa de advisories de seguridad (no esperar a que te llegue el email).
• Tiempo de respuesta medido en horas, no en días.
• Verificación post-parche de que todo sigue funcionando y no hay indicadores de compromiso.
• Rotación de credenciales cuando el vector SQLi ha podido exfiltrar hashes.

Como recomienda Nebula Design en su writeup, la mayoría de compromisos explotan vulnerabilidades que fueron parcheadas semanas o meses antes. wp2shell es el caso opuesto: aquí la ventana fue de horas.

IOCs para los que estén auditando

• Endpoints objetivo: /wp-json/batch/v1 y ?rest_route=/batch/v1.
• User-agent: wp2shell (bloqueo directo si aparece).

Si quieres comprobar si tu instalación es vulnerable, Searchlight Cyber ofrece un checker en wp2shell.com.

Conclusión

wp2shell es un recordatorio de que las vulnerabilidades en el núcleo de WordPress son el escenario de peor caso: no dependen de tu plugin de contacto, no dependen de tu contraseña de admin. Dependen de una actualización que llegó un viernes por la tarde y que, si no la aplicas en 24 horas, te pone en la mira de todo Internet automatizado.

El mantenimiento no es un coste. Es tu primera línea de defensa.