El 17 de julio de 2026 WordPress publicó una actualización de seguridad de emergencia para tapar wp2shell, una cadena de dos fallos del propio núcleo (CVE-2026-63030 y CVE-2026-60137) que permite a un atacante anónimo ejecutar código de forma remota sobre una instalación por defecto, sin plugins de por medio ni credenciales.
Encadenados, los dos bugs habilitan crear una cuenta de administrador, iniciar sesión y subir un plugin malicioso. Los parches son 6.9.5 y 7.0.2 (además de 6.8.6 para la rama anterior), y CISA agregó ambos CVE a su catálogo de vulnerabilidades explotadas (KEV) el 21 de julio.
Dos fallos que solos no alcanzan, juntos sí
CVE-2026-63030 es una confusión de rutas en el endpoint batch de la REST API (/wp-json/batch/v1), presente desde WordPress 6.9. Cuando wp_parse_url() falla sobre la ruta de una sub-petición, los arreglos internos de validación y de despacho se desalinean, y las peticiones siguientes terminan ejecutándose bajo el handler equivocado. Está catalogado como CWE-436 con un CVSS de 7.5.
CVE-2026-60137 es una inyección SQL en WP_Query, presente desde la 6.8: el parámetro author__not_in se interpola directo en el SQL crudo cuando se pasa como cadena escalar en lugar de como arreglo. Es un CWE-89 con CVSS 9.1.
La gracia del ataque es la combinación: la desincronización del endpoint batch permite saltear la validación que normalmente frenaría al parámetro vulnerable, y así llegar a la inyección SQL. De ahí a crear un admin y subir un plugin con código PHP arbitrario hay un paso.
Qué versiones están afectadas
- Rama 6.9: afectadas 6.9.0 a 6.9.4, parcheada en 6.9.5.
- Rama 7.0: afectadas 7.0.0 y 7.0.1, parcheada en 7.0.2.
- Rama 6.8: afectada solo por la inyección SQL (
CVE-2026-60137), parcheada en 6.8.6. - La línea 7.1 beta quedó corregida a partir de la beta 2.
El punto clave es que se trata de una instalación por defecto: no hace falta ningún plugin de terceros ni una configuración especial para ser vulnerable.
Ya hay PoC y explotación activa
Tras la divulgación técnica, aparecieron múltiples pruebas de concepto públicas en cuestión de horas. Varias firmas de seguridad (entre ellas Patchstack, Hexastrike y watchTowr) confirmaron explotación in-the-wild en los días posteriores.
Por la magnitud del riesgo, el equipo de WordPress.org activó actualizaciones automáticas forzadas sobre los sitios con auto-updates habilitados, para achicar la ventana de exposición. Aun así, muchísimos sitios deshabilitan esa función o corren versiones desactualizadas a mano.
Qué hacer ahora
- Actualizar ya a 6.9.5, 7.0.2 o 6.8.6 según tu rama (Escritorio → Actualizaciones → Actualizar ahora).
- Revisar si aparecieron cuentas de administrador nuevas o inesperadas.
- Buscar plugins desconocidos o archivos PHP recién subidos que no reconozcas.
- Auditar los logs de acceso HTTP en busca de peticiones anómalas al endpoint
/wp-json/batch/v1. - Si no podés parchear de inmediato, bloquear ese endpoint en el WAF como mitigación temporal (Cloudflare desplegó reglas para todos los planes).
La actualización tapa el agujero, pero no deshace un compromiso previo. Si tu sitio corrió una versión vulnerable durante estos días, conviene asumir que pudo ser tocado: buscar backdoors, revisar usuarios y rotar credenciales antes de dar por cerrado el tema.
¿Ya actualizaste tus sitios WordPress?
WordPress corre en una porción enorme de la web, y un RCE pre-auth en el core es de los peores escenarios posibles. ¿Tenías las actualizaciones automáticas activadas, o vas a tener que revisar sitio por sitio? Contanos cómo lo estás manejando en los comentarios.
Fuentes
- Rapid7 — CVE-2026-63030: wp2shell, a Critical Remote Code Execution Vulnerability in WordPress Core
- Tenable — wp2shell (CVE-2026-63030, CVE-2026-60137): Frequently Asked Questions About Remote Code Execution
- WordPress.org News — WordPress 7.0.2 Release
- The Hacker News — New wp2shell WordPress Core Flaw Lets Unauthenticated Attackers Run Code
