Ataque BdThemes WordPress: 7 plugins afectados

En pocas palabras: El 7 de agosto de 2026, Wordfence detectó que atacantes comprometieron el bucket de DigitalOcean Spaces de BdThemes para inyectar XSS vía JSON envenenado, creando administradores fraudulentos en sitios WordPress con cualquiera de sus 7 plugins activos entre el 23 de junio y el 8 de agosto.

El ataque BdThemes WordPress es un ataque de cadena de suministro detectado el 7 de agosto de 2026 por el investigador Paolo Tresso del equipo de inteligencia de amenazas de Wordfence. Los atacantes envenenaron una API JSON promocional que 7 plugins de BdThemes usan para mostrar banners en el panel de administración, logrando ejecutar XSS en la sesión de cualquier admin autenticado y crear cuentas con privilegios máximos sin que el administrador legítimo se enterara.

Un ataque de cadena de suministro en WordPress ocurre cuando el atacante compromete infraestructura de terceros que los plugins usan, en vez de ir contra el servidor del sitio directamente. En el caso BdThemes, el componente interno Biggopti descargaba banners promocionales desde un bucket de DigitalOcean Spaces: los atacantes ganaron acceso de escritura y reemplazaron el JSON legítimo con payloads XSS, exponiendo cualquier sitio con uno de los 7 plugins activos y un admin logueado entre el 23 de junio y el 8 de agosto de 2026.

¿Qué fue el ataque de cadena de suministro BdThemes de agosto 2026?

BdThemes es una empresa de plugins premium para Elementor, con un catálogo de más de 7 extensiones y más de 350.000 instalaciones activas. Todos sus plugins comparten un componente interno llamado Biggopti, que descarga banners promocionales desde servidores propios alojados en DigitalOcean Spaces (con Cloudflare delante). El sistema funcionaba sin problemas hasta que, según el análisis de Wordfence publicado el 10 de agosto de 2026, un atacante consiguió acceso de escritura a ese bucket y reemplazó las respuestas JSON legítimas con código malicioso.

Lo que hace peligroso a este vector es que no requería ninguna actualización de plugins ni ningún archivo modificado en el servidor del usuario. El código malicioso vivía en la infraestructura de BdThemes, no en la tuya. Hasta que Wordfence lo detectó, cualquier sitio con un plugin BdThemes activo y un administrador logueado era vulnerable.

La vulnerabilidad base (una XSS de inyección de atributos, CVSS 5.4) se introdujo el 1 de marzo de 2026 con la versión 4.1.9 de Prime Slider. En mayo agregaron un sanitizador al endpoint, pero (spoiler: no aplicaron la corrección al atributo que importaba) el fallo persistió. El envenenamiento masivo del endpoint se registró el 6-7 de agosto. Cuatro meses de ventana sin que nadie notara nada en producción. Complementá tu estrategia de seguridad con monitoreo de cambios maliciosos.

El mismo servidor C2 (ia-cdn[.]com) aparece vinculado a ataques previos contra los plugins Advanced Responsive Video Embedder (CVE-2026-18072) y OptinMonster, lo que sugiere un actor que viene trabajando el ecosistema WordPress con metodología y no de forma oportunista.

¿Cuáles son los 7 plugins WordPress de BdThemes que fueron afectados?

Todos comparten el componente Biggopti. Si tenés alguno instalado y activo entre el 23 de junio y el 8 de agosto de 2026, y durante ese período algún administrador accedió al panel de WordPress, el sitio estuvo expuesto. La recomendación de Wordfence es tratar el sitio como comprometido hasta descartar cada indicador de compromiso.

Element Pack es el más grande con diferencia: más de 100.000 sitios activos, según los datos que recopiló Bleeping Computer en su cobertura del incidente.

¿Cómo funcionaba la vulnerabilidad XSS en la librería Biggopti?

Biggopti descarga un JSON desde api[.]sigmative[.]io/prod/store/api/biggopti/ y usa el campo display_id de la respuesta para construir un atributo HTML id. El campo se insertaba sin escapar directamente en el HTML. Lo curioso es que en el atributo data-display-id del mismo elemento sí lo escapaban correctamente, lo que revela que fue una omisión puntual introducida en marzo 2026, no una cultura de desarrollo sin sanitización.

El payload envenenado inyectado en el JSON rompía el atributo con una comilla doble, agregaba un manejador de evento onanimationstart y forzaba una animación CSS de 0.01 segundos. Ese evento se disparaba en silencio cada vez que un admin cargaba cualquier página del panel (sin clic, sin interacción, sin nada), ejecutaba código ofuscado con eval(String.fromCharCode(...)), cargaba el payload principal desde ia-cdn[.]com/fz/w2.js y desde ahí arrancaba la secuencia completa. Cubrimos ese tema en detalle en autenticación de dos factores.

Ponele que tenés Element Pack instalado y revisás el tablero de WordPress un martes de agosto: sin saberlo ejecutás el payload completo, el script contacta el servidor C2, crea una cuenta admin nueva con credenciales calculadas a partir de tu hostname (usuario bd_[hash en base36], contraseña Bd@26![hash]x), descarga un plugin falso con emer-run.php como webshell (MD5 conocido: 1024732009983dd5e54b4cf5593f04d4), instala un backdoor en mu-plugins que permite acceso admin sin contraseña y agrega un módulo stealth que oculta las cuentas rogue de la lista de usuarios de WordPress. Todo eso mientras vos estabas mirando cuántas visitas tuviste en la semana.

¿Por qué credenciales determinísticas basadas en el hostname? Porque si querés comprometer miles de sitios, necesitás poder identificar las cuentas sin mantener una base de datos centralizada con cada víctima. El esquema predecible le permite al atacante calcular las credenciales de cualquier sitio comprometido desde cero.

¿Cómo saber si tu sitio WordPress fue comprometido por el ataque BdThemes?

Si usaste cualquiera de los 7 plugins entre junio y agosto de 2026, revisá estos indicadores de compromiso en orden. La presencia de cualquiera de ellos confirma que el payload se ejecutó.

• Usuarios con patrón bd_: buscá en la tabla wp_users cuentas con ese prefijo seguido de 6 caracteres alfanuméricos. También cuentas con email terminado en @wordpress.org que vos no creaste.
• Opciones de base de datos maliciosas: verificá en la tabla wp_options los registros fz_emer_login_tokens y fz_emer_done_v1. Si existen, el payload se ejecutó en tu sitio.
• Webshell emer-run.php: revisá el directorio /wp-content/plugins/ por carpetas o archivos que no reconocés. El MD5 del webshell conocido es 1024732009983dd5e54b4cf5593f04d4.
• Backdoors en mu-plugins: buscá class-wp-token-validate.php y archivos class-wp-query-*.php en /wp-content/mu-plugins/. No deberían estar ahí si no los pusiste vos.
• Tráfico saliente a ia-cdn[.]com: si tenés logs del servidor, buscá requests hacia ese dominio. Es el C2 del atacante.

Wordfence activó firmas de detección para usuarios premium el 7 de agosto de 2026. Los usuarios de la versión gratuita las reciben después de 30 días (ojo con eso). Lo explicamos a fondo en doble verificación en cuentas admin.

Qué está confirmado y qué no

• Confirmado: La vulnerabilidad XSS fue introducida en Prime Slider v4.1.9 el 1 de marzo de 2026, según el análisis técnico de Wordfence publicado el 10 de agosto.
• Confirmado: El payload activo usó el servidor C2 ia-cdn[.]com, el mismo identificado en ataques previos a otros plugins de WordPress.
• Confirmado: Los 7 plugins fueron cerrados en WordPress.org el 8 de agosto de 2026 y los endpoints de la API de BdThemes fueron limpiados ese mismo día.
• Confirmado: La campaña «Summer Sale» de BdThemes, que activó la exposición del XSS, comenzó el 23 de junio de 2026, dando una ventana de exposición de más de seis semanas.
• No confirmado: El número exacto de sitios efectivamente comprometidos. Wordfence no publicó cifras de infecciones confirmadas, solo de sitios expuestos.
• No confirmado: Si BdThemes tiene versiones parcheadas disponibles. Al momento del cierre, Wordfence reportó la vulnerabilidad como no parcheada. Verificá el repositorio oficial antes de reinstalar cualquiera de los plugins.
• No confirmado: La identidad del atacante. La conexión con ataques previos es circunstancial vía el servidor C2 compartido.

Pasos para limpiar WordPress tras un ataque de cadena de suministro

Si confirmaste algún indicador de compromiso, el orden importa. No empieces eliminando archivos antes de hacer un respaldo: si necesitás reconstruir qué pasó exactamente, vas a querer tener evidencia forense.

• Respaldo del estado actual: antes de tocar nada, hacé un snapshot completo incluyendo base de datos. Sirve tanto para rollback como para análisis forense posterior.
• Eliminá los usuarios rogue: desde wp-admin (si las cuentas son visibles) o directamente en base de datos con DELETE FROM wp_users WHERE user_login LIKE 'bd_%', seguido de limpieza en wp_usermeta.
• Borrá el webshell y los backdoors: eliminá emer-run.php del directorio de plugins, y revisá mu-plugins por class-wp-token-validate.php y cualquier archivo class-wp-query-*.php.
• Limpiá las opciones de base de datos maliciosas: DELETE FROM wp_options WHERE option_name IN ('fz_emer_login_tokens', 'fz_emer_done_v1').
• Cambiá todas las credenciales admin legítimas: los usuarios reales también, porque el atacante podría haber capturado sesiones activas durante la ejecución del payload.
• Desinstalá los 7 plugins BdThemes afectados hasta que haya versiones oficialmente verificadas y parcheadas disponibles en WordPress.org.
• Escaneá con Wordfence o WPScan: buscá archivos modificados y malware residual que el módulo stealth pudiera haber ocultado.
• Monitoreá Google Search Console durante 30 días: los ataques de este tipo frecuentemente inyectan spam SEO o configuran redirecciones que demoran semanas en aparecer en GSC.

¿Cómo proteger WordPress de ataques de cadena de suministro?

La defensa contra este vector es más compleja que el clásico «actualizá los plugins», porque el problema no era un archivo desactualizado en tu servidor sino la infraestructura del proveedor. Eso no significa que estés desamparado.

• Minimizá la superficie de plugins: cada plugin con una dependencia remota de API, CDN o servicio externo amplía tu superficie de ataque hacia infraestructura que vos no controlás. Si no usás todas las funcionalidades de un plugin, desinstalalo.
• Monitoreá integridad de archivos: Wordfence tiene detección de cambios en el sistema de archivos. Si alguien instala un plugin falso en /wp-content/plugins/, lo vas a saber antes de que el daño escale.
• Auditá usuarios admin periódicamente: una vez por mes, revisá la lista de administradores activos. Es un hábito de 2 minutos que hubiera detectado esto el día 1 en cualquier sitio comprometido.
• WAF activo con reglas actualizadas: Wordfence bloqueó este ataque para usuarios premium el mismo día de la detección. Los 30 días de delay en la versión gratuita son un riesgo real en incidentes activos.
• Revisá GSC mensualmente: el spam SEO que inyectan estos ataques tarda semanas en aparecer en Google. Una revisión mensual de Search Console te avisa antes de que el daño en rankings sea irreversible.

El aislamiento de entornos también limita el daño lateral. Si tu hosting tiene buena separación entre cuentas, un compromiso en un sitio no escala al servidor completo. donweb.com tiene planes de WordPress con aislamiento de instancias que reducen exactamente ese riesgo.

Alternativas seguras a los plugins BdThemes afectados

Si dependías de alguno de estos plugins, hay opciones que no implican instalar nada de terceros con historial cuestionable ahora mismo.

• Sliders y carruseles: Elementor ya tiene widgets nativos de carrusel e imagen que cubren el 80% de los casos de uso de Prime Slider sin dependencia externa. Para necesidades más avanzadas, Smart Slider 3 (más de 1 millón de instalaciones, actualizaciones regulares en WordPress.org) es una opción con historial limpio.
• Galerías: el widget Gallery nativo de Elementor Pro cubre la mayoría de los casos de Pixel Gallery. Si necesitás lightbox, FooGallery tiene más de 200.000 instalaciones y actualizaciones recientes, sin el overhead de un addon pack completo.
• Listados de posts y queries: el Query Loop de Elementor y los widgets de Posts nativos reemplazan gran parte de lo que hacía Ultimate Post Kit. Para estructuras más complejas, Custom Post Type UI junto con las herramientas nativas de Elementor cubre bien el caso sin agregar una dependencia de API externa.

El criterio al elegir un reemplazo: repositorio oficial de WordPress.org, más de 100.000 instalaciones activas, commits de actualización en los últimos 90 días. Un plugin sin actualizaciones recientes es deuda técnica esperando convertirse en incidente. Para más detalles técnicos, mirá mejores prácticas contra intrusiones.

Preguntas Frecuentes

¿Qué es el ataque BdThemes Supply Chain?

El ataque BdThemes Supply Chain es un compromiso de cadena de suministro descubierto el 7 de agosto de 2026 por Wordfence. Los atacantes ganaron acceso de escritura al bucket de DigitalOcean donde BdThemes almacenaba sus respuestas JSON de API promocional, reemplazando ese contenido con payloads XSS que se ejecutaban en el panel de cualquier WordPress con uno de los 7 plugins activos. El resultado fue la creación de administradores no autorizados y la instalación de webshells persistentes en los sitios afectados.

¿Qué plugins WordPress fueron afectados por el ataque BdThemes?

Los 7 plugins afectados son: Element Pack Addons for Elementor (más de 100.000 instalaciones activas), Prime Slider Addons for Elementor, Pixel Gallery Addons for Elementor, Ultimate Post Kit Addons for Elementor, Ultimate Store Kit (más de 6.000), Live Copy Paste (más de 6.000) y Smart Admin Assistant. Todos comparten el componente Biggopti, que fue el vector de la infección. El portfolio completo suma más de 350.000 instalaciones activas, según datos de Bleeping Computer.

¿Cómo sé si mi sitio fue comprometido por el ataque BdThemes?

Buscá cuentas de usuario con el prefijo bd_ seguido de 6 caracteres alfanuméricos en tu lista de administradores. Verificá en la tabla wp_options los registros fz_emer_login_tokens y fz_emer_done_v1: si existen, el payload se ejecutó en tu sitio. También buscá el archivo emer-run.php en el directorio /wp-content/plugins/ y archivos class-wp-token-validate.php en /wp-content/mu-plugins/. La presencia de cualquiera de estos elementos confirma el compromiso.

¿Actualizar los plugins BdThemes protege mi sitio?

No por sí solo. Si el payload ya se ejecutó en una sesión admin entre el 23 de junio y el 8 de agosto de 2026, el daño ya está hecho: el backdoor y los usuarios rogue persisten aunque desinstales el plugin. Además, Wordfence reportó los 7 plugins como no parcheados al momento del cierre. Desinstalalos, pero primero auditá si el sitio ya fue comprometido usando los indicadores de compromiso. El orden importa.

¿Cómo proteger WordPress de ataques de cadena de suministro como el de BdThemes?

No hay un parche único porque el vector está en infraestructura de terceros que el plugin usa, no en el plugin en sí. La defensa es multicapa: minimizá la cantidad de plugins instalados (menos dependencias externas, menos superficie expuesta), activá monitoreo de integridad de archivos, auditá la lista de usuarios admin mensualmente y usá un WAF con reglas actualizadas. Wordfence Premium bloqueó este ataque el día que lo detectó; la versión gratuita tardó 30 días en recibir la misma protección.

Conclusión

El ataque BdThemes de agosto 2026 pone sobre la mesa algo que muchos administradores de WordPress no terminan de internalizar: la superficie de ataque de tu sitio no termina en los archivos de tu servidor. Cada plugin con una dependencia remota de API, CDN o servicio externo amplía esa superficie hacia infraestructura que vos no controlás ni podés auditar.

En este caso, una XSS introducida en marzo 2026 sin que nadie la detectara en producción por cuatro meses, más el acceso del atacante a un bucket de almacenamiento en la nube, fueron suficientes para comprometer potencialmente miles de sitios sin tocar un solo archivo local del usuario. El mecanismo de credenciales determinísticas (calculadas a partir del hostname del sitio víctima) muestra que el atacante diseñó el ataque para escalar a miles de sitios de forma sistemática, no para comprometer objetivos individuales.

Si tenés cualquiera de los 7 plugins instalados, el orden de acción es claro: auditá primero con los indicadores de compromiso, limpiá segundo si encontrás algo, desinstalá o actualizá tercero cuando haya versión verificada. Y después de esto, quizás sea buen momento para revisar cuántos otros plugins de tu WordPress se conectan a APIs externas sin que lo sepas.

Fuentes

• The Hacker News — BdThemes Supply Chain Attack Poisons JSON to Create Rogue WordPress Admins
• Bleeping Computer — BdThemes plugins supply chain hack creates rogue WordPress admins
• Malware.news — PSA: Supply chain compromise in BdThemes ecosystem via poisoned API response (análisis técnico completo)
• GBHackers — WordPress Supply Chain Attack Exploits BdThemes Plugins
• El Hacker — Nuevo ataque de cadena de suministro de WordPress afecta plugins BdThemes