wp2shell (CVE-2026-63030): un RCE previo a la autenticación en el núcleo de WordPress y qué hacer ahora

wp2shell es un fallo de ejecución remota de código previo a la autenticación en el núcleo de WordPress, lo que significa que una petición anónima, sin inicio de sesión y sin necesidad de ningún plugin vulnerable, puede ejecutar código en una instalación por defecto. Encadena dos fallos divulgados el 17 de julio de 2026: una inyección SQL en el WP_Query de WordPress (CVE-2026-60137) y una confusión en la ruta de lotes de la REST API (CVE-2026-63030). Los exploits públicos aparecieron en cuestión de horas, los ataques reales se confirmaron en cuestión de días, y CISA añadió ambos fallos a su catálogo de Known Exploited Vulnerabilities. Si gestionas un sitio WordPress autoalojado en 6.9.x o 7.0.x, la única suposición segura es que eres un objetivo: actualiza a 6.9.5 o 7.0.2 de inmediato y, después, comprueba si alguien entró antes de que aplicaras el parche.

¿Qué es wp2shell y por qué es tan grave?

wp2shell es el nombre que los investigadores de Searchlight Cyber dieron a una cadena de dos fallos en el propio núcleo de WordPress, no en un plugin ni en un tema. Esa distinción es lo que lo hace serio. Un fallo en un plugin afecta a los sitios que instalaron ese plugin; un fallo en el núcleo afecta a un WordPress recién instalado, sin nada añadido. WordPress funciona en unos 500 million de sitios estimados, y cualquiera de ellos en una versión afectada expone el endpoint vulnerable por defecto.

La gravedad reside en la cadena. Tenable califica el fallo de la ruta de lotes de REST, CVE-2026-63030, con un CVSS de 9.8, y la inyección SQL, CVE-2026-60137, con 5.9. Por separado, cada uno es un problema; juntos, permiten que un atacante no autenticado pase de una única petición HTTP a la toma de control completa como administrador. Sin credenciales, sin interacción del usuario, sin necesidad de un segundo punto de apoyo.

Cómo funciona la cadena de explotación

Lo ingenioso es cómo los dos fallos se cubren mutuamente. El parámetro de consulta author__not_in de WordPress se interpola directamente en SQL en bruto cuando se pasa como una cadena escalar: una inyección clásica, salvo que la validación normal de la petición rechaza la entrada malformada antes de que llegue a la base de datos.

Ahí es donde entra la batch API. El endpoint /wp-json/batch/v1 valida y ejecuta las subpeticiones en dos bucles separados. Cuando wp_parse_url() falla en la ruta de una subpetición manipulada, el error se registra en el array de validación, pero la petición no se elimina del array de ejecución. Las dos listas se desincronizan, la validación se omite, y una llamada de lote recursiva cuela una inyección SQL basada en UNION directamente. A partir de ahí, el exploit encadena los mecanismos internos de WordPress para crear una cuenta de administrador, inicia sesión con ella y sube un plugin malicioso, y ese plugin es la carga útil de ejecución de código. Entra una petición, sale una web shell.

¿Qué versiones de WordPress están afectadas?

La cadena completa de RCE solo funciona donde existe la ruta de lotes, que WordPress introdujo en 6.9. La inyección SQL por sí sola llega más atrás. Se publicaron versiones parcheadas en las tres ramas con soporte.

Rama	Versiones afectadas	Corregido en	Exposición
7.0.x	7.0.0 – 7.0.1	7.0.2	RCE completo previo a la autenticación
6.9.x	6.9.0 – 6.9.4	6.9.5	RCE completo previo a la autenticación
6.8.x	6.8.0 – 6.8.5	6.8.6	Solo inyección SQL (CVE-2026-60137)

Como el fallo está en el núcleo y el riesgo es crítico, el equipo de seguridad de WordPress.org activó las actualizaciones automáticas forzadas para los sitios en versiones afectadas. Eso ayuda, pero las actualizaciones forzadas se despliegan de forma gradual y pueden desactivarse en wp-config.php, así que no esperes a que te la empujen; aplica la actualización tú mismo.

¿Se está explotando wp2shell ahora mismo?

Sí, y con rapidez. Aparecieron varios exploits de prueba de concepto en GitHub a las pocas horas de la divulgación, algunos de ellos asistidos por IA. La telemetría de ataques llegó casi de inmediato: la firma de seguridad watchTowr informó de que sus honeypots registraron decenas de miles de intentos de explotación desde 13 IPs de atacantes distintas repartidas por Europa y Asia, con compromisos exitosos en marcha en menos de un día. El 21 de julio de 2026, ambos CVE se añadieron al catálogo Known Exploited Vulnerabilities de CISA, la señal más clara de que esto es algo activo, no teórico.

El comportamiento posterior a la explotación es lo que importa a los defensores. Los atacantes han creado más de 100 cuentas de administrador de puerta trasera, han soltado una web shell PHP de aproximadamente 150 KB disfrazada de plugin de seguridad llamado "CMSmap", han recopilado nombres de usuario de administrador y credenciales de base de datos, y en algunos casos han intentado instalar un troyano de acceso remoto basado en Go llamado Overlord RAT. Dicho de otro modo, parchear una máquina que ya fue atacada no expulsa al atacante, porque se dejó una llave.

Aplica el parche ya: la solución de quince minutos

Para cualquiera que gestione su propio WordPress, el orden de prioridad es sencillo:

1. Actualiza el núcleo a 6.9.5, 7.0.2 o 6.8.6. Desde el escritorio es un solo clic; con WP-CLI es wp core update && wp core update-db. Esta es la única solución real; todo lo que sigue es un remedio provisional.
2. Bloquea el endpoint de lotes si no puedes actualizar en este mismo instante. Deniega las peticiones a /wp-json/batch/v1 y al equivalente ?rest_route=/batch/v1 en tu servidor web o WAF. Cloudflare desplegó una regla WAF gestionada a todos los planes, incluido el gratuito, de modo que los sitios que están detrás obtienen una cobertura básica de forma automática.
3. Restringe el acceso anónimo a REST con un plugin o un pequeño filtro must-use que exija autenticación en la REST API, cerrando la vía de inyección.
4. Confirma la versión después. Comprueba Dashboard → Updates o ejecuta wp core version, para que una actualización automática atascada no te deje creyendo que estás a salvo cuando no lo estás.

Si administras servidores, tratar las actualizaciones del núcleo como un evento de seguridad del mismo día en lugar de como una tarea mensual es la verdadera lección aquí; nuestra guía sobre la primera hora segura en un nuevo VPS explica cómo integrar esa disciplina desde el principio. Gestionamos la propia infraestructura de este sitio a través de WaseerHost, nuestra empresa de hosting, y los fallos a nivel de núcleo como este son exactamente la razón por la que los planes de WordPress gestionado fuerzan las versiones de seguridad en el momento en que se publican.

¿Ya has aplicado el parche? Comprueba primero si te alcanzó

Este es el paso que la mayoría de los artículos se saltan, y es el que te salva. Todas las firmas de seguridad que siguen wp2shell repiten la misma advertencia: inspecciona tu sitio en busca de señales de compromiso, independientemente de si has aplicado el parche, porque actualizar el núcleo no hace nada frente a una puerta trasera ya plantada. Revisa lo siguiente en cualquier servidor que estuviera expuesto:

• Audita las cuentas de administrador. wp user list --role=administrator debería mostrar únicamente a personas que reconoces. La firma de este ataque son usuarios administradores inesperados, a veces docenas de ellos. Elimina cualquiera que no hayas creado y restablece las contraseñas de los que conserves.
• Rastrea tus registros de acceso. Busca accesos a la ruta de lotes: grep -E "batch/v1" access.log. Las peticiones a /wp-json/batch/v1 o ?rest_route=/batch/v1 desde IPs desconocidas, sobre todo agrupadas antes de tu hora de parcheo, son la huella de la explotación.
• Caza la web shell. Busca archivos PHP modificados recientemente o de tamaño anómalo bajo wp-content/plugins y wp-content/uploads, y un plugin que nunca instalaste (se ha observado el nombre "CMSmap", pero da por hecho que puede renombrarse). find wp-content -name '*.php' -mtime -7 es un primer barrido rápido.
• Rota tus secretos. Si hay cualquier señal de compromiso, sustituye las claves de autenticación y los salts en wp-config.php, fuerza un restablecimiento de contraseña para todos los usuarios y rota las credenciales de base de datos que el atacante haya podido exfiltrar.

Si encuentras una puerta trasera, parchear no es remediar: restaura desde una copia de seguridad íntegra tomada antes de la fecha de divulgación y luego actualiza. Un compromiso tan limpio como este se parece más, en espíritu, a una brecha en la cadena de suministro que a un fallo de plugin: el límite de confianza era la propia plataforma.

Preguntas frecuentes

¿Estoy afectado si mi sitio no tiene plugins adicionales? Sí, y ese es precisamente el quid. wp2shell explota el núcleo de WordPress, de modo que una instalación por defecto con cero plugins en una versión afectada (6.9.0–6.9.4 o 7.0.0–7.0.1) es vulnerable a la cadena completa de ejecución remota de código. Añadir o quitar plugins no cambia tu exposición al fallo del núcleo.

¿Actualizar elimina a un atacante que ya ha entrado? No. Aplicar el parche cierra la puerta, pero si alguien la cruzó antes de que la cerraras, puede haber dejado una cuenta de administrador de puerta trasera o una web shell que sobrevive a la actualización. Tienes que rastrear y eliminar eso por separado, o restaurar desde una copia de seguridad anterior a la divulgación.

¿Y si no puedo actualizar de inmediato? Bloquea /wp-json/batch/v1 y ?rest_route=/batch/v1 en tu firewall o WAF, y coloca el sitio detrás de un servicio como Cloudflare, que ha desplegado una regla gestionada. Estas son mitigaciones, no soluciones, así que programa la actualización del núcleo tan pronto como puedas y verifica la versión después.

¿Es seguro un hosting de WordPress totalmente gestionado? En gran medida, si el proveedor forzó la versión de seguridad del núcleo, cosa que los proveedores gestionados de confianza hicieron en cuestión de horas. Aun así, merece la pena confirmar tu versión y comprobar si hay cuentas de administrador fraudulentas, porque un panel de control gestionado no limpia automáticamente un compromiso que ocurrió antes del parche.

¿Está relacionado con la oleada de parches de junio de 2026? No, es un problema independiente del núcleo de WordPress, pero llega en un tramo ya de por sí feo. Consulta nuestro repaso del Patch Tuesday récord de junio de 2026 para el contexto más amplio sobre la rapidez con la que se están convirtiendo en armas los fallos críticos en 2026.

Sources

• Strobes — wp2shell: RCE previo a la autenticación en el núcleo de WordPress: fecha de divulgación y visión general de la cadena.
• Tenable — FAQ de wp2shell (CVE-2026-63030, CVE-2026-60137): puntuaciones CVSS, versiones afectadas/corregidas y mitigación con WAF.
• Rapid7 — CVE-2026-63030: RCE wp2shell en el núcleo de WordPress: mecánica de la cadena de explotación y adición al KEV de CISA.
• BleepingComputer — Los fallos RCE "wp2shell" del núcleo de WordPress reciben exploits públicos: descubridor, actualizaciones automáticas forzadas y escala.
• The Hacker News — Crece la explotación de wp2shell en WordPress: indicadores de compromiso en la naturaleza y actividad posterior a la explotación.