En pocas palabras: WordPress 7.0.2 salió el 17 de julio de 2026 como release de seguridad que parchea dos fallas: una crítica de ejecución remota de código en la REST API y una inyección SQL de severidad alta. WordPress.org forzó actualizaciones automáticas: si tenés 6.8, 6.9 o 7.0, actualizá ya.
WordPress 7.0.2 salió el 17 de julio de 2026 como release de seguridad y corrige dos fallas: una crítica y una de severidad alta. Según el anuncio oficial de WordPress.org, se activaron actualizaciones forzadas para los sitios afectados. La recomendación es clara: actualizá ya.
Lo que ocurre con WordPress 7.0.2 es que no es un update opcional de esos que podés dejar para el finde. Hay una inyección SQL facilitada y, peor todavía, un bug en la REST API que termina en ejecución remota de código. Si tenés un sitio en 6.8, 6.9 o 7.0, esto te toca.
WordPress 7.0.2 es el parche de seguridad de la rama 7.0 del CMS de WordPress.org, publicado el 17 de julio de 2026 para parchear una vulnerabilidad crítica de ejecución remota de código en la REST API y una inyección SQL de severidad alta. El equipo de WordPress.org habilitó actualizaciones automáticas forzadas para todas las versiones afectadas.
En 30 segundos
- WordPress 7.0.2 corrige una falla crítica (RCE vía REST API) y una alta (inyección SQL), según el comunicado oficial del 17 de julio de 2026.
- WordPress.org activó actualizaciones forzadas por el auto-update system para los sitios en versiones vulnerables.
- Afectadas: 7.0, 6.9 (ambas fallas) y 6.8 (solo la primera). Las versiones previas a 6.8 no corren riesgo.
- Ramas parcheadas en paralelo: 6.9.5, 6.8.6 y hasta la 7.1 beta2.
- El RCE lo reportó Adam Kues, de Assetnote / Searchlight Cyber.
WordPress es un software de código abierto para crear y administrar sitios web, blogs y tiendas en línea, desarrollado y mantenido por Automattic y la comunidad WordPress.
¿Qué vulnerabilidades críticas trae WordPress 7.0.2?
Son dos, y las dos terminan tocando la base de datos. La primera es una inyección SQL facilitada, reportada por TF1T, dtro y haongo. La segunda es la que asusta: una confusión de rutas en el endpoint batch de la REST API que combina con otra inyección SQL y escala hasta ejecución remota de código. Esa la reportó Adam Kues, de Assetnote / Searchlight Cyber.
¿Por qué la segunda es crítica y la primera «solo» alta? Porque un RCE no te roba datos, te da la casa entera. El atacante puede correr código arbitrario en tu servidor. Complementá con comunidad WordPress y su evolución.
Ponele que tenés un WooCommerce con la REST API abierta (que es lo normal, la usan las apps, los headless, medio todo). Un atacante manda una request armada al batch-route, se cuela por la confusión de rutas, inyecta SQL y de ahí salta a ejecutar código. Sin plugin vulnerable de por medio, sin contraseña filtrada. Solo el core desactualizado.
Si querés el detalle fino de cómo se explotan estas cosas (hardening, WAF, análisis forense), ese es terreno de nuestro blog hermano seguridadenwordpress.com. Acá lo que importa es que actualices.
¿Qué versiones de WordPress están afectadas?
Las ramas 7.0, 6.9 y 6.8 están afectadas, además de la beta de 7.1. WordPress 6.9 y 7.0 cargan con las dos vulnerabilidades; 6.8 se salva de la crítica (RCE) y solo sufre la inyección SQL facilitada. Todo lo anterior a 6.8 queda afuera. Cada rama recibió su parche por separado.
Acá viene lo importante: si estás en 6.8, no bajes la guardia por tener «una sola» vulnerabilidad. Igual necesitás el fix.
| Versión afectada | SQLi facilitada (alta) | RCE vía REST API (crítica) | Versión corregida |
|---|---|---|---|
| WordPress 7.0.x | Sí | Sí | 7.0.2 |
| WordPress 6.9.x | Sí | Sí | 6.9.5 |
| WordPress 6.8.x | Sí | No | 6.8.6 |
| WordPress 7.1 (beta) | Sí | Sí | 7.1 beta2 |
| Anteriores a 6.8 | No | No | No afectadas |
¿Qué significa la actualización forzada que activó WordPress.org?
Significa que WordPress.org forzó la actualización sin pedirte permiso. Por la severidad de las fallas, el equipo habilitó las actualizaciones forzadas a través del auto-update system para todos los sitios que corran versiones afectadas. Es un mecanismo que el proyecto reserva para casos graves, y este entró en esa categoría. Para más detalles técnicos, mirá crear landing pages de alto rendimiento.
Fijate que «forzada» no quiere decir «instantánea en todos lados». El proceso arranca en background en los sitios que soportan actualizaciones automáticas de fondo. Si tu hosting las tiene habilitadas (lo normal), en algún momento de las próximas horas te vas a encontrar el sitio ya en 7.0.2.
Eso sí: no todos los sitios reciben el empujón. Los que tienen los auto-updates deshabilitados por configuración, o un hosting que bloquea la escritura sobre el core, quedan fuera del reparto. Esos los tenés que actualizar a mano.
¿Cómo actualizar WordPress 7.0.2 manualmente paso a paso?
Entrás al Escritorio de WordPress, vas a «Actualizaciones» y hacés clic en «Actualizar ahora». Listo, eso dispara la instalación de 7.0.2. La otra vía es descargar el paquete desde WordPress.org y subirlo por FTP. En un sitio típico tarda menos de un minuto.
Igual, un consejo de quince años peleando con esto: no actualices directamente en el sitio en vivo sin antes hacer backup. En probar la actualización en un ambiente seguro profundizamos sobre esto.
- Backup primero. Base de datos y archivos, antes de tocar nada. Un release de seguridad casi nunca rompe, pero «casi» no es «nunca».
- Escritorio > Actualizaciones > Actualizar ahora. Es la ruta oficial y la más rápida.
- Alternativa manual. Descargás WordPress 7.0.2 desde WordPress.org y reemplazás
wp-adminywp-includespor FTP. - Revisá después. Entrá al front y al admin, chequeá que el checkout, el login y los formularios respondan.
Si tu WordPress vive en un hosting WordPress como el de Donweb, las actualizaciones automáticas de fondo suelen venir activadas, así que lo más probable es que el update ya te haya llegado solo. Igual conviene verificarlo.
¿Qué riesgo corrés si no actualizás?
El riesgo concreto es que te ejecuten código en el servidor. Con el RCE de la REST API, un atacante que llegue a explotarlo puede instalar malware, robar la base de datos completa, desfigurar el sitio o dejar una puerta trasera para volver cuando quiera. La inyección SQL, por su lado, expone datos sensibles de tu base.
¿Y qué pasa cuando un bug de core sale a la luz con reportantes nombrados y parche público? Que los escaneos automáticos aparecen a las pocas horas. Los atacantes leen los mismos changelogs que vos.
Un sitio desactualizado con la REST API expuesta es un blanco pasivo esperando el barrido. No hace falta que seas un objetivo elegido, alcanza con estar en la lista de IPs que alguien escanea.
¿Los plugins y temas son compatibles con WordPress 7.0.2?
Sí, en la enorme mayoría de los casos. Un release de seguridad menor como 7.0.2 no cambia APIs ni rompe compatibilidad: parchea fallas puntuales sin tocar la superficie que usan plugins y temas. Si venías corriendo bien en 7.0.1, 7.0.2 no debería moverte nada. Más contexto en verificar Enlaces rotos tras actualizar.
El punto es que «no debería» y «no va a» son cosas distintas cuando tenés diez plugins raros. Si administrás un sitio de producción con WooCommerce o builders pesados encima (Elementor, Divi, Bricks), lo prudente es probar en staging antes de tocar producción, aunque el update sea chico. Si algún plugin llegara a fallar, desactivalo, actualizalo a su última versión y reportalo al autor.
Qué está confirmado y qué no
- Confirmado: WordPress 7.0.2 corrige una falla crítica y una alta, según el comunicado oficial de WordPress.org del 17 de julio de 2026.
- Confirmado: se activaron actualizaciones forzadas vía auto-update para las versiones afectadas.
- Confirmado: las ramas 6.8.6, 6.9.5 y 7.1 beta2 salieron en simultáneo con sus respectivos parches.
- Confirmado: el RCE lo reportó Adam Kues (Assetnote / Searchlight Cyber); la SQLi facilitada, el equipo de TF1T, dtro y haongo.
- Pendiente: los identificadores CVE y GHSA figuran como referencia en el aviso, pero el detalle técnico completo suele publicarse con demora para no facilitar exploits.
- Pendiente: al momento del release no hay reportes públicos de explotación activa en la naturaleza.
Errores comunes al actualizar
- Confiar en que el auto-update «seguro corrió». No lo asumas. Andá a Escritorio > Actualizaciones y confirmá que el número diga 7.0.2. Muchos hostings tienen los auto-updates a medias.
- Actualizar sin backup. El clásico. La falla no viene del update, viene de ese plugin viejo que se lleva mal con todo. Sin backup, un problema chico se vuelve una noche larga.
- Quedarse en 6.8 pensando que «es vieja pero anda». 6.8 también está afectada. Actualizá a 6.8.6 si no querés saltar de rama todavía.
- Ignorar la REST API. Bloquear endpoints a mano no reemplaza el parche. La confusión de rutas se arregla en el core, no con reglas sueltas.
Preguntas Frecuentes
¿Qué es WordPress 7.0.2 y por qué hay que actualizar?
WordPress 7.0.2 es un release de seguridad publicado el 17 de julio de 2026 que parchea una vulnerabilidad crítica de ejecución remota de código y una inyección SQL de severidad alta. Hay que actualizar de inmediato porque ambas fallas afectan al core y ya tienen parche público, lo que las vuelve blanco de escaneos automáticos.
¿Mi sitio se actualiza solo a WordPress 7.0.2?
Si tu sitio soporta actualizaciones automáticas de fondo y corre una versión afectada, sí: WordPress.org activó actualizaciones forzadas para este release. El proceso arranca en background sin intervención tuya. Aun así, verificá en Escritorio > Actualizaciones que ya figure 7.0.2, porque algunos hostings tienen los auto-updates deshabilitados.
¿Qué versiones de WordPress están afectadas?
Las ramas 7.0, 6.9 y 6.8, más la beta de 7.1. La 6.9 y la 7.0 tienen las dos vulnerabilidades; la 6.8 solo la inyección SQL facilitada. Las versiones previas a 6.8 no están afectadas. Los parches salieron como 7.0.2, 6.9.5, 6.8.6 y 7.1 beta2.
¿Puedo hacer rollback si algo se rompe tras actualizar?
Podés, pero no es lo recomendable con un parche de seguridad. Si algo falla, la vía correcta es restaurar el backup previo, identificar el plugin o tema conflictivo y volver a 7.0.2 apenas lo resuelvas. Quedarte en una versión vulnerable para «evitar el bug» te deja expuesto al RCE.
¿Quién reportó las vulnerabilidades de WordPress 7.0.2?
La inyección SQL facilitada la reportó un equipo formado por TF1T, dtro y haongo. La falla crítica de confusión de rutas en la REST API con inyección SQL que escala a RCE la reportó Adam Kues, de Assetnote / Searchlight Cyber, según el aviso oficial de WordPress.org.
Conclusión
WordPress 7.0.2 no es un update de rutina. Un RCE en la REST API es de los pocos casos donde el propio proyecto se toma la molestia de forzar la actualización, y eso ya te dice el nivel de urgencia. Si administrás sitios en 6.8, 6.9 o 7.0, el trabajo de hoy es simple: verificá que estén en 7.0.2, 6.9.5 o 6.8.6, y si no, actualizá con backup previo. La ventana entre el parche público y los primeros escaneos masivos se mide en horas, no en días. No la desperdicies.
