Una solicitud POST basta para tomar el control de un sitio WordPress. Actualice a 7.0.2 hoy.
El 17 de julio, WordPress publicó la versión 7.0.2, y no fue una actualización de versión menor normal. Cierra una cadena que los investigadores denominaron wp2shell: dos errores que, combinados, permiten a un atacante anónimo ejecutar código en una instalación predeterminada de WordPress. Sin inicio de sesión. Sin complemento vulnerable. Sin tema extraño. Una solicitud POST manipulada a la API REST, y el servidor puede terminar con una nueva cuenta de administrador y un shell respondiendo a comandos.
La cadena comprende dos CVE. CVE-2026-63030 es una confusión de ruta/manejador en el endpoint de lote de la API REST, calificado como crítico, introducido en la versión 6.9. CVE-2026-60137 es una inyección SQL en el manejo de author__not_in por WP_Query, calificado como alto, y se remonta hasta la versión 6.8. Por sí solos, cada uno es un problema. Encadenados, la confusión del endpoint de lote desvincula la validación de la ejecución y alimenta la entrada no validada directamente en la inyección SQL, logrando ejecución remota de código sin autenticación. WordPress activó las actualizaciones automáticas forzadas para los sitios afectados, lo que indica cómo el equipo principal evaluó el riesgo. Patchstack afirma que ya está viendo intentos de explotación en sus registros.
Este es el mapa de versiones. La cadena RCE completa afecta desde la 6.9.0 hasta la 7.0.1. La rama 6.8 solo lleva la inyección SQL, no la confusión de ruta que la hace accesible sin inicio de sesión. Las correcciones llegaron en las versiones 6.8.6, 6.9.5 y 7.0.2, más una versión beta2 de 7.1 para quienes estén probando la próxima rama. La confusión de ruta fue reportada por Adam Kues de Assetnote, el brazo de investigación de Searchlight Cyber, a través del programa HackerOne de WordPress. La inyección SQL fue reportada por separado por TF1T, dtro y haongo.
Por qué esta vulnerabilidad es peor que el CVE habitual de WordPress
La mayoría de las vulnerabilidades de WordPress residen en complementos. Se pueden auditar, fijar o eliminar. Esta está en el núcleo, en una instalación predeterminada, accesible antes de la autenticación. Esa combinación es poco frecuente, y es exactamente el perfil que los atacantes automatizan primero. Un error de núcleo preautenticación en la plataforma que ejecuta una gran parte de la web es un evento de escaneo masivo, no uno dirigido. Los scripts públicos de prueba de concepto aparecieron en uno o dos días tras la divulgación, y las actualizaciones forzadas solo llegan a los sitios que tienen activada la actualización automática y que realmente se conectan al servidor. Muchos no lo hacen.
Hay un detalle operativo que merece mención. Los informes sobre el error señalan que la ruta RCE es más fácil de alcanzar cuando un sitio no ejecuta una caché de objetos persistente, que es la configuración predeterminada para muchas instalaciones pequeñas y medianas. Por lo tanto, los sitios con menor probabilidad de tener una configuración reforzada son los más expuestos. Esto coincide con lo que vemos durante los compromisos de pruebas de penetración para estudios de videojuegos: el riesgo real suele estar en la aburrida configuración predeterminada, no en el caso extremo exótico en el que todos pasan el tiempo preocupándose.
Qué hacer esta semana
Primero, aplique el parche. Si ejecuta WordPress desde la versión 6.8 hasta la 7.0.1 en cualquier entorno, migre a la 7.0.2 o al backport correspondiente 6.9.5 o 6.8.6 ahora, no en la próxima ventana de mantenimiento. Luego confirme que la actualización se aplicó realmente. Las actualizaciones automáticas forzadas pueden fallar silenciosamente detrás de un proxy inverso o en un sistema de archivos bloqueado, así que compruebe la versión reportada en lugar de confiar en que el mecanismo cumplió su función.
Segundo, asuma que el tiempo entre el lanzamiento de la versión 6.9 y el 17 de julio fue una ventana abierta y busque indicios de que alguien la aprovechó. Revise si hay usuarios administradores que no reconoce, archivos inesperados en wp-content/plugins/ y conexiones salientes del servidor web que no pueda explicar. Un parche limpio no deshace un compromiso que ya ocurrió, y este error deja al atacante exactamente el tipo de acceso persistente que sobrevive a una actualización.
Tercero, coloque un control frente a la aplicación, no solo dentro de ella. Cloudflare implementó una regla WAF de emergencia el día de la divulgación. Cuando configuramos Cloudflare para clientes que necesitan protección DDoS y un WAF, una regla gestionada para un CVE de núcleo reciente como este proporciona horas o días de cobertura mientras el parche se aplica en una flota de sitios. Por nuestra experiencia con plataformas de viajes, esa ventana de parche virtual suele marcar la diferencia entre reaccionar en minutos y reaccionar después del hecho.
Para los equipos que desarrollan en PHP en general, la lección real tiene que ver con los límites de confianza. Esta cadena funcionó porque una capa de validación y una capa de ejecución no coincidían en cuanto al contenido de la solicitud. Vemos el mismo tipo de error en aplicaciones personalizadas constantemente: la entrada se verifica en un lugar y se consume en otro, y los dos se distancian hasta que un atacante introduce algo entre ellos. En nuestro trabajo con PHP y Docker, el hábito que lo detecta es tratar cada solicitud como hostil hasta que la capa exacta que ejecuta la consulta la haya revalidado. La validación que ocurre a tres funciones de distancia de la base de datos no es una validación en la que se pueda confiar.
Realizamos este tipo de revisión de preautenticación para clientes empresariales con obligaciones reales de cumplimiento, y la experiencia del equipo está en encontrar la solicitud que no debería funcionar pero funciona. Si «parcheamos, pero no estamos seguros de que nada haya entrado antes» le suena familiar, hablemos.