Un backdoor se coló en un plugin de WordPress con 20.000 instalaciones — y una IA lo detectó en menos de dos horas

WordPress mueve una porción enorme de todo internet, y buena parte de lo que lo hace tan flexible —la posibilidad de instalar cualquiera de los miles de plugins disponibles— es también su punto más débil. El 28 de julio de 2026 quedó documentado un caso que ilustra bien ese riesgo: el plugin "Advanced Responsive Video Embedder", con cerca de 20.000 instalaciones activas, fue modificado en su versión 10.8.7 para incluir una puerta trasera de autenticación deliberada, no un simple error de programación.

El mecanismo técnico, registrado como CVE-2026-18072 con una puntuación de severidad de 9.8 sobre 10 (crítica), se escondía en una función llamada _arve_uc_init(). Esa función procesaba parámetros especiales en las peticiones que llegaban al sitio y los validaba contra un hash SHA-256 incrustado directamente en el código — en la práctica, un atacante que conociera ese valor secreto podía obtener acceso completo de administrador sin necesidad de usuario ni contraseña. No es el tipo de falla que se cuela por descuido: es un ataque de cadena de suministro, el mismo patrón que ya se ha visto en otros ecosistemas de código abierto, donde el compromiso no ocurre en el sitio de la víctima sino en el propio software que miles de sitios ya tenían instalado y en el que confiaban.

Lo que hace este caso distinto de la mayoría de los reportes de seguridad que cubrimos aquí es la velocidad de la respuesta. Chloe Chamberland, del equipo de Wordfence, identificó el código malicioso usando PRISM, el sistema de inteligencia de amenazas de la compañía basado en IA, en menos de dos horas desde que el backdoor se introdujo en el plugin. Para dimensionar lo que eso significa: la mayoría de las vulnerabilidades de este tipo tardan días o semanas en descubrirse, tiempo durante el cual cualquier sitio que actualice el plugin automáticamente queda expuesto sin saberlo. Dos horas es, en términos de esta industria, casi instantáneo. El equipo de WordPress.org retiró el plugin del repositorio oficial el mismo día, y Wordfence desplegó reglas de firewall para sus clientes de pago de inmediato — la protección para usuarios de la versión gratuita de Wordfence está programada recién para el 27 de agosto, casi un mes después de la detección.

Ese último detalle es el que vale la pena que cualquiera que use WordPress se lleve de esta historia, más allá de la anécdota de la IA detectando algo rápido: existe una brecha real de casi treinta días entre la protección que reciben quienes pagan por una herramienta de seguridad y quienes usan la versión gratuita del mismo sistema. Wordfence no está haciendo nada incorrecto — es un modelo de negocio legítimo y común en seguridad—, pero si administras un sitio en WordPress con plugins de terceros y solo cuentas con la protección gratuita de turno, la realidad es que tu ventana de exposición ante un caso como este es semanas, no horas.

La lección práctica no es "desconfía de todos los plugins" —eso haría inutilizable la mitad de lo que hace útil a WordPress—, sino tratar cada plugin instalado como una pieza de software que puede cambiar de comportamiento sin que tú lo pidas, y actuar en consecuencia: mantén el número de plugins activos al mínimo real que necesitas (cada uno es una superficie de ataque adicional, no solo una función extra), revisa qué plugins tienen actualizaciones recientes sospechosamente frecuentes o cambios de mantenedor, y si tu sitio maneja algo sensible —pagos, datos de clientes—, invertir en la capa de seguridad de pago que te da protección el mismo día, no un mes después, deja de ser un gasto opcional.