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):
- 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 errorWP_Erroren una subpetición desplaza los arrays una posición, haciendo que una petición se ejecute bajo el handler de otra. - CVE-2026-60137: Inyección SQL en el parámetro
author__not_indeWP_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/v1y?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.
Deja una respuesta