wp2shell: dos CVE y cero contraseñas para hackear tu WordPress

Una cadena de dos vulnerabilidades en el núcleo de WordPress —no en un plugin, no en un tema: en el corazón mismo del CMS— permite a cualquier atacante anónimo ejecutar código en tu servidor sin necesidad de credenciales. Se llama wp2shell, combina los CVE-2026-63030 y CVE-2026-60137, y ya está siendo explotada activamente. BleepingComputer recoge los detalles de lo que podría ser la vulnerabilidad más grave en la historia reciente de WordPress.

Anatomía de un atraco en dos actos

wp2shell no es una vulnerabilidad: son dos que, encadenadas, se convierten en algo mucho peor que la suma de sus partes. Es como descubrir que la puerta de tu casa y la cerradura de tu caja fuerte comparten el mismo defecto de fábrica.

Acto primero: la confusión de rutas (CVE-2026-63030). El endpoint /wp-json/batch/v1 de la API REST de WordPress procesa múltiples sub-peticiones en paralelo usando arrays. Un error en una sub-petición provoca un desalineamiento que permite a la petición del atacante ejecutarse bajo un handler diferente, esquivando la lista de seguridad del endpoint. Puntuación CVSS: 7.5.

Acto segundo: la inyección SQL (CVE-2026-60137). Una vez dentro del camino vulnerable, el atacante apunta al parámetro author__not_in en WP_Query. Al enviar una cadena en lugar de un array, la validación se salta e inyecta SQL directamente en la consulta a la base de datos. Puntuación CVSS: 9.1+.

El resultado final: ejecución remota de código sin autenticación. Un usuario anónimo, sin plugins instalados, sin configuración especial, en una instalación limpia de WordPress. Cero precondiciones.

Quinientos millones de razones para preocuparte

Más de 500 millones de sitios web funcionan con WordPress a nivel global. La cadena de RCE completa afecta a las versiones 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1 — es decir, todas las instalaciones actualizadas desde diciembre de 2025. Ocho meses de despliegues potencialmente vulnerables.

Las versiones anteriores (6.8.0 a 6.8.5) no se libran del todo: aunque la cadena RCE completa no funciona, la inyección SQL sigue siendo explotable. WordPress ha publicado parches para todas las ramas: 6.8.6, 6.9.5 y 7.0.2.

El equipo de WordPress.org ha activado las actualizaciones forzadas automáticas, algo que solo ocurre en situaciones de emergencia absoluta. Pero no todos los sitios tienen las auto-updates habilitadas. Los que usan hosting gestionado probablemente ya estén parcheados. Los que no… juegan a la lotería.

La carrera contra el reloj que ya se perdió

El viernes 18 de julio se publicaron los parches. El mismo fin de semana, los exploits proof-of-concept ya circulaban públicamente en GitHub —con repositorio automatizado incluido para lanzar ataques en lote—. Para el domingo, las firmas de seguridad detectaban ataques en honeypots y los equipos de respuesta a incidentes ya tenían trabajo. La ventana entre “parche disponible” y “exploit público” fue de horas, no días.

Los atacantes están desplegando webshells persistentes e instalando plugins maliciosos en los servidores afectados. Incluso después de parchear, si la explotación ya ocurrió, el acceso del atacante persiste.

Esa es la parte más perversa de wp2shell: el parche cierra la puerta de entrada, pero no expulsa al intruso que ya entró. Si tu sitio fue comprometido antes de la actualización, parchear no es suficiente. Necesitas una auditoría completa.

Qué hacer ahora mismo (sin excusas)

Si gestionas sitios WordPress, esto es lo que deberías estar haciendo en este preciso instante:

Actualizar inmediatamente a las versiones 6.8.6, 6.9.5 o 7.0.2. Verificar que la actualización se aplicó realmente — la versión que muestra el dashboard es la que cuenta, no la que asumes.

Si no puedes parchear de inmediato: bloquear /wp-json/batch/v1 y rest_route=/batch/v1 a nivel de WAF. Otra opción: desactivar la API REST de WordPress para acceso no autenticado. Es una solución de emergencia, no una estrategia a largo plazo.

Revisar los logs en busca de actividad sospechosa, especialmente intentos de inyección SQL y accesos a la ruta batch. Si detectas indicios de compromiso, asume lo peor: busca webshells, plugins desconocidos y usuarios administradores que no creaste tú.

Un dato esperanzador: los sitios que utilizan cachés de objetos persistentes como Redis o Memcached podrían estar protegidos frente a la cadena RCE específica, aunque la inyección SQL sigue siendo un riesgo.

WordPress y su eterno talón de Aquiles

wp2shell pone sobre la mesa una pregunta incómoda que la comunidad de WordPress lleva años esquivando: ¿es sostenible que el CMS que alimenta el 43% de la web tenga vulnerabilidades de ejecución remota de código en su núcleo? No hablamos de un plugin abandonado de 2019 ni de un tema premium con puertas traseras. Hablamos de WP_Query y la API REST — los cimientos del edificio.

La respuesta automática de forzar actualizaciones es un parche sobre el parche. Funciona para los sitios conectados, pero deja fuera a las instalaciones aisladas, los entornos corporativos con procesos de aprobación y los millones de sitios mantenidos por freelancers que no revisan sus dashboards entre proyecto y proyecto.

Lo que wp2shell demuestra, una vez más, es que la seguridad de WordPress no es un estado: es un proceso continuo que exige atención constante. Y en un ecosistema donde un solo par de CVE puede poner en jaque a cientos de millones de sitios, esa atención no es opcional — es la línea que separa un negocio operativo de un desastre con webshell incluida.