Alerta de seguridad campaña de compromiso de la cadena de suministro ataca WordPress mediante JSON remoto y XSS persistente

Investigadores de seguridad han detectado una campaña de compromiso de la cadena de suministro que aprovechó un componente promocional de BdThemes, un proveedor de complementos para WordPress, para tomar control de sitios sin alterar los archivos de los plugins alojados en el repositorio oficial. Como resultado, el equipo de plugins de WordPress deshabilitó temporalmente las descargas de las extensiones afectadas en el directorio oficial los días 7 y 8 de agosto de 2026, hasta completar una revisión. La técnica no modifica código en disco dentro del repositorio: explota JSON remotos usados para mostrar banners administrativos y ejecuta XSS persistente en el navegador de administradores.

Hechos confirmados: un informe técnico publicado por investigadores externos (Wordfence) describe que el vector es una librería incluida en varios plugins de BdThemes, llamada Biggopti, que descarga datos JSON desde un bucket de DigitalOcean Spaces para renderizar banners promocionales en el panel wp-admin. Esos JSON contienen un parámetro "display_id" que no se escapa correctamente en el cliente, lo que permite la inyección de scripts (XSS) cuando un atacante controla el contenido JSON. La explotación activa un archivo JavaScript (por ejemplo "w2.js") que contacta a un servidor de mando y control (C2), crea cuentas administrativas, sube un ZIP que despliega un web shell PHP ("emer-run.php") y instala persistencia en la carpeta de Must-Use plugins (mu-plugins), incluyendo un backdoor de "login mágico" y un módulo que oculta los usuarios maliciosos. El fallo recibió una puntuación CVSS de 5.4 y el cambio vulnerable se introdujo por primera vez el 1 de marzo de 2026 en al menos uno de los paquetes afectados.

Cómo funciona técnicamente: el componente Biggopti actúa como cliente que solicita JSON remotos alojados por el desarrollador (en DigitalOcean Spaces). Si un actor ofensivo obtiene permisos de escritura sobre ese almacenamiento, puede reemplazar las respuestas JSON con payloads que incluyen HTML/JS malicioso en el campo vulnerable. Cada vez que un administrador accede a cualquier página de wp-admin, el navegador interpreta el banner y ejecuta el script inyectado en el contexto del dominio —lo que otorga capacidades de gestión (a través de la REST API), subida de plugins y ejecución remota sin modificar el código original del plugin en el servidor. Esta cadena evita la mayoría de las verificaciones basadas en integridad de archivos porque no modifica los ficheros del repositorio WordPress.org.

Quién está en riesgo y por qué importa: cualquier sitio WordPress con una de las extensiones afectadas y con al menos un usuario admin que haya iniciado sesión es potencialmente vulnerable. El listado de plugins implicados incluye varios paquetes populares (por ejemplo, “bdthemes-element-pack-lite” con 100.000+ instalaciones activas), pero también hay extensiones con menos instalaciones. La consecuencia práctica es completa usurpación administrativa del sitio: creación de cuentas, instalación de web shells, persistencia difícil de detectar y exfiltración de información o pivote a otros sistemas. Además, la técnica hace más costosa la detección general porque no deja cambios evidentes en los archivos del plugin distribuido por WordPress.org.

Indicadores de compromiso y acciones de detección: busca usuarios con patrones mencionados por los investigadores (por ejemplo nombres que comiencen con "bd_" seguidos de un hash) y revisa archivos y directorios por emer-run.php o entradas sospechosas en mu-plugins. Revisa los logs HTTP para peticiones salientes a dominios asociados al C2 (por ejemplo, la campaña contactaba a un host identificado como ia-cdn[.]com/fz/c en el informe) y busca solicitudes recientes a endpoints de API tipo "api-data-all-records" o "api-data-records". También es señal de compromiso la aparición de ZIP o plugins subidos recientemente por usuarios que no deberían haberlos instalado.

Medidas concretas e inmediatas que deberían tomar los administradores (confirmadas y prácticas): cambie todas las credenciales administrativas y active 2FA; compruebe y elimine cuentas administrativas no reconocidas; revise y, si es necesario, restaure desde copias de seguridad anteriores al 1 de marzo de 2026; investigue la presencia de archivos mencionados (emer-run.php, w2.js, x.js) y entradas en mu-plugins; bloquee a nivel de firewall e infraestructura las comunicaciones salientes hacia los C2 indicados; revoque y regenere claves/credenciales del proveedor de almacenamiento (DigitalOcean Spaces) si su sitio o plugins usan buckets propios. Si no tiene capacidad de respuesta interna, contacte con un proveedor forense o con el equipo de seguridad de WordPress para asistencia.

Recomendaciones para desarrolladores y administradores de plugins: nunca confíe en datos JSON remotos sin saneamiento y escape en el cliente; aplique saneamiento del lado servidor y validación estricta de campos que se inyectan en HTML; considere firmar los assets remotos o servirlos desde orígenes almacenados y controlados con mecanismos de integridad (SRI/headers) y limite permisos de acceso en buckets de objetos. Implemente Content Security Policy (CSP) restrictiva en el área admin para mitigar ejecución de scripts remotos.

Distinción entre hechos confirmados, estimaciones e incertidumbres: está confirmado que Wordfence documentó la explotación de JSON remotos y que WordPress desactivó las descargas de los plugins mientras se investigaba. Es una estimación razonable —basada en indicadores técnicos del informe— que el actor persigue persistencia administrativa para pivotar o ejecutar código malicioso en masa (spam, crypto, botnets), porque la cadena de acciones lo facilita. Lo que sigue incierto y no confirmado públicamente es la identidad del operador del C2, el número total de sitios comprometidos en la naturaleza y si la cuenta de BdThemes fue comprometida directamente o si hubo un fallo intermedio en la cadena de despliegue de su almacenamiento. También es una correlación técnica (no una prueba de atribución definitiva) que los mismos servidores C2 estén relacionados con campañas previas contra otros plugins.

Para información técnica adicional y contexto sobre XSS y gestión de CVE, consulte recursos públicos como la documentación de DigitalOcean Spaces y el registro de vulnerabilidades: https://www.digitalocean.com/docs/spaces/ y la base de datos de vulnerabilidades (NVD) para el CVE reciente corregido por WordPress: https://nvd.nist.gov/. También siga el blog de análisis de amenazas de proveedores independientes como Wordfence para obtener indicadores y actualizaciones técnicas verificadas: https://www.wordfence.com/blog/.

Conclusión: esta campaña subraya un riesgo creciente en las cadenas de suministro de software: no solo la modificación de paquetes distribuidos, sino la manipulación de recursos remotos que se consumen en tiempo de ejecución. Los administradores deben priorizar la detección proactiva (revisión de usuarios y artefactos), la contención (bloqueo de C2, rotación de claves) y la recuperación desde copias limpias; los desarrolladores, por su parte, deben eliminar cualquier dependencia que asuma confianza ciega en contenidos remotos sin validación. La revisión completa y la coordinación con el equipo de seguridad de WordPress son pasos indispensables antes de volver a habilitar descargas o reinstalar componentes comprometidos.