El viernes 17 de julio de 2026, mientras muchos revisaban el fin de semana, WordPress activó actualizaciones automáticas forzadas en millones de instalaciones. No fue un aviso suave en el panel: fue un parche de emergencia contra wp2shell, una cadena de dos vulnerabilidades (CVE-2026-63030 y CVE-2026-60137) que permite ejecución remota de código sin autenticación. Yo lo vi en clientes que tenían desactivadas las actualizaciones automáticas y, aun así, amanecieron con la 7.0.2 instalada. Eso no es lo habitual.
La cadena combina una confusión de rutas en la REST API con una inyección SQL en el parámetro author__not_in de WP_Query. Según BleepingComputer, afecta a WordPress 6.9.0–6.9.4 y 7.0.0–7.0.1. En pocas horas aparecieron exploits públicos en GitHub. Cloudflare desplegó reglas WAF el mismo día; el CERT francés publicó alerta el lunes 20. Cuando el parche llega un viernes por la tarde y el PoC aparece esa misma noche, no estamos ante un CVE más: estamos ante la prueba de que el ecosistema WordPress sigue siendo un blanco demasiado grande.
Lo que me preocupa no es solo la gravedad técnica. Es lo que pasa después del parche.
La actualización forzada: necesaria, pero opaca
WordPress tiene mecanismo de actualizaciones automáticas de seguridad desde hace años, pero rara vez los usa de forma tan agresiva. En esta ocasión, según el análisis de Patrowl, el equipo de seguridad activó el despliegue forzado en instalaciones compatibles. Bien hecho, en abstracto: un RCE pre-auth en core no admite esperar a que el cliente lea el email del lunes.
Pero piénsalo desde la perspectiva de quien mantiene webs en producción. Tienes un plugin de facturación que no ha pasado QA con la 7.0.2. Tienes una plantilla con overrides en functions.php que nadie ha tocado desde 2024. Tienes un cliente que te prohibió actualizar sin aviso previo porque la última vez se rompió el checkout. Y de repente, a las 20:00 de un viernes, el core salta de versión solo.
En mi experiencia, la mitad de los problemas post-parche no vienen del propio core sino de la combinación core + plugins + hosting mal configurado. La actualización forzada resuelve el agujero de seguridad y puede abrir otro distinto: una web caída el sábado por la mañana, con el cliente llamando y el proveedor de hosting respondiendo con un ticket automático que dice «su WordPress está actualizado, problema resuelto».
Lo que tu proveedor de hosting no te cuenta
He revisado varios paneles de clientes en Plesk y cPanel esta semana. El patrón se repite: el hosting muestra «WordPress 7.0.2 ✓» como si fuera una medalla, pero no dice si comprobó compatibilidad de plugins, si hay copia de seguridad previa al parche, ni si el WAF del proveedor filtró intentos de explotación antes de que tú parchearas.
Algunos hostings españoles han enviado emails genéricos del tipo «hemos protegido su sitio». Protegido contra qué, exactamente? Contra wp2shell en core, sí. Pero si tu instalación llevaba meses sin actualizar plugins, el vector de entrada puede seguir ahí por otro lado. El parche de core no sustituye una auditoría; solo cierra esta puerta concreta.
Tampoco te cuentan que la actualización forzada puede haber saltado tu política interna. Si gestionas webs de terceros bajo contrato de mantenimiento, ¿tu SLA cubre cambios de versión de core sin consentimiento previo? Yo creo que muchos contratos no lo contemplan, y eso es un problema legal además de técnico.
¿Funcionó el parche? Depende a quién le preguntes
Patrowl documenta la cronología hora a hora: parche el viernes 17, señales de explotación el sábado 18, PoC público esa misma madrugada. WordPress publicó el comunicado oficial de la 7.0.2 el mismo día. La respuesta fue rápida para los estándares del proyecto.
Lo que no cuadra del todo es la percepción de calma posterior. El miércoles 22 salió la beta 3 de WordPress 7.1, con más de 71 correcciones y un debate aparte sobre si incluir o no soporte de email Unicode (Mullenweg lo sacó por preocupaciones de seguridad). El proyecto sigue avanzando como si nada, mientras miles de instalaciones en 6.8.x ni siquiera entran en el ciclo de actualizaciones automáticas forzadas de la misma forma.
Y aquí está la grieta que nadie quiere mirar: WordPress 6.8 sigue teniendo usuarios activos. El parche llegó también en 6.8.6, pero las instalaciones fuera de soporte o en hostings que congelan versiones antiguas no reciben el mismo tratamiento. El ecosistema queda partido: los que están al día sobreviven, los que no, se convierten en botnet potencial.
Qué haría yo esta semana (y qué no haría)
Primero, verificar versión real en cada instalación, no confiar en el panel del hosting. Segundo, revisar logs del fin de semana del 18–19 de julio buscando peticiones sospechosas a /wp-json/ o patrones de SQL injection. Tercero, comprobar que plugins críticos (WooCommerce, constructores, cache) siguen funcionando tras la 7.0.2.
Lo que no haría: dar por cerrado el tema porque «WordPress ya se actualizó solo». Lo que no haría tampoco: culpar al core sin revisar tu propio descontrol de plugins obsoletos. Wp2shell es un recordatorio de que el 43% del internet corre WordPress y eso tiene un precio: cuando sale un CVE de core, el impacto es industrial.
Me parece irónico que la misma semana hablemos de IA hackeando Hugging Face de forma autónoma y, en paralelo, un fallo de routing en la REST API de WordPress permita lo mismo a un atacante anónimo. La sofisticación del atacante importa menos que el tamaño del blanco. Y WordPress sigue siendo enorme.
Si tu proveedor te garantiza que «con el parche automático no tienes de qué preocuparte», pregúntale qué pasa si mañana el parche automático rompe tu tienda online un sábado a las 9 de la mañana en plena campaña de rebajas: ¿quién restaura, en cuánto tiempo, y con qué copia?