Qué hace realmente wp2shell
Cuando Adam Kues, de Assetnote, envió una petición manipulada a una instalación normal de WordPress, el servidor ejecutó su código. Sin cuenta, sin contraseña, sin plugin, sin ningún ajuste raro. Los investigadores llamaron a la cadena wp2shell, WordPress le asignó CVE-2026-63030 y ambas partes la calificaron de crítica.
El exploit encadena dos debilidades en la ruta por lotes de la REST API: una confusión de enrutado que permite a quien no ha iniciado sesión alcanzar rutas de código que deberían estar protegidas, y una inyección SQL accesible a través de ella. Encadenadas, convierten una petición HTTP anónima en ejecución de código, el peor resultado posible de un fallo web.
Por qué el parche automático no es la meta
WordPress publicó 6.9.5 y 7.0.2 el 17 de julio de 2026 y, dada la gravedad, forzó las actualizaciones en los sitios afectados en lugar de esperar a que el propietario hiciera clic. Es la decisión correcta y la mayoría de los sitios ya están cerrados. También oculta la pregunta más difícil.
Un fallo sin autenticación significa que cualquiera en internet pudo usarlo antes de que usted parcheara, e instalar la corrección no revierte eso. Si su sitio estaba accesible y sin parchear durante la ventana de exposición, la actualización quitó la puerta pero no lo que ya había entrado: un usuario administrador colado, una tarea programada, una webshell en la carpeta de subidas.
Por qué casi todo propietario está afectado
Esto vivía en el núcleo, el software que ejecuta cada sitio WordPress, así que la exposición no dependía de un plugin o un tema poco común. WordPress mueve cerca del 40 por ciento de la web, y por eso un único fallo del núcleo de esta clase es un evento masivo y no un caso aislado.
Las versiones 6.9.0 a 6.9.4 y 7.0.0 a 7.0.1 eran vulnerables a wp2shell. El segundo fallo, una inyección SQL en el parámetro author__not_in de WP_Query con CVSS 9.1, se remonta a 6.8, de modo que un sitio que dejó de actualizar durante unos meses cargaba la mayor de las dos ventanas de exposición.
En qué lo convierten las normas de la UE
Para una empresa europea el fallo no es solo técnico. Si hay datos personales detrás de ese sitio, el RGPD le da 72 horas para notificar a su autoridad de control en cuanto tenga conocimiento de una brecha, y 'no podemos descartarlo' está más cerca de ese conocimiento que de la tranquilidad.
Para entidades esenciales e importantes bajo NIS2, un incidente de esta gravedad activa su propio reloj de alerta temprana y notificación, y los reguladores esperan cada vez más pruebas de detección, no solo un registro del parche. Una actualización automática forzada es una defensa que usted no eligió; si después comprobó si hubo compromiso es lo que sí consta en su registro.
La comprobación que toca hacer ahora
Confirme que el sitio está en 6.9.5 o 7.0.2 y trate luego la ventana de exposición como el trabajo real. Revise cuentas de administrador y contraseñas de aplicación creadas en julio, inspeccione tareas programadas y archivos PHP modificados hace poco, y saque los registros del servidor web en busca de peticiones POST inusuales a la REST API alrededor de la fecha de divulgación.
Si usa WordPress gestionado, pida a su proveedor por escrito cuándo llegó el parche y si vio intentos de explotación contra su sitio. La respuesta honesta a 'nos alcanzaron' rara vez es inmediata, pero los propietarios que preguntan esta semana son los que no estarán explicando una brecha silenciosa el próximo trimestre.
Leer a continuación: Un edificio inutilizado cuesta más que un rescate | Atacaron su sandbox un mes antes del aviso
