Ayer Searchlight Cyber soltó una bomba que debería tener a todo el que administra un WordPress pegado al teclado: wp2shell, una vulnerabilidad de ejecución remota de código sin autenticación en el core de WordPress. No en un plugin tercero ni en un theme pirata. En el core mismo.
Los números asustan: se estima que más de 500 millones de sitios corren WordPress. Un RCE pre-auth en ese ecosistema no es una noticia más del montón, es una alarma roja para caleta de infraestructura, desde el blog personal hasta tiendas WooCommerce que mueven millones de dólares al año.
Qué es exactamente wp2shell
Adam Kues, el investigador que la descubrió, la describe como un bug sin precondiciones: cualquier usuario anónimo puede explotarla en una instalación stock de WordPress, sin plugins. Afecta a las versiones 6.9.0 a 6.9.4 (arreglada en 6.9.5) y 7.0.0 a 7.0.1 (arreglada en 7.0.2). Si tu versión es menor a 6.9.0, respiras tranquilo por ahora.
El vector de ataque pasa por el endpoint de batch del REST API: /wp-json/batch/v1. Por eso las mitigaciones de emergencia apuntan directo ahí: bloquear esa ruta en el WAF, desactivar el REST API para usuarios no autenticados, o instalar un plugin mínimo que rechace requests anónimos al batch endpoint.
Lo preocupante: SQL con string formatting en 2026
Uno de los comentarios en Lobsters lo resume perfecto: estamos en 2026 y todavía estamos construyendo queries SQL con string formatting. Es verdad, po. Después de décadas de prepared statements, ORMs, linters, y toda la literatura de seguridad que existe, el CMS más usado del planeta sigue cayendo en el mismo error de siempre.
Y aquí va mi opinión personal: esto no es solo un problema de WordPress. Es un síntoma de la industria completa. Seguimos priorizando velocidad de desarrollo sobre higiene de código. Los code reviews pasan rápido, los tests de seguridad son un checkbox, y la deuda técnica se acumula hasta que alguien como Kues encuentra la grieta. La diferencia es que WordPress, por su escala, no puede darse el lujo de fallar así.
Qué hacer ahora
Si administras sitios WordPress, la pega es simple pero urgente:
1. Actualiza ya. WordPress 7.0.2 o 6.9.5 según tu rama. No hay excusa válida para no hacerlo hoy.
2. Si no puedes actualizar de inmediato, aplica una mitigación: bloquea /wp-json/batch/v1 y rest_route=/batch/v1 en tu WAF o .htaccess.
3. Revisa tus logs. Busca requests sospechosos al endpoint de batch. El equipo de Searchlight no soltó detalles técnicos todavía, pero el diff entre 7.0.1 y 7.0.2 está público en GitHub, así que es cosa de tiempo para que los exploits se masifiquen. De hecho, ya hay un PoC circulando en GitHub.
4. Verifica si eres vulnerable. Searchlight tiene un checker en wp2shell.com donde puedes escanear tu sitio directamente.
Reflexión final
Estos bugs me hacen pensar en la fragilidad del stack que usamos todos los días. WordPress tiene más de 20 años y una comunidad gigante, pero la superficie de ataque crece más rápido que la madurez del código. Como ingeniero de sistemas, mi recomendación es siempre la misma: automatiza las actualizaciones de seguridad, monitorea tus logs como un obsesivo, y nunca asumas que porque algo es popular es seguro. La seguridad no es un estado, es un proceso continuo. Y wp2shell es el recordatorio perfecto de eso.
Fuente de inspiración: wp2shell: Pre Authentication RCE in WordPress Core
