La automatización de releases del proyecto fue usada para distribuir bee-js 13.3.0 y Swarm Desktop 0.56.2 con código que extrae claves y contraseñas de nodos.
El proyecto Ethersphere confirmó que su sistema de automatización de lanzamientos fue comprometido por atacantes que lograron publicar versiones maliciosas de dos herramientas centrales para la red de almacenamiento descentralizado Swarm. Las versiones afectadas — bee-js 13.3.0 y Swarm Desktop 0.56.2 — fueron distribuidas a través de los canales oficiales del proyecto, lo que convirtió la infraestructura de confianza en el vector de ataque. El código insertado apunta directamente a las credenciales que los operadores de nodos mantienen en sus instalaciones locales, con capacidad adicional de persistencia mediante backdoor.
Cómo la automatización de releases se convirtió en el punto de entrada
El compromiso no ocurrió en el código fuente de las herramientas ni en los repositorios de desarrollo. Los atacantes intervinieron el pipeline de automatización que Ethersphere usa para empaquetar y publicar nuevas versiones. Esto significa que el malware nunca pasó por revisión de código ni por los controles habituales de pull request — fue inyectado en una etapa posterior, cuando el software ya estaba siendo preparado para distribución. Ese momento del ciclo de vida es particularmente vulnerable porque muchos proyectos asumen que lo que sale del build automatizado refleja exactamente lo que está en el repositorio verificado.
La elección de comprometer la automatización en lugar del código fuente tiene ventajas tácticas claras para un atacante. Primero, reduce la ventana de detección: el malware solo existe en los artefactos finales, no en el historial de commits donde otros desarrolladores podrían notarlo durante semanas. Segundo, permite distribuir el payload a través de los canales oficiales de actualización, lo que hace que los usuarios confíen en la descarga sin verificación adicional. Tercero, si el proyecto no firma criptográficamente sus releases o no valida la integridad del build contra el código fuente, la intervención puede pasar desapercibida hasta que alguien inspeccione manualmente el binario distribuido.
Qué hace el código malicioso una vez instalado
El malware insertado en ambas herramientas tiene dos objetivos inmediatos. Primero, extrae la clave privada del wallet que Swarm Desktop mantiene para operar su nodo en la red descentralizada. Segundo, captura la contraseña almacenada que desbloquea ese wallet. Esa combinación — clave más contraseña — es suficiente para que un atacante tome control total de los fondos asociados al nodo y, potencialmente, de la identidad del nodo dentro de la red Swarm.
Además del robo de credenciales, el código incluye funcionalidad de backdoor. Esto sugiere que los atacantes no buscaban solo un golpe único de extracción de wallets, sino establecer acceso persistente a los sistemas comprometidos. Un backdoor en este contexto puede servir para múltiples propósitos: monitorear actividad futura del nodo, inyectar código adicional sin necesidad de volver a comprometer el pipeline de releases, o usar la máquina infectada como punto de pivote hacia otras partes de la infraestructura del operador.
La arquitectura del ataque indica planificación. No es un script oportunista que busca credenciales genéricas — está diseñado específicamente para los artefactos que Swarm Desktop almacena y para el flujo de autenticación de esa aplicación. Eso implica que los atacantes estudiaron previamente cómo funciona la herramienta, dónde guarda sus secretos y qué formato tienen esos archivos.
Por qué proyectos de infraestructura descentralizada son blancos atractivos
Swarm es una red de almacenamiento descentralizado donde los nodos operan con incentivos económicos — los operadores mantienen wallets con fondos que respaldan su participación en la red. Esa característica convierte cada instalación de Swarm Desktop en un objetivo con valor monetario directo. A diferencia de comprometer un cliente de correo o un navegador, donde el atacante tiene que buscar qué datos valiosos hay en el sistema, aquí el valor está garantizado por diseño: si alguien corre Swarm Desktop, tiene un wallet con clave privada.
Este patrón se repite en otros proyectos de blockchain e infraestructura descentralizada. Los nodos de validación, los clientes de staking y las herramientas de gestión de wallets son blancos recurrentes porque combinan dos factores: alta concentración de valor (las claves controlan fondos) y superficie de ataque amplia (software que se actualiza frecuentemente, con dependencias complejas y pipelines de build automatizados). En América Latina, donde la adopción de infraestructura cripto ha crecido tanto en exchanges centralizados como en proyectos DeFi, el riesgo no es teórico. Operadores de nodos en Argentina, Brasil y México que usen Swarm para almacenamiento descentralizado o que participen en redes similares enfrentan el mismo vector: si actualizaron a las versiones comprometidas antes de que se detectara el problema, sus claves ya están en manos de los atacantes.
El patrón más amplio de compromiso de supply chain en proyectos open source
Este incidente se suma a una serie de casos recientes donde la infraestructura de distribución de software — no el código en sí — fue el punto débil. El compromiso de pipelines de CI/CD, registros de paquetes y sistemas de firma automática se ha convertido en una técnica estándar para atacantes que buscan escala. Una vez que controlás el proceso de build, podés inyectar malware en miles de instalaciones sin tocar una sola línea del repositorio público.
La defensa contra este tipo de ataque requiere más que revisión de código. Los proyectos necesitan builds reproducibles — donde cualquiera pueda verificar que el binario distribuido corresponde exactamente al código fuente declarado — y firma criptográfica de releases con claves gestionadas fuera del pipeline automatizado. También necesitan monitoreo de integridad: alertas automáticas si el hash de un artefacto publicado no coincide con el esperado, o si aparecen dependencias no declaradas en el build final.
Para los usuarios, la lección es que actualizar desde canales oficiales no garantiza seguridad si esos canales están comprometidos. En contextos de alto riesgo — como gestión de wallets o infraestructura cripto — tiene sentido esperar confirmación de integridad antes de aplicar actualizaciones, especialmente si el proyecto no publica hashes verificables o no tiene un proceso de firma transparente.
Nuestro análisis
Lo que distingue este caso no es la sofisticación técnica del malware — robar claves de wallets es un objetivo clásico — sino la elección del vector. Comprometer la automatización de releases en lugar del código fuente es una apuesta a que los proyectos open source confían demasiado en sus propios pipelines. Y esa apuesta, en este caso, funcionó: las versiones maliciosas fueron distribuidas como si fueran legítimas, sin que ningún control intermedio las detuviera.
El patrón se repite porque la industria todavía trata la seguridad de supply chain como un problema de dependencias externas — escanear librerías de terceros, auditar paquetes de npm — pero no aplica el mismo rigor a la infraestructura interna de build y distribución. Un pipeline de CI/CD comprometido es funcionalmente equivalente a un repositorio de paquetes malicioso, pero con una diferencia crítica: tiene la firma de confianza del proyecto.
Para proyectos que gestionan valor económico directo, como Swarm, la falta de builds reproducibles y firma criptográfica verificable no es solo una deuda técnica — es una vulnerabilidad estructural. Si un operador de nodo no puede verificar de forma independiente que el binario que descargó corresponde al código auditado, está confiando ciegamente en que nadie intervino el proceso de empaquetado. Y como muestra este incidente, esa confianza no siempre está justificada.
¿Cuántos otros proyectos de infraestructura descentralizada están distribuyendo software a través de pipelines que podrían ser comprometidos de la misma forma sin que nadie lo note hasta que las wallets empiecen a vaciarse?