- El mismo atacante compró más de 30 plugins de WordPress y, en el primer commit, insertó código de puerta trasera, infectando la cadena de suministro
- El código malicioso permaneció latente durante unos 8 meses y se activó a inicios de abril de 2026 para inyectar enlaces de spam y redirecciones en múltiples sitios
- WordPress.org cerró permanentemente 31 plugins relacionados en un solo día, el 7 de abril de 2026, y distribuyó una actualización forzada
- El atacante adquirió el portafolio ‘Essential Plugin’ en Flippa por una suma de seis cifras y usó un smart contract de Ethereum para ocultar el dominio de C2
- Este incidente reproduce un ataque masivo a la cadena de suministro similar al caso de ‘Display Widgets’ de 2017 y deja en evidencia la falta de gestión de confianza en el ecosistema de plugins de WordPress
Caso de ataque a la cadena de suministro de plugins de WordPress
- Más de 30 plugins de WordPress fueron adquiridos por el mismo atacante y luego se les implantó una puerta trasera
- El atacante compró el portafolio ‘Essential Plugin’ en Flippa por una suma de seis cifras y añadió código malicioso en el primer commit
- La puerta trasera permaneció inactiva y oculta durante 8 meses, hasta activarse a inicios de abril de 2026 e infectar numerosos sitios
- WordPress.org cerró permanentemente 31 plugins relacionados en un solo día, el 7 de abril de 2026
- Se considera que este caso repite un patrón de ataque a la cadena de suministro similar al incidente de ‘Display Widgets’ de 2017
Descubrimiento del ataque y respuesta inicial
- La infección inicial se confirmó mediante una alerta de seguridad en wp-admin de un sitio cliente
- El equipo de plugins de WordPress.org advirtió que el plugin “Countdown Timer Ultimate” incluía código que permitía acceso no autorizado
- WordPress.org distribuyó una actualización forzada (v2.6.9.1), pero algunos sitios ya estaban comprometidos
- Una revisión de seguridad mostró que el módulo
wpos-analyticsdel plugin se conectaba a analytics.essentialplugin.com para descargar el archivowp-comments-posts.php, y a través de este se realizaba una inyección masiva de código PHP en wp-config.php
Cómo operaba el malware
- El código inyectado obtenía enlaces de spam, redirecciones y páginas falsas desde el servidor C2 y los mostraba solo a Googlebot
- El atacante usó un smart contract de Ethereum para administrar dinámicamente el dominio de C2
- Como el dominio se consultaba mediante un endpoint RPC de blockchain, no podía bloquearse con un bloqueo de dominio convencional
- La actualización forzada de WordPress.org solo detuvo la función de “phone home” del plugin, pero el código malicioso en
wp-config.phppermaneció intacto
Rastreo del momento de la infección mediante análisis de respaldos
- Usando los respaldos restic de CaptainCore, se comparó el tamaño de 8 archivos
wp-config.phpen distintos momentos- Entre el 6 de abril de 2026 a las 04:22 y las 11:06 UTC, el tamaño del archivo aumentó de 3,345 bytes a 9,540 bytes
- Se confirmó que la infección ocurrió dentro de ese intervalo de 6 horas y 44 minutos
Momento de inserción de la puerta trasera y estructura del código
- En la versión 2.6.7 del plugin (8 de agosto de 2025) se agregaron 191 líneas nuevas de código, momento en que se insertó la puerta trasera
- En el changelog figuraba como “compatibilidad confirmada con WordPress 6.8.2”
- Funciones principales del código añadido
fetch_ver_info()procesa con@unserialize()los datos provenientes del servidor del atacanteversion_info_clean()ejecuta el nombre de función recibido desde los datos remotos- Se crea un endpoint de REST API invocable sin autenticación (
permission_callback: __return_true)
- Esta estructura permite ejecución arbitraria de funciones (RCE) y permaneció inactiva durante 8 meses hasta activarse entre el 5 y 6 de abril de 2026
Proceso de adquisición de los plugins
- El equipo de desarrollo original era WP Online Support, con base en India, y desarrollaba plugins desde 2015
- Más tarde hizo rebranding a Essential Plugin y operó más de 30 plugins gratuitos y de pago
- A fines de 2024, al caer sus ingresos entre 35% y 45%, publicaron a la venta todo el negocio en Flippa
- A inicios de 2025, una persona llamada ‘Kris’ lo adquirió teniendo experiencia en marketing de SEO, criptomonedas y apuestas en línea
- Flippa publicó esta operación en su blog en julio de 2025 como caso de éxito
- Tras la adquisición, el código de puerta trasera se añadió de inmediato en el primer commit a SVN (8 de agosto de 2025)
- Entre el 5 y 6 de abril de 2026,
analytics.essentialplugin.comcomenzó a distribuir la carga maliciosa a todos los sitios - El 7 de abril de 2026, WordPress.org cerró permanentemente todos los plugins de Essential Plugin (31 en total)
Lista de plugins cerrados
- Accordion and Accordion Slider, Countdown Timer Ultimate, Popup Anything on Click, WP Blog and Widgets, WP Team Showcase and Slider y más de 30 plugins
- Al buscar ese autor en WordPress.org ya no aparecen resultados
analytics.essentialplugin.comactualmente devuelve la respuesta{"message":"closed"}
Casos similares en el pasado
- En 2017, una persona llamada ‘Daley Tias’ compró el plugin Display Widgets (con 200 mil instalaciones) por $15,000 e insertó código de spam
- Después infectó más de 9 plugins usando el mismo método
- Este incidente confirma la repetición de la misma táctica, pero a mayor escala (más de 30 plugins)
Recuperación del daño y trabajo de parcheo
- La actualización forzada de WordPress.org fue solo una medida temporal
- El módulo
wpos-analyticsseguía existiendo
- El módulo
- Se creó internamente una versión parcheada que elimina por completo el módulo con puerta trasera
- Entre 22 sitios de clientes, se encontraron plugins de Essential Plugin en 12, y 10 fueron parchados manualmente
- La versión parcheada elimina el directorio
wpos-analytics, quita la función loader y añade-patchedal nombre de versión
- Ejemplos: Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial with Widget, entre otros
Cómo aplicar el parche manualmente
- Eliminar el directorio
wpos-analytics/ - En el archivo principal del plugin, eliminar el bloque “Plugin Wpos Analytics Data Starts” o
wpos_analytics_anl - Añadir
-patchedal encabezadoVersion:y volver a comprimir - Instalar con
wp plugin install your-plugin-patched.zip --force - Si el archivo
wp-config.phpaumentó alrededor de 6 KB, debe considerarse una infección activa y se requiere recuperación completa
Problema de confianza en el ecosistema de plugins de WordPress
- En las últimas 2 semanas se han producido ataques consecutivos a la cadena de suministro
- Se adquieren plugins confiables y luego se les inserta código malicioso
- Se heredan los permisos de commit de WordPress.org y se distribuye sin verificación adicional
- En WordPress.org no existe monitoreo de cambios de propiedad ni un proceso de revisión de código
- No hay alertas para usuarios ni revisión automática cuando se registra un nuevo committer
- Aunque la respuesta del equipo de plugins fue rápida, la puerta trasera no fue detectada durante 8 meses tras su inserción
- Los operadores de sitios WordPress deben revisar su lista de plugins, eliminar o parchear de inmediato los plugins de la familia Essential Plugin y verificar obligatoriamente el archivo
wp-config.php
8 comentarios
WordPress, usándolo desde hace décadas...
Uso solo los plugins mínimos, pero igual siempre me da inquietud.
Aun así, sigue siendo más cómodo que algo estático, así que no quiero migrar.
Últimamente han salido muchas noticias sobre ataques a la cadena de suministro :(
Así es. Ha aumentado drásticamente.
WordPress de verdad... sigue dando problemas. Si ya lo están usando, revisen artículos relacionados como el de EmDash.
Yo ya lo dejé y simplemente me pasé a una página estática.
Probé instalar EmDash, pero por ahora es demasiado lento. El TTFB sale en unos 3 segundos como base, así que te hace preguntarte si de verdad lo hicieron para que alguien lo use.
Ah, ya veo. Entonces yo me conformo con algo estático jaja
Creo que esto hace pensar que la IA podría reemplazar a los CMS cubiertos de código legado para gestionar páginas estáticas.
Comentarios en Hacker News
Siempre me dan risa las reacciones exageradas sobre Mythos
La tecnología automatizada de detección de vulnerabilidades podría sacudir a la industria de la seguridad, pero esa no es la verdadera preocupación
El stack tecnológico actual y la gobernanza corporativa ya están atrasados respecto a los tiempos
Si hubiera que señalar al principal responsable de que la situación empeorara, sería las criptomonedas. Eso convirtió el hacking en una industria de decenas de miles de millones de dólares y hasta involucró a estados como Corea del Norte
Ahora ya estamos en una realidad donde simplemente se pueden comprar dependencias o pagarle a un empleado para inducir un “error”
Podemos escribir software con muy pocos bugs, pero no tenemos ningún plan para mantener seguras a las grandes empresas en este entorno
Los agentes LLM autónomos se usarán en organizaciones de ransomware, pero no hará falta usar exploits de FreeBSD
En la práctica, todas las semanas me topo con bugs en PrimeVue, Vue, Spring Boot, Oracle driver, Ansible, Nvidia driver, etc.
Siendo realistas, el código completamente libre de fallos solo parece posible en aviones o naves espaciales
La mayoría de los desarrolladores no es que no quiera escribir código sin bugs, sino que muchas veces es imposible por las limitaciones del entorno
Esto no es teoría, es la realidad. Con financiamiento a nivel estatal, comprar insiders es mucho más fácil
Los proyectos OSS tienen menos “bugs WTF” que el software de grandes empresas
En un entorno de desarrollo individual no cometerías errores que en una organización se terminan desplegando tal cual por procesos de aprobación o costumbres internas
Una cultura disfuncional donde no se puede preguntar “¿esto es lo mejor?” produce bugs en masa
En equipos pequeños es fácil cambiar eso, pero en organizaciones grandes el costo es alto
Cuando ves proyectos web, casi siempre empiezan con “npm install”, y automáticamente se instalan decenas de librerías
Muchas veces ni el autor sabe qué dependencias transitivas quedaron incluidas
En una estructura así, casi no hay posibilidad de verificar ataques a la cadena de suministro
Hace poco escribí una herramienta de sincronización del clima usando solo la biblioteca estándar de Python
No hizo falta usar paquetes externos como
requests, y obtuve la tranquilidad de no tener dependenciasLógica crítica como criptografía no deberías implementarla por tu cuenta, pero depender de librerías hasta para funciones simples ya es demasiado
Si las versiones están fijadas, aunque un paquete sea vendido y le metan un backdoor, no te afecta hasta que actualices manualmente
De hecho, da más miedo cuando Dependabot te abre automáticamente un PR de “patch version” y te mete el riesgo
sudo curl URL | bashCreo que el problema está en la propia ideología de las actualizaciones
Las actualizaciones tienen la ventaja de traer parches de seguridad, pero al mismo tiempo pueden forzar cambios que el desarrollador no quiere o incluso volverse maliciosas
En especial, creo que a las extensiones de WordPress hechas por desarrolladores individuales nunca se les debería permitir actualización automática
El marketplace de wordpress.org no soporta bien una estructura así, y por eso es riesgoso
Antes escribí un comentario sobre extensiones de Chrome, y si cambias Chrome por WordPress, sigue aplicando exactamente igual
La superficie de ataque de la cadena de suministro en los plugins de WordPress viene siendo riesgosa desde hace mucho
Se debe a la estructura del ecosistema, que incentiva instalar montones de plugins pequeños hechos por desarrolladores individuales
Comprar y luego abusar de un plugin que ya se ganó la confianza de los usuarios es una forma de ataque muy eficiente
Como la “notificación de actualización” funciona como señal de confianza, el usuario ni siquiera sabe que cambió el autor
Hace falta un sistema de firmas de paquetes y transparencia, pero WordPress avanza lento en mejorar su infraestructura de seguridad
El panel de administración llegaba a parecer un meme de barras de herramientas de IE6
Muchas veces instalaban la versión gratuita de Securi o Wordfence, no la configuraban, y aun así esperaban seguridad total
Bloquea malware evidente, pero tolera bait-and-switch como insertar widgets publicitarios desde dominios de terceros
A este nivel, casi hay que verlo como diseño intencional
Es una lástima que el proyecto de package manager FAIR no haya logrado despegar
fair.pm tiene una estructura descentralizada inspirada en atproto, que cualquiera puede operar sin un repositorio central
Los paquetes se identifican con DID, y entidades como Socket pueden adjuntar resultados de análisis como “labelers”
El usuario puede bloquear paquetes con ciertas etiquetas o incluso operar su propio labeler de análisis de seguridad basado en IA
No es perfecto, pero es un enfoque mucho mejor que un package manager centralizado
Ahora están colaborando con la comunidad de Typo3 y expandiéndose a otros ecosistemas (quien comenta es copresidente de FAIR)
Tiene una estructura de incentivos mejor que WordPress, aunque quizá siga sin ser suficiente
La descentralización da libertad, pero desde la perspectiva del usuario es incómoda
Lo interesante de este incidente es que los plugins fueron adquiridos en Flippa
Flippa no es un marketplace exclusivo de WP, sino una plataforma general para compraventa de software
Preocupa que apps o extensiones indie adquiridas de buena fe puedan terminar siendo armadas más adelante
Ese tipo de apps puede valer más para un atacante que para su operador real
Lo más aterrador no es el backdoor en sí, sino que la adquisición parecía demasiado normal
Comprar un plugin confiable y empujar una actualización no se distingue del mantenimiento legítimo
El usuario no tiene ninguna señal para sospechar
Los M&A que limitan la competencia en el mercado a veces requieren aprobación gubernamental
Entonces me pregunto si las adquisiciones con impacto importante en seguridad también deberían requerir un proceso de aprobación por parte del marketplace o del gobierno
Ver artículo de Wikipedia sobre Mergers and acquisitions
WordPress fue excelente gracias a sus plugins, pero ahora justamente por esa estructura de plugins se convirtió en un ecosistema riesgoso
Yo me pasé a Hugo, y también recomiendo a otros esta guía de migración
Parece que las empresas no terminan de darse cuenta de cuánto control han perdido al hacer “outsourcing de TI”