Investigadores de ciberseguridad han advertido sobre un ataque de cadena de suministro que comprometió la distribución de varios plugins para WordPress asociados al proveedor BdThemes. En lugar de tocar archivos de código dentro del repositorio oficial de WordPress.org, la intrusión se centró en cómo se servía contenido desde un sistema externo, lo que amplificó el impacto y dificultó detectar el origen a simple vista.
Como respuesta, el equipo de plugins del ecosistema de WordPress deshabilitó temporalmente las descargas de los complementos afectados mientras se realiza una revisión completa. A continuación, repasamos qué ocurrió, qué plugins estuvieron involucrados y por qué el vector utilizado resulta especialmente relevante para administradores y equipos de seguridad.
Qué se sabe del ataque de cadena de suministro
Según el análisis compartido por investigadores, el incidente no se comportó como los ataques tradicionales de cadena de suministro que modifican archivos dentro de un repositorio. En este caso, no se reportaron cambios en archivos de código fuente en WordPress.org. El punto crítico fue un flujo de datos JSON remoto que se consumía desde el panel de administración.
En palabras de los investigadores, los atacantes “envenenaron” una transmisión estática de datos JSON que es solicitada por un componente de WordPress encargado de mostrar banners promocionales. Ese JSON, al ser procesado, contenía una falla explotable que permitía ejecutar scripts en el navegador cuando el contenido era renderizado por la interfaz de administración.
Cómo el JSON remoto terminó ejecutando código
El mecanismo de la plataforma involucraba un componente interno conocido como Biggopti, que viene incluido con los plugins. Este sistema está diseñado para obtener banners desde un servidor API y mostrar esa información dentro del panel de administración de WordPress.
La carga llega mediante solicitudes que extraen archivos JSON desde un bucket en DigitalOcean Spaces. Allí es donde se habría producido la manipulación: se detectó una vulnerabilidad de cross-site scripting (XSS) vinculada a la forma en que el JSON se interpreta, específicamente por el parámetro display_id procedente de la API.
La gravedad radica en que, si un atacante logra comprometer el servicio que entrega esos datos, puede inyectar scripts arbitrarios. Esos scripts se activan cuando un usuario autenticado abre páginas de administración (por ejemplo, bajo wp-admin), ejecutándose silenciosamente en el navegador del administrador.
Plugins afectados y estado en el directorio
La alerta identifica varios plugins con instalaciones activas, aunque no en todos se proporcionó el mismo nivel de datos. Los investigadores enumeran los siguientes complementos:
- Element Pack Addons for Elementor (widgets, plantillas y más) — 100.000+ instalaciones activas.
- Live Copy Paste for Elementor — 6.000+ instalaciones activas.
- Pixel Gallery Addons for Elementor — cifra no especificada.
- Prime Slider Addons for Elementor — cifra no especificada.
- Smart Admin Assistant — cifra no especificada.
- Ultimate Post Kit Addons for Elementor — cifra no especificada.
- Ultimate Store Kit — 6.000+ instalaciones activas.
Además, al consultar las fichas de cada plugin en el directorio de WordPress, se muestra un mensaje de que las entradas fueron cerradas (a partir del 7 u 8 de agosto de 2026) y que no estarán disponibles para descarga hasta una revisión completa.
El XSS fue solo el inicio: creación de admins y web shells
El reporte detalla que el script inyectado se ejecuta cada vez que se carga una página de administración. Desde ese punto, el payload busca persistencia y escalamiento de control: crea cuentas administrativas no autorizadas, instala un plugin malicioso y termina desplegando una shell web basada en PHP.
Los investigadores señalan que el código malicioso llegó como un archivo JavaScript denominado w2.js, servido a través de un endpoint de la API identificado como api-data-all-records. Durante la ejecución, el script realiza varias acciones encadenadas:
- Se comunica con un servidor de mando y control (C2) usando la ruta ia-cdn[.]com/fz/c, enviando el origen del sitio afectado para recibir instrucciones de ataque.
- Si el servidor responde con estados como skip o done, la ejecución se detiene.
- Crea un nuevo administrador “rogue” mediante la API REST de WordPress.
- Descarga un ZIP de plugin falso desde el C2 e instala ese paquete utilizando el formulario estándar de carga de plugins, con lo que se despliega una shell PHP con el nombre emer-run.php.
- Activa persistencia instalando módulos en mu-plugins. Entre ellos, menciona un “backdoor de acceso mágico” que habilita una entrada administrativa sin autenticación mediante un parámetro en la URL con un token. También incluye un módulo de sigilo para evitar que el listado administrativo muestre las cuentas creadas y para alterar el recuento visible de usuarios.
Un segundo payload: credenciales deterministas
Además del archivo w2.js, los investigadores identifican un payload alternativo denominado x.js. Este contenido se entregaba mediante el endpoint api-data-records y su propósito era generar credenciales administrativas “deterministas” a partir del nombre de host del sitio víctima.
El reporte explica que el algoritmo produce:
- Usuarios con un prefijo (por ejemplo, bd_) seguido de un hash de 6 caracteres en base36.
- Contraseñas con un patrón fijo y el hash incrustado (incluyendo una cadena como Bd@26! seguida del hash y un sufijo indicado en el análisis).
- Un correo asociado con formato @wordpress.org.
La ventaja para los atacantes es clara: no necesitan mantener un listado central de sitios comprometidos para calcular las credenciales. Para el equipo de respuesta a incidentes, en cambio, esa predictibilidad permite inferir exactamente qué usuario y contraseña intentar para verificar y buscar actividad sospechosa, siempre dentro de un proceso controlado.
Persistencia, exfiltración y objetivo final
Tras generar o crear credenciales maliciosas, el ataque busca mantener el acceso y además recopilar resultados para enviarlos de vuelta al servidor C2. En conjunto, el reporte describe un patrón de persistencia administrativa encubierta y ejecución remota a través del entorno WordPress.
También se observa que el servidor C2 asociado a esta campaña se relacionó con otros incidentes recientes de cadena de suministro contra plugins de WordPress, vinculados a técnicas para otorgar acceso total sin autenticación mediante tokens ocultos o cuentas administrativas creadas bajo ciertas condiciones de inicio de sesión.
Por qué el vector “API + bucket” importa
Un elemento que los investigadores resaltan es que el contenido malicioso (incluyendo registros JSON y el payload secundario x.js) se subió directamente al bucket del proveedor. Esto sugiere que el compromiso no se limitó a un descuido puntual, sino a una compromisión previa en la infraestructura cloud o en las credenciales asociadas al almacenamiento.
En otras palabras: la vía de ataque estuvo “aguas arriba”, en cómo se almacenan y entregan los datos que luego se muestran en el panel. Por eso, aunque no se modificaran archivos en disco dentro del repositorio de WordPress.org, el efecto final se materializó sobre usuarios y administradores al cargar páginas de wp-admin.
Qué significa esto para administradores de WordPress
Este caso pone en primer plano un riesgo que va más allá de “actualiza el plugin”: también hay que vigilar cómo los plugins consumen recursos externos, procesan datos y renderizan contenido en el panel.
Si gestionas sitios con complementos de proveedores externos, considera estas medidas prácticas:
- Revisa inventarios de plugins y desactiva temporalmente los que estén bajo revisión o con alertas públicas.
- Comprueba accesos y cuentas administrativas recientes o inusuales, especialmente si aparecieron sin un proceso legítimo.
- Busca archivos PHP inesperados asociados a shells y revisa la presencia de módulos en mu-plugins.
- Monitorea actividad en el panel de administración (eventos, cargas de plugins y cambios en usuarios) para detectar señales tempranas.
Además, mantén actualizado el núcleo y valida los parches de seguridad del ecosistema. El reporte recuerda que, días antes, WordPress abordó una vulnerabilidad relacionada con reflected XSS previa a autenticación, que puede derivar en ejecución de código en servidores cuando un administrador interactúa con contenido controlado por un atacante.
Conclusión
El incidente atribuido a BdThemes muestra cómo un ataque de cadena de suministro puede materializarse sin modificar el código dentro del repositorio oficial: basta con comprometer la entrega de datos remotos y explotar una falla en cómo se interpretan esos datos en el panel de administración.
Con la desactivación temporal de descargas y la revisión en curso de los plugins afectados, el foco ahora debe estar en la detección y contención: buscar cuentas administrativas no autorizadas, revisar posibles shells y confirmar que no exista persistencia oculta. Si administras sitios con WordPress, trata estas señales como una alerta para reforzar monitoreo, inventario y respuesta ante incidentes.
Fuente: https://thehackernews.com/2026/08/bdthemes-supply-chain-attack-poisons.html
