Si llevas años gestionando webs en WordPress, seguro que tienes instalado Wordfence, Sucuri, iThemes Security o algún equivalente. Lo pagas, lo actualizas, te llegan alertas cada dos por tres y te quedas más tranquilo. Yo también lo hice durante mucho tiempo. Hasta que wp2shell ha demostrado, otra vez, que esa tranquilidad es en gran parte teatro.
El 17 de julio de 2026 WordPress publicó parches de emergencia para dos vulnerabilidades en el núcleo — CVE-2026-63030 y CVE-2026-60137 — que encadenadas permiten ejecutar código remotamente sin autenticación. No hace falta plugin vulnerable, no hace falta contraseña débil, no hace falta que el administrador haga clic en nada. Una instalación limpia, con todos tus plugins de seguridad activos y al día, era igual de explotable que una web sin protección. Matt Mullenweg lo resumió con una frase que me ha quedado grabada: este tipo de RCE pre-autorización es algo que en 23 años de WordPress apenas hemos visto un par de veces.
Y aquí viene lo incómodo. Durante la última década, la industria del hosting y las agencias hemos vendido — o recomendado — plugins de seguridad como la primera línea de defensa. Te prometen escaneos de malware, firewall de aplicación, bloqueo de IPs, alertas en tiempo real. Suena bien. Cuesta dinero, pero «¿cuánto vale la tranquilidad?». El problema es que wp2shell no pasa por la puerta que esos plugins vigilan.
El agujero estaba en el core, no en tu plugin de confianza
La cadena de ataque explota el endpoint REST de batch (/wp-json/batch/v1) y una inyección SQL en parámetros del core. Todo dentro de WordPress, sin tocar código de terceros. Según BleepingComputer, en cuestión de días aparecieron exploits públicos en GitHub y se confirmó explotación activa en la wild. Tenable lo documenta igual: parches en 7.0.2 y 6.9.5, actualizaciones forzadas activadas desde WordPress.org, y recomendaciones de bloquear el endpoint en el WAF si no puedes parchear al momento.
¿Qué hace tu plugin de seguridad aquí? En la mayoría de casos, nada útil hasta que el daño ya está hecho. Wordfence puede detectar el archivo malicioso que subió el atacante después de explotar la RCE. Sucuri puede limpiarte la web cuando ya te han metido un backdoor. Pero la vulnerabilidad que abrió la puerta no la parchean ellos: la parchea Automattic en el core, o no se parchea.
Lo peor es que esto no es nuevo. Cada vez que sale un CVE grave en el núcleo — y wp2shell es de los más serios — la conversación vuelve a los mism sitios: «¿tenías el plugin actualizado?», «¿el firewall estaba en modo aprendizaje?». Como si la culpa fuera de la configuración del cliente y no de que el software base tenía un agujero del tamaño de un camión.
Defensa en profundidad… si alguien la paga de verdad
Mullenweg reconoce en su post que hosts y CDNs mitigaron el ataque a nivel de red antes de que muchos parchearan. Eso es defensa en profundidad de verdad: Cloudflare, Kinsta, WP Engine y compañía bloqueando patrones en el WAF, actualizaciones automáticas forzadas desde WordPress.org. Funciona. Pero tu plugin de 99 euros al año instalado en un hosting compartido de 5 euros no es lo mismo.
He visto tiendas online con Wordfence Premium, SiteLock y backup en la nube, alojadas en un servidor compartido sin WAF, sin staging y con PHP desactualizado. Es como poner cinco cerraduras en una puerta de cartón. El plugin genera informes bonitos, te manda emails con gráficos, y tú crees que estás protegido. Hasta que llega un CVE del core y descubres que la única defensa real era actualizar WordPress — algo que podías hacer gratis.
Y no me vale el argumento de que «el plugin te avisa de actualizaciones pendientes». WordPress ya te avisa. El escudo de administración te grita en rojo cuando hay una versión de seguridad. El plugin añade una capa de ruido, no de protección estructural.
El negocio de la seguridad periférica
Los plugins de seguridad facturan millones porque venden miedo de forma elegante. Te muestran intentos de login bloqueados (la mayoría bots genéricos que no iban a entrar de todos modos), te alertan de archivos modificados (a veces falsos positivos de actualizaciones legítimas), te venden limpieza de malware como servicio premium. Todo eso tiene valor marginal. Lo crítico — mantener el core, temas y plugins actualizados, usar contraseñas fuertes, limitar acceso admin, tener backups probados — cuesta poco o nada.
Después de wp2shell, lo que más me preocupa no es la vulnerabilidad en sí — eso pasa en cualquier software maduro — sino la dependencia psicológica que hemos creado. Clientes que pagan 200 euros anuales en plugins de seguridad pero se resisten a pagar 30 euros más al mes por un hosting gestionado con WAF real. Agencias que instalan Wordfence en todas las webs del portfolio porque «es lo que se hace», sin revisar si el hosting ya filtra en el edge.
Mullenweg apunta en la misma dirección: la seguridad va a ser un tema central en 2026 porque la IA acelera tanto el descubrimiento como la explotación de fallos. Los plugins que escaneaban firmas de malware de hace tres años no van a servir contra ataques orquestados por modelos que encadenan vulnerabilidades solos — sí, como hizo OpenAI con Hugging Face la misma semana. El escenario se complica, y seguir vendiendo placebos no es una estrategia.
Qué haría yo (y qué no)
Actualizar el core inmediatamente. Siempre. Sin excusas de «la web se rompe con la 7.0.2». Montar staging, probar, desplegar. Bloquear /wp-json/batch/v1 en el WAF si tu versión aún no está parcheada. Limitar el REST API a usuarios autenticados si no lo necesitas público. Backups offsite diarios con restauración probada — no «tengo un plugin de backup», sino «he restaurado una copia este mes y funciona».
Lo que no haría: contratar otro plugin de seguridad «más potente» como respuesta al pánico. Cambiar de Wordfence a Solid Security no arregla un CVE del core. Lo que arregla un CVE del core es el parche de Automattic, punto.
Si tu plugin de seguridad te sirve para auditoría interna, cumplimiento o tener un log centralizado, adelante. Pero deja de venderlo — o de comprarlo — como escudo principal. wp2shell ha demostrado que el escudo estaba en el hosting, en el WAF y en la actualización del core. Todo lo demás es cosmética cara.
Fuentes
- Important Security Update | Matt Mullenweg
- WordPress Core «wp2shell» RCE flaws get public exploits, patch now | BleepingComputer
- wp2shell: WordPress Core Pre-Auth RCE FAQ | Tenable
Si mañana tu hosting te ofreciera quitar el WAF del plan y regalarte una licencia vitalicia de Wordfence Premium, ¿aceptarías el trato sabiendo lo que wp2shell ha demostrado sobre dónde está la protección real?