TL;DR:
- WordPress lanzó parches de emergencia y activó actualizaciones forzadas; varias firmas de ciberseguridad ya confirmaron ataques reales en curso.
- Un cálculo citado por TechCrunch estima decenas de millones de sitios aún expuestos, con una proyección cercana a los 90 millones que no es un conteo oficial.
- Encadenadas, las dos fallas (bautizadas WP2Shell) permiten ejecución remota de código sin autenticación y el control total del sitio.
Los hackers ya están entrando a sitios web que corren versiones desactualizadas de WordPress, el gestor de contenidos más usado de internet. Varias firmas de ciberseguridad lo confirmaron: la explotación es real y está en curso. La semana pasada, el 17 de julio de 2026, WordPress publicó parches de emergencia para dos fallas graves y pidió actualizar de inmediato. La gravedad fue tal que el proyecto activó actualizaciones automáticas forzadas. Encadenadas, esas dos vulnerabilidades (bautizadas WP2Shell) permiten que un atacante sin credenciales tome el control total de un sitio. Un cálculo citado por TechCrunch estima que decenas de millones de instalaciones siguen expuestas. Si administras un sitio en WordPress, la tarea de hoy es una sola: confirmar que estás en una versión con parche.
WP2Shell es el nombre que la firma Searchlight Cyber le puso al par de vulnerabilidades que descubrió en el núcleo de WordPress. La primera, registrada como CVE-2026-63030, es una falla crítica de ejecución remota de código en la REST API del gestor. La segunda, CVE-2026-60137, es una inyección SQL de severidad alta. Por separado ya son un problema. Juntas son el escenario que ningún administrador quiere: según Searchlight Cyber, Cloudflare y el propio equipo de WordPress, encadenarlas permite ejecutar código sin autenticación y quedarse con el sitio completo. No hace falta iniciar sesión ni que la víctima haga nada.
Lo más incómodo es lo fácil que resulta. Así lo resumió la propia firma que las encontró:
"El ataque no tiene condiciones previas y puede ser explotado por un usuario anónimo en una instalación estándar de WordPress sin plugins."
Cuántos sitios siguen en riesgo
Nadie tiene la cifra exacta, pero los números disponibles ponen la escena en perspectiva. WordPress mueve una porción enorme de la web, y eso convierte cualquier falla del núcleo en un problema de millones.
De acuerdo con TechCrunch, un cálculo ubicaba en decenas de millones los sitios vulnerables el lunes. El consultor de ciberseguridad Daniel Card revisó una muestra de unos 4,200 sitios con WordPress y estimó que menos del 15% seguía expuesto; llevada esa proyección al total de instalaciones, la cuenta rondaría los 90 millones, según el mismo reporte. Son estimaciones, no un conteo oficial: las estadísticas públicas de WordPress hablan de más de 400 millones de sitios corriendo versiones afectadas, aunque ese dato no distingue a los que ya se parchearon.
Cómo saber si tu sitio está en riesgo y qué hacer
El rango afectado está acotado. Las versiones vulnerables al ataque completo son las 6.9.0 a 6.9.4 y las 7.0.0 a 7.0.1. WordPress corrigió el problema en la 7.0.2 y lo respaldó con los backports 6.9.5, 6.8.6 y 7.1 Beta 2. Las versiones anteriores a la 6.8 quedan fuera.
Como el equipo de WordPress clasificó esto en su nivel de máxima prioridad, forzó las actualizaciones automáticas, así que buena parte de los sitios ya se corrigió sola. Aun así, conviene no dar nada por hecho y verificar la versión a mano desde el panel de administración.
Cloudflare sumó una segunda capa. La compañía recibió el aviso antes de la publicación y desplegó reglas en su firewall de aplicaciones (WAF) que bloquean los intentos de explotación, tanto para clientes de pago como del plan gratuito cuyo tráfico pasa por su red. El matiz importante lo puso la propia Cloudflare: el firewall reduce la exposición mientras actualizas, pero no reemplaza al parche. Actualizar sigue siendo la única solución de fondo.
De la revelación al ataque en cuestión de horas
Hay un dato que vuelve a este caso más que una alerta de rutina: la velocidad. Searchlight Cyber no publicó detalles técnicos para evitar el abuso, pero otros sí difundieron pruebas de concepto funcionales, y los ataques arrancaron poco después de la revelación. La firma Patchstack confirmó la explotación activa. Hexastrike empezó a ver intentos en sus honeypots durante el fin de semana y el domingo ya asistía en la respuesta a varios incidentes. WatchTowr también registró intentos en la práctica.
Benjamin Harris, director y fundador de WatchTowr, no lo suavizó al hablar con SecurityWeek:
"Esto va a doler. WordPress corre en cientos de millones de sitios en todo el mundo. Algunos serán parcheados automáticamente por sus proveedores de hosting, pero muchos no, y ahí es donde se hará el daño."
Harris apuntó a algo de fondo: este es otro ejemplo de una tendencia clara de fallas detectadas con herramientas asistidas por inteligencia artificial, un giro en cómo la industria encuentra estos huecos y en la rapidez con que los atacantes los convierten en armas. Contó a SecurityWeek que las pruebas de concepto aparecieron en cuestión de horas, cuando antes eso tomaba un día o más. La ventana entre que un fallo se revela y empieza a explotarse, dijo, se comprimió, y WordPress es apenas el recordatorio de turno.
Para cualquiera que administre un sitio en WordPress dentro del mundo hispanohablante, el mensaje es directo: las actualizaciones forzadas y el firewall ayudan, pero la responsabilidad de confirmar la versión sigue siendo tuya, y la ventana para hacerlo se mide en horas, no en días. El episodio deja además una señal sobre lo que viene. Cuando hallar y explotar una falla se acelera con IA, la ventaja se inclina hacia quien parchea primero.
