WordPress ha publicado una actualización de seguridad urgente que corrige una vulnerabilidad crítica y otra de severidad alta en el núcleo. La versión 7.0.2, publicada el 17 de julio de 2026, incorpora ambas correcciones; la rama 6.9 recibe 6.9.5 con los dos parches y la rama 6.8 recibe 6.8.6 para la vulnerabilidad que le afecta. El proyecto ha habilitado actualizaciones forzadas en los sitios afectados mediante su sistema de autoactualización por la gravedad del problema.
No es una alerta sobre un plugin aislado ni una recomendación genérica de «actualiza cuando tengas tiempo». El aviso oficial afecta al core de WordPress. La prioridad razonable para quien administra una web es verificar la versión instalada, confirmar que el parche ha llegado y comprobar que la web, las copias y los servicios críticos siguen funcionando.
Qué ha corregido WordPress
El anuncio oficial identifica dos problemas: una inyección SQL facilitada, comunicada responsablemente por TF1T, dtro y haongo; y una confusión en la ruta batch de la API REST que, combinada con una inyección SQL, puede conducir a ejecución remota de código. Esta segunda vulnerabilidad fue reportada por Adam Kues, de Assetnote / Searchlight Cyber.
Los identificadores publicados son CVE‑2026‑60137 / GHSA‑fpp7‑x2x2‑2mjf y CVE‑2026‑63030 / GHSA‑ff9f‑jf42‑662q. No hace falta reproducir ataques ni publicar instrucciones técnicas para actuar: el dato operativo importante es que WordPress clasifica el paquete como una actualización de seguridad con un fallo crítico y otro alto.
Qué versiones deben revisarse
- WordPress 7.0: actualizar a 7.0.2; corrige las dos vulnerabilidades.
- WordPress 6.9: actualizar a 6.9.5; corrige las dos vulnerabilidades.
- WordPress 6.8: actualizar a 6.8.6; el aviso oficial indica que esta rama está afectada por la primera vulnerabilidad.
- Versiones anteriores a 6.8: el aviso oficial señala que no están afectadas por estos dos fallos concretos. Eso no las convierte en una buena elección: una rama antigua puede contener otras vulnerabilidades o carecer de soporte.
- WordPress 7.1 beta: no es para producción; el proyecto publicó 7.1 beta 2 con las correcciones.
Las actualizaciones automáticas de segundo plano pueden haber aplicado el parche, pero no deben darse por supuestas. Un hosting, una política de mantenimiento, permisos de archivos o una personalización pueden impedir que la actualización se complete. Comprueba la versión real desde Escritorio → Actualizaciones o desde Escritorio → Actualizaciones → Comprobar de nuevo.
Plan de actuación: 30 minutos bien invertidos
- 1. Haz una copia recuperable. Comprueba que tienes backup de archivos y base de datos, y que sabes dónde restaurarlo. Una copia que nunca se ha probado es solo una expectativa.
- 2. Verifica la versión. Anota la rama y la versión actual antes de tocar nada. Si gestionas varios sitios, empieza por los que reciben más tráfico, procesan formularios, pagos o datos personales.
- 3. Aplica el parche del core. Instala la actualización de seguridad correspondiente. Evita aprovechar la misma ventana para cambiar muchos plugins, tema y PHP a la vez: separar cambios reduce el tiempo de diagnóstico si algo falla.
- 4. Valida lo esencial. Abre portada, una entrada, formulario de contacto, búsqueda, acceso de usuarios y cualquier conversión crítica. Revisa también los registros de error del servidor y de WordPress.
- 5. Revisa extensiones. Actualiza plugins y temas desde fuentes fiables, elimina los abandonados y borra los que no uses. Desactivar no es lo mismo que eliminar: el código sigue presente.
- 6. Documenta el resultado. Registra versión anterior, hora, copia utilizada y comprobaciones. En la siguiente alerta, esa información reduce el tiempo de respuesta.
Errores que retrasan la protección
El primer error es esperar a una «ventana perfecta». En seguridad, una actualización crítica conocida tiende a perder margen con el tiempo. El segundo es actualizar sin copias ni plan de vuelta atrás. El tercero es convertir la intervención en una reforma completa del sitio; si hay que corregir algo, conviene saber si procede del core, de un plugin, de un tema o de un cambio de configuración.
También es mala práctica exponer administración, REST, XML-RPC o credenciales con más permisos de los necesarios. El parche es imprescindible, pero debe convivir con MFA para administradores, cuentas separadas, contraseñas únicas, mínimos privilegios, WAF cuando encaje y monitorización de actividad. La seguridad no es una casilla, es una serie de capas.
Cómo reducir el impacto de la próxima alerta
- Activa y supervisa actualizaciones menores automáticas cuando tu entorno lo permita.
- Mantén un inventario de versiones de WordPress, plugins, temas y PHP.
- Establece una ventana periódica de mantenimiento y una ruta de escalado para avisos críticos.
- Prueba restauraciones y actualizaciones en un staging si el sitio tiene comercio, reservas o integraciones complejas.
- Mide los servicios que realmente importan: disponibilidad, formularios, ventas, rendimiento y errores.
La actualización publicada por WordPress es una oportunidad para revisar el proceso, no solo el botón de actualizar. Si no puedes dedicar tiempo a seguir boletines, probar parches y validar que la web sigue vendiendo o captando contactos, en allado.es pueden ayudarte a plantear un mantenimiento WordPress seguro, con copias, actualizaciones y comprobaciones posteriores.
Qué revisar si la actualización automática ya se aplicó
Una actualización automática correcta no cierra el trabajo. Comprueba el correo administrativo de WordPress y el registro de actualizaciones, revisa que la versión instalada coincide con la rama corregida y confirma que no hay tareas pendientes. Después, valida desde fuera de tu sesión habitual: abre el sitio en una ventana privada, envía una prueba de formulario y revisa las páginas que sostienen ingresos o contactos. Si tienes caché, CDN o un optimizador, purga solo después de comprobar que la actualización terminó y vuelve a calentar las páginas principales.
Por último, busca usuarios administradores inesperados, cambios recientes en plugins y errores anómalos en los logs. Estas comprobaciones no demuestran que no haya habido un incidente, pero convierten una actualización reactiva en una respuesta ordenada y permiten detectar antes una anomalía que requiera análisis adicional.