Durante los primeros meses de 2026, el ecosistema open source fue escenario de una serie de ataques a la cadena de suministro que dejaron de ser episodios aislados para convertirse en una tendencia clara. En apenas unas semanas se registraron compromisos de alto impacto que afectaron a proyectos ampliamente utilizados, como Axios, Trivy y LiteLLM, además de otros casos vinculados a Checkmarx KICS y a SDKs como Telnyx.
Diversos informes coinciden en que entre mediados y fines de marzo se produjo un pico de actividad maliciosa, con múltiples ataques concentrados en pocos días, lo que permitió identificar patrones comunes y confirmar que este tipo de incidentes ya no responde a episodios puntuales, sino a campañas activas contra el ecosistema open source.
Zero Trust… ¿dónde?
Más allá de las diferencias entre los proyectos afectados, todos cumplen funciones críticas dentro de procesos o pipelines de desarrollo, automatización, seguridad o inteligencia artificial. Asimismo, todos comparten un rasgo clave: se ejecutan en entornos donde la confianza es la norma y los privilegios suelen ser elevados. Precisamente por eso resultan tan atractivos para los atacantes.
Dos campañas distintas, un mismo objetivo
El análisis de los incidentes más relevantes de 2026 permite distinguir al menos dos campañas principales, con actores y motivaciones diferentes, pero con una lógica operativa en común: comprometer software confiable para llegar a la mayor cantidad posible de víctimas a través de la cadena de suministro.
El caso de Axios fue atribuido a UNC1069, también conocido como Sapphire Sleet, un grupo APT vinculado a los intereses de Corea del Norte, y cuya principal motivación es la ganancia financiera. En este compromiso, se produjo un secuestro de la cuenta del mantenedor principal de Axios mediante técnicas de ingeniería social, lo que permitió publicar versiones maliciosas del paquete en npm, que incluyó un troyano de acceso remoto multiplataforma. El código malicioso se ejecutaba durante una instalación aparentemente normal, sin modificar de forma visible el comportamiento principal de la librería, lo que facilitó que pasara desapercibido en una primera etapa.
En paralelo, otros incidentes que afectaron a LiteLLM, Checkmarx KICS y Telnyx fueron asociados a una campaña distinta que fue atribuida al grupo TeamPCP. En estos casos, el foco no estuvo en un único paquete de alto impacto, sino en una propagación en cascada.
TeamPCP inicialmente explotó una vulnerabilidad de configuración en un workflow del repositorio de código de Trivy (un escáner de seguridad de código abierto con amplia adopción desarrollado por compañía Aqua). El aprovechamiento de esta vulnerabilidad (y una rotación incompleta de credenciales y secretos por parte del desarrollador), derivó en el robo credenciales y tokens de entornos de desarrollo y pipelines CI/CD de las compañías que utilizaron la versión comprometida de Trivy, lo que desató un efecto “trampolín” y de propagación en otros proyectos, generando un patrón de expansión automática similar al de un gusano.
Aunque ambos actores tienen objetivos similares, sus motivaciones no son idénticas. UNC1069 mantiene un perfil alineado a intereses estatales y objetivos financieros sostenidos, mientras que TeamPCP responde a una lógica más criminal y oportunista, orientada a una rápida monetización y reutilización de accesos.
Qué tecnologías fueron afectadas y quiénes las utilizan
Uno de los aspectos más relevantes de estos ataques es la diversidad de tecnologías comprometidas. No se trata de software marginal o proyectos poco conocidos, sino de herramientas ampliamente utilizadas.
Axios es una librería HTTP omnipresente en aplicaciones web, servicios cloud y APIs corporativas, con decenas de millones de descargas semanales. Trivy es un escáner de vulnerabilidades ampliamente integrado en pipelines de DevSecOps y entornos de CI/CD, lo que lo convierte en un objetivo valioso para el robo de credenciales y secretos de infraestructura. LiteLLM funciona como una capa de integración clave para equipos que desarrollan soluciones basadas en modelos de lenguaje, ya que permite enrutar solicitudes hacia múltiples proveedores de IA.
En los ataques atribuidos a TeamPCP, estos compromisos fueron utilizados como vector para extender el compromiso hacia otros proyectos. Checkmarx KICS, por su parte, es una herramienta utilizada para analizar configuraciones de infraestructura como código, lo que refuerza la idea de que los ataques apuntan a todo aquello que forma parte “confiable” del proceso de construcción, prueba y despliegue de software.
Las consecuencias silenciosas de instalar una dependencia comprometida
La instalación de una dependencia comprometida no siempre se traduce en un fallo visible o inmediato. En muchos de los ataques detectados en 2026, una característica común fue su bajo nivel de ruido: el software seguía funcionando como se esperaba, mientras que el código malicioso operaba en segundo plano.
Las consecuencias pueden incluir la instalación de troyanos de acceso remoto, como en el caso de Axios, o el robo masivo de secretos críticos, como tokens de GitHub, npm o PyPI, credenciales de proveedores cloud, claves SSH o configuraciones completas de CI/CD, tal como se observó en la campaña atribuida a TeamPCP.
En materia de cadena de suministro, el tiempo juega a favor del atacante: cada hora adicional aumenta las posibilidades de propagación, reutilización de accesos y ampliación del impacto.
Mirando más allá de la detección
Cuando una alerta llega a manos de los equipos de seguridad, el paquete ya fue ejecutado y el daño inicial, en muchos casos, ya ocurrió. En ataques a la cadena de suministro una detección tardía no solo implica reaccionar después del hecho, sino hacerlo cuando el atacante ya ganó ventaja.
Esta realidad expone los límites de los enfoques basados exclusivamente en la prevención. Por eso, cada vez resulta más evidente que la estrategia no puede limitarse a “instalar software solo de fuentes confiables”, sino que debe incluir la capacidad de identificar rápidamente acciones sospechosas ejecutadas por software legítimo.
Detectando anomalías
Uno de los aprendizajes más claros que dejan estos compromisos recientes es la necesidad de cambiar el foco. En lugar de concentrarse únicamente en qué dependencia se instaló y su fuente, resulta indispensable verificar, y observar cómo se comporta ese componente en tiempo real.
En algunos de los ciberataques mencionados, los primeros indicios surgieron a partir de comportamientos anómalos, como la ejecución de scripts sospechosos durante la instalación, conexiones salientes hacia infraestructuras sospechosas o accesos a archivos sensibles que no forman parte del flujo normal. Este enfoque no requiere conocer de antemano la firma exacta del ataque, sino entender qué es esperable en un entorno y detectar rápidamente aquello que se sale de ese patrón (anomalía).
Un escenario real: detección y respuesta administrada de nuestros servicios de MDR
A continuación, un ejemplo de cómo los servicios de Managed Detection & Response (MDR) pueden aportar visibilidad y respuesta temprana ante este tipo de ataques.
En este caso, una organización se vio involucrada en el ataque a la cadena de suministro de Axios cuando uno de los desarrolladores de la compañía intentó instalar la librería troyanizada durante la ventana de tiempo en la cual el paquete se encontraba publicado en el repositorio oficial de npm.
Al contar con soluciones de seguridad de ESET, fue posible identificar el comportamiento malicioso en sus primeras etapas y bloquear el intento de acceso no autorizado a los sistemas de la organización antes de que el ataque se materializara.
Además, se obtuvo una visibilidad inmediata de toda la cadena del ataque, lo que permitió confirmar el alcance real del incidente, contenerlo de forma inmediata y evitar impactos operativos.
Evidencias del intento de ataque detectado
Imagen 1. Indicadores asociados con la instación de la librería comprometida de Axios.
Indicadores de la protección antivirus:
- Malware: JS/Agent.UHP
Indicadores de reglas de EDR:
- Suspicious script interpreter started - cscript [F0447b]
- Script started from %TEMP% [F0443a]
- Suspicious script interpreter started - cmd [F0447d]
- Script interpreter saved default script file [A0317]
- Curl uploaded file [A0521]
- Renamed PowerShell Execution [D0411]
- PowerShell Suspicious Activity Executed [D0413]
- PowerShell Engine Loaded in Non-PowerShell Process [D1206]
Asimismo, los analistas de seguridad del equipo de MDR de ESET crearon un incidente para notificar a la compañía afectada de que se habían detectado eventos de seguridad sospechosos:
Como medida preventiva, y con el fin de evitar un compromiso mayor, el equipo de MDR aisló el equipo de la red hasta identificar la causa raíz del incidente:
Acciones específicas para defenderse de los ataques a la cadena de suministro
- Identificar y documentar riesgos asociados con la cadena de suministro.
- Implementar soluciones de seguridad robustas y monitorear activamente equipos de desarrolladores, repositorios de código y pipelines de CI/CD.
- Implementar políticas relacionadas con el concepto de menor privilegio posible y Zero-Trust.
- Desplegar soluciones como Socket Firewall o Aikido Safe Chain , las cuales funcionan como “proxy”. De esta manera los paquetes serán interceptados e inspeccionados previo a su instalación en busca de anomalías y de alguna amenaza conocida.
- Adoptar gestores de paquetes como pnpm, los cuales pueden bloquear scripts de posinstalación.
- Aplicar políticas que previenen la instalación de paquetes publicados entre las últimas 24-72 hs (software pinning). En la mayoría de los ataques a la cadena de suministro, el software comprometido permanece solo unas pocas sin ser descubierto.
- Crear y mantener una lista de SBOM (Software Bill of Materials), que consta de los “ingredientes” que componen a un software, ya sea librerías, dependencias y versiones de estos. Esta lista de SBOM permitirá validar rápidamente si hay algún componente comprometido con un código malicioso, vulnerabilidades, e incluso detectar violaciones relacionadas a derechos intelectuales.
