En el ecosistema de la seguridad web, pocas noticias generan tanta urgencia como las fallas críticas en el núcleo (core) de WordPress. Recientemente se ha dado a conocer wp2shell, un vector de ataque que permite a atacantes anónimos (sin autenticación previa) ejecutar código de forma remota (RCE) en instalaciones por defecto, sin necesidad de que el sitio tenga plugins o temas vulnerables instalados.
Con más del 40% de la web funcionando sobre WordPress, este hallazgo pone de manifiesto una verdad fundamental: la seguridad no es un estado estático, sino una carrera continua contra el tiempo.
¿Qué es wp2shell y cómo funciona?
El ataque wp2shell combina dos fallos de seguridad independientes que, encadenados, permiten saltarse todas las barreras de autenticación del sistema y ejecutar código malicioso en el servidor web.
- Confusión de rutas en la API REST (CVE-2026-63030): Descubierto por Adam Kues de Assetnote (Searchlight Cyber), este fallo reside en el endpoint de procesamiento por lotes (
/wp-json/batch/v1). Una inconsistencia en el manejo de peticiones secundarias desalinea el procesamiento, permitiendo a un usuario no autenticado saltarse la lista de verificación e interactuar con controladores internos. - Inyección SQL en
WP_Query(CVE-2026-60137): Ubicado en el parámetroauthor__not_indel núcleo de WordPress. Al enviar una cadena de texto en lugar del array esperado, el control interno falla y el parámetro se inyecta directamente en la consulta SQL.
Al unir ambas vulnerabilidades, una simple petición HTTP anónima puede pasar del endpoint público hasta la inyección y, finalmente, a la ejecución remota de código (RCE) en la máquina hospedadora.
Versiones afectadas
A diferencia de otros incidentes donde un plugin mal mantenido es el culpable, wp2shell habita directamente en las tripas de WordPress:
- WordPress 6.9.0 a 6.9.4: Afectadas por la cadena RCE completa. Corregido en 6.9.5.
- WordPress 7.0.0 a 7.0.1: Afectadas por la cadena RCE completa. Corregido en 7.0.2.
- WordPress 6.8.0 a 6.8.5: Afectadas únicamente por la inyección SQL. Corregido en 6.8.6.
Nota importante: La vulnerabilidad de RCE afecta principalmente a instalaciones estándar sin un sistema de caché de objetos persistente activo (como Redis o Memcached). No obstante, depender de la caché como barrera de defensa no es una solución adecuada, ya que no elimina la inyección SQL subyacente.
La urgencia: El código de explotación (PoC) ya es público
WordPress reaccionó con rapidez forzando actualizaciones automáticas hacia las versiones corregidas (6.9.5 y 7.0.2). Sin embargo, la naturaleza del código abierto implica que, una vez publicado el parche, los investigadores (y los atacantes) pueden analizar las diferencias en el código fuente (diffing) para reconstruir la falla.
Actualmente, ya existen demostraciones de concepto (PoC) públicas en GitHub, lo que reduce drásticamente el tiempo de reacción para los administradores de sistemas y webmasters. Grupos de explotación masiva suelen automatizar el escaneo de estas vulnerabilidades en cuestión de horas o días.
¿Cómo proteger tu servidor y sitio web?
Si gestionas infraestructura o sitios en WordPress, debes tomar medidas inmediatas para mitigar el riesgo:
1. Actualiza inmediatamente (Acción prioritaria)
Verifica de forma manual que tu instalación haya aplicado el parche y se encuentre en WordPress 6.9.5, 7.0.2 o superior. Aunque WordPress utiliza actualizaciones forzadas, configuraciones personalizadas de permisos de archivos o desactivaciones del sistema de auto-update pueden haber bloqueado el parche.
2. Bloqueo en el WAF o Firewall de aplicación
Si no puedes actualizar de inmediato por compatibilidad o ciclos de despliegue, aplica reglas en tu WAF (como Cloudflare, ModSecurity o NGINX) para denegar el acceso a las siguientes rutas:
/wp-json/batch/v1- Cadenas de consulta que contengan
rest_route=/batch/v1
(Es crítico bloquear ambas vías, ya que cubrir únicamente la ruta URL deja expuesto el parámetro por consulta).
3. Mitigación temporal mediante código
Si necesitas mantener la API REST activa para otros servicios, puedes implementar un parche temporal interceptando solicitudes en el gancho rest_pre_dispatch para rechazar consultas anónimas dirigidas al endpoint /batch/v1.
Conclusión
El caso wp2shell demuestra la importancia crítica de contar con planes de parcheo automatizados, monitoreo de infraestructura y una arquitectura de red con capas de protección (WAF, políticas de mínimo privilegio y aislamiento de procesos). En el panorama actual de ciberseguridad, asumir que un sitio está seguro simplemente por “no tener plugins instalados” es un riesgo que ningún administrador se puede permitir.
Si te gustó este artículo, suscríbete a nuestro canal de YouTube para videos tutoriales de Hosting, prácticas y demás. También puede encontrarnos en X (Twitter), Facebook e Instagram.
