Ayer salió WordPress 7.0.2 y, si gestionas webs para clientes, no lo trates como una actualización de rutina. El equipo de seguridad de WordPress ha publicado un parche crítico que combina una confusión en las rutas batch de la REST API con una inyección SQL. El resultado, según el advisory de GitHub, es ejecución remota de código. RCE. En el core. Sin plugins raros de hace cinco años.
Lo primero que me llamó la atención no fue solo la gravedad, sino la reacción oficial: WordPress.org ha activado actualizaciones forzadas vía auto-update para las versiones afectadas. Cuando el propio proyecto decide empujar el parche desde arriba, no es porque quieran molestarte un viernes. Es porque consideran que el riesgo es demasiado alto para confiar en que cada administrador entre al panel a tiempo.
Qué ha pasado exactamente
Las versiones afectadas van desde WordPress 6.9.0 hasta 7.0.1. El fallo lo descubrió Adam Kues, de Assetnote / Searchlight Cyber, y está catalogado como CVE-2026-63030. La cadena de ataque es la típica que a mí me pone los pelos de punta: una debilidad en cómo WordPress procesa peticiones batch en la REST API, encadenada con otra vulnerabilidad SQL (CVE-2026-60137) reportada por TF1T, dtro y haongo. Dos piezas que por separado ya inquietan; juntas, abren la puerta al servidor.
WordPress ha sacado parches en cascada: 7.0.2 para la rama actual, 6.9.5 para quien sigue en 6.9, 6.8.6 para la primera de las dos vulnerabilidades, y 7.1 beta2 para quien esté probando la beta. Si tu cliente lleva meses en una 6.7 porque «si funciona no se toca», esta vez te libras del core. Las versiones anteriores a 6.8 no están afectadas. Pero conozco demasiados proyectos que llevan meses en 6.9.x esperando a que alguien les dé luz verde para actualizar.
La REST API: la puerta trasera que nadie vigila
Aquí es donde el artículo deja de ser un aviso técnico y se convierte en crítica al ecosistema. Llevamos años montando webs con bloques, headless, integraciones, MCP, chatbots conectados al backoffice… y todo pasa por la REST API. Es la columna vertebral de WordPress moderno. Pero en la práctica, la mayoría de tiendas y webs corporativas que mantengo no tienen ni idea de qué endpoints tienen expuestos, quién puede llamarlos ni si el batch processing está activo.
El hosting compartido te vende «WordPress optimizado» y te instala LiteSpeed Cache, un certificado Let’s Encrypt y poco más. El WAF filtra bots y ataques genéricos, pero una confusión de rutas en el propio core no la para un plugin de seguridad de 29 euros al año. He visto paneles de Plesk con cincuenta sitios en 6.9.3, todos con el mismo plugin de firewall, todos convencidos de que «estamos protegidos». No lo estáis. Estáis actualizados hasta la última brecha conocida.
Y no me vale el argumento de «pero si el atacante necesita autenticación». Léete el advisory. La combinación con SQL injection cambia las reglas. Cuando el vector incluye ejecución remota, el perfil del atacante deja de ser el script kiddie y pasa a ser alguien que sabe lo que busca: servidores con tiendas WooCommerce, formularios con datos de clientes, backups accesibles desde el mismo hosting.
Lo que tu proveedor no te va a decir
WordPress ha activado auto-updates forzados. Eso significa que en muchos servidores el parche ya se está aplicando solo. ¿Suena bien? Depende. Si tu cliente tiene un tema custom que revienta con cada minor release, acabas de enterarte por un ticket de «la web se ve rara» y no por un aviso del hosting. Si gestionas diez, veinte o cien sitios en un reseller, el caos es proporcional.
Lo que me molesta es el silencio. He revisado varios proveedores de hosting español esta mañana y la mayoría sigue con el banner habitual de «rendimiento y seguridad premium», cero mención a 7.0.2, cero recomendación de revisar plugins desactualizados. El parche del core es necesario pero no suficiente: el 96% de vulnerabilidades en WordPress vienen de plugins, no del núcleo. Arreglar la REST API no arregla tu Spectra desactualizado, tu constructor de bloques abandonado ni el plugin de sliders que nadie se atreve a quitar.
En mi experiencia, los clientes que más sufren en situaciones así son los que externalizaron el mantenimiento al «sobrino que le gusta la informática» o al freelance más barato del marketplace. Nadie monitoriza versiones, nadie tiene staging, y cuando WordPress fuerza una actualización a las tres de la madrugada, el primer responsable eres tú, el que montó la web hace tres años y sigue cobrando el hosting en nombre del cliente.
Qué haría yo hoy, sin dramatismos pero sin pereza
Primero: comprobar versión en todos los sitios. No uno, todos. Segundo: actualizar a 7.0.2, 6.9.5 o 6.8.6 según corresponda. Tercero: revisar plugins con acceso a la REST API o que registren rutas custom. Cuarto: mirar logs del servidor por peticiones raras a /wp-json/batch/v1 en las últimas semanas. Si tienes staging, pruébalo ahí antes. Si no tienes staging, quizá este incidente te sirva para dejar de ahorrarte 15 euros al mes.
No voy a caer en el catastrofismo de «WordPress es inseguro». El propio comunicado demuestra lo contrario: vulnerabilidad crítica, parche en horas, backports, CVE publicados, créditos a los investigadores. El core funciona como debe. Lo que falla es la cadena de mantenimiento entre el parche y el sitio del pyme que vende online los fines de semana.
La ironía es que muchos de esos clientes llevan meses preguntando si deberían meter IA en la web, conectar un chatbot o montar un MCP para gestionar contenidos. Quieren la capa brillante sin pagar la capa aburrida de actualizar, auditar y probar. Pues bien: la REST API que alimenta media innovación de 2026 acaba de demostrar que sin mantenimiento básico, la innovación se construye sobre un cimiento agrietado.
Fuentes
- WordPress 7.0.2 Release – WordPress News
- REST API batch-route confusion and SQL injection issue leading to Remote Code Execution – GitHub Advisory
Si tu proveedor de hosting te garantiza «seguridad WordPress incluida» pero no te avisó del parche 7.0.2 en las primeras 24 horas, ¿seguirías pagando el mismo plan el próximo año o exigirías un SLA de respuesta ante CVEs críticos?