Soporte técnico
Documentación
Inicio de sesión
Contáctenos
Ir directamente al resumen generado por IA de esta entrada del blog 
Principales conclusiones
- Entre marzo y julio de 2026 se registraron seis campañas confirmadas dirigidas a la cadena de suministro que afectaron a npm, PyPI, los módulos de Go y Packagist.
- Ninguno de ellos necesitaba un error en el código de la aplicación de nadie, solo un eslabón de confianza en la cadena de distribución.
- Tres de los seis llegaron y se marcharon en cuestión de horas, lo cual es más rápido de lo que suelen tardar la mayoría de los programas de escaneo.
- La detección posterior a la instalación se diseñó para un ataque más lento que el que están sufriendo los equipos actualmente.
Dos de las campañas más rápidas de este año demuestran lo poco que necesita un atacante. El 31 de marzo, dos versiones maliciosas de Axios permanecieron en npm durante unas tres horas antes de que alguien las retirara. La toma de control de Mastra fue aún más rápida, volviendo a publicar más de 140 paquetes en unos 88 minutos el 17 de junio. Microsoft atribuye ambos casos a Sapphire Sleet, mientras que Google vincula el ataque a Axios con el grupo norcoreano al que ahora denomina Midnight Neptune, anteriormente conocido como UNC1069. Ninguna de las dos intrusiones se detuvo antes de que las versiones maliciosas llegaran a los usuarios, y en ninguno de los dos casos nadie modificó el código fuente del paquete. El atacante añadió una única dependencia a package.json y dejó que npm install se encargara del resto.
SCA tradicional centrado en CVE y SBOM nunca se diseñaron para detener ninguna de las dos cosas, ya que, en el momento en que importaba, no había nada con lo que compararlas. Ambas ventanas se abrieron y se cerraron en menos tiempo del que tardan en completarse muchas compilaciones nocturnas.
Así se perfila el año 2026 hasta ahora. No se trata de una única brecha de seguridad de gran envergadura sobre la que todo el mundo siga discutiendo meses después, sino de una sucesión constante de campañas breves, rápidas y ejecutadas con eficacia que atacan los registros públicos una tras otra, mientras que la mayoría de los sistemas de defensa siguen estando en la parte más lejana del proceso, a la espera de informar de lo que ya ha ocurrido.
¿Qué cambió entre 2025 y 2026?
Si se analizan las fechas, el patrón resulta evidente. Se han detectado seis campañas confirmadas en un periodo de cinco meses, de marzo a julio de 2026, en cuatro ecosistemas. Esto supone aproximadamente una campaña importante, confirmada de forma independiente, al mes, varias de ellas asociadas a actores maliciosos identificados.
Y los datos generales sobre amenazas indican que no se trató solo de un periodo excepcionalmente malo. El informe de Wiz sobre amenazas en la nube del primer semestre de 2026 reveló que el volumen de incidentes significativos que notificó a sus clientes aumentó un 60 % con respecto al segundo semestre de 2025, la cifra más alta de todos los periodos analizados, y que los ataques a la cadena de suministro pasaron de representar alrededor del 10 % de esos incidentes al 25 %. Wiz se centra en contabilizar los incidentes en la nube en lugar de la higiene del registro, por lo que estos datos constituyen una verificación externa de la tendencia, en lugar de una confirmación por parte del propio proveedor de su propia tesis. El Grupo de Inteligencia sobre Amenazas de Google estima con un alto grado de confianza que el crecimiento de las campañas de muy gran escala dirigidas a la cadena de suministro de código abierto a lo largo de 2025 y principios de 2026 representa una expansión real de la táctica, más que una mejora en la detección, y las cifras de OpenSSF que cita sitúan el aumento de los paquetes de código abierto maliciosos identificados en más del 1.400 % entre 2024 y 2025.
Lo que merece la pena fijarse es la duración de cada una de las campañas. Mastra estuvo activa unos 88 minutos. Axios duró unas tres horas. Las cinco versiones maliciosas de jscrambler se distribuyeron en un intervalo de tiempo más o menos similar. Las demás campañas, por el contrario, se desarrollaron de forma silenciosa durante semanas, lo que podría decirse que es aún peor. Cualquiera de los dos extremos de ese intervalo resulta complicado para las herramientas diseñadas para detectar amenazas con una periodicidad nocturna.
Una visión realista: Una campaña al mes no implica un aumento proporcional en el número de atacantes. La automatización explica gran parte de ello, y el año 2026 nos ofreció un claro ejemplo. TeamPCP publicó el código fuente completo del gusano Mini Shai-Hulud en GitHub el 12 de mayo, y en cuestión de semanas aparecieron campañas derivadas que utilizaban esa cadena de herramientas. La publicación de un paquete se puede automatizar mediante scripts, el robo de credenciales se puede automatizar mediante scripts y la suplantación de espacios de nombres lleva años pudiéndose automatizar mediante scripts.
También puedes obtener más información sobre el «slopsquatting» y las «alucinaciones» de los paquetes de IA en nuestra guía detallada.
Las seis campañas que marcaron la pauta
Los seis casos que se enumeran a continuación no constituyen un «top seis» por número de paquetes afectados. Son los seis que mejor reflejan la variedad de lo ocurrido este año, desde secuestros mediante credenciales robadas (axios, jscrambler) hasta un gusano autopropagable, una cuenta inactiva que volvió a activarse, la inyección de mensajes dirigidos a revisores de IA y la apropiación de cuentas impulsada por ingeniería social.
| Campaña | Fecha | Ecosistema de paquetes | ¿Qué hizo que funcionara? |
| secuestro de Axios | 31 de marzo | npm | El ordenador del responsable principal del mantenimiento fue comprometido mediante ingeniería social, tras lo cual se publicaron directamente en npm dos versiones maliciosas, que permanecieron activas durante unas tres horas. Microsoft lo atribuyó a «Sapphire Sleet» y Google, a «Midnight Neptune». |
| Mini Shai-Hulud | A partir del 29 de abril | npm | Un gusano autopropagable que recopilaba credenciales de npm y de integración continua (CI) y, a continuación, se volvía a publicar en todos los paquetes que sus víctimas pudieran publicar. Se atribuye a TeamPCP. |
| Hades | 7 y 8 de junio | PyPI | Se enviaron 19 paquetes que contenían 37 «wheels» maliciosos con ganchos de inicio .pth, con texto de inyección de mensajes de comando destinado a la revisión basada en modelos de lenguaje grande (LLM). Forman parte de la línea Miasma, derivada a su vez de Mini Shai-Hulud. |
| Adquisición de Mastra | 17 de junio | npm | Cuenta de colaborador inactiva, sin actividad desde febrero de 2025, cuyo acceso a Scope nunca se ha revocado, utilizada para volver a publicar más de 140 paquetes con una dependencia inyectada. Se trata del mismo actor que en el caso de axios. |
| jscrambler | 11 de julio | npm | Se utilizó una credencial de publicación robada para distribuir cinco versiones que contenían un programa de robo de información multiplataforma; las tres primeras de ellas a través de un gancho de preinstalación. |
| PolinRider | A partir de marzo | npm, Go, Packagist | Se apropiaron de cuentas de mantenedores mediante herramientas de desarrollo maliciosas y procesos de recuperación de cuentas, y luego las utilizaron para introducir cargadores ofuscados en 108 paquetes y extensiones. Se detectó a principios de julio y se relacionó con el clúster «Contagious Interview». |
Si ponemos estos seis casos en fila, hay algo que los une a todos. Ninguno de ellos necesitó una vulnerabilidad en el propio código de la víctima. Todos ellos se aprovecharon de un paso de confianza en algún punto entre el teclado del administrador y tu comando de instalación, y en cuatro de los seis casos ese paso fue una cuenta legítima del administrador.
La similitud entre Axios y Mastra no es una coincidencia de estilo. Microsoft puso al mismo equipo detrás de ambas, por lo que al menos dos de las seis formaban parte de un mismo grupo que iba perfeccionando su enfoque entre una campaña y otra, en lugar de ser dos equipos que hubieran dado con la misma idea por casualidad. Hades y Mini Shai-Hulud también comparten un árbol genealógico. Seis campañas, pues, pero más bien cuatro grupos diferenciados, algo que conviene dejar claro antes de que alguien interprete el recuento como seis grupos independientes.
Hades es el que merece la pena analizar con detenimiento. Sus paquetes contenían inyecciones de comandos en texto plano destinadas a engañar a un analizador basado en un modelo de lenguaje grande (LLM) para que los marcara como seguros, lo que los investigadores describieron como una novedosa técnica de evasión; además, solo funciona como estrategia si los atacantes dan por hecho que las herramientas de IA se interponen ahora entre el paquete y el ingeniero. Para mediados de 2026, eso no es nada descabellado. El caso de Maven Central, ocurrido en diciembre, utilizó un «ruido» similar contra el análisis de aprendizaje automático, por lo que la técnica llevaba meses madurando discretamente. Hades también ejecutaba un monitor de tokens que amenazaba con acciones destructivas si se revocaban los tokens robados de GitHub, lo que reordena discretamente la secuencia de operaciones para cualquiera que intente limpiar el sistema.
PolinRider es el que más preocupa, aunque por una razón diferente. No se trataba de una apropiación oportunista de nombres abandonados, y la vía de acceso descrita resulta más extraña que un volcado de credenciales. Los investigadores afirman que las credenciales robadas de GitHub no fueron en absoluto el vector de ataque. Las víctimas se vieron comprometidas primero a través de una extensión maliciosa de VS Code o un paquete de npm, y la toma de control por parte del mantenedor se produjo posteriormente a través de dominios caducados u otras vías de recuperación de cuentas, todo ello envuelto en la ingeniería social por la que es conocido el equipo de Contagious Interview. Una buena práctica de publicación no hace que ese riesgo desaparezca: el eslabón débil reside en las herramientas del responsable de mantenimiento y en la recuperación de la cuenta, más que en el proceso de lanzamiento.
Más adelante en este artículo se mencionan otras dos campañas de 2026. TrapDoor introdujo 34 paquetes maliciosos en npm, PyPI y Crates.io, y Laravel-Lang tuvo más de 700 versiones contaminadas mediante etiquetas de Git reescritas. TeamPCP es un caso diferente. No tiene una fila propia porque la fila de Mini Shai-Hulud ya corresponde a TeamPCP. La operación más amplia, que Google rastrea como UNC6780, se desarrolló entre febrero y mayo y encadenó ataques a sistemas de CI/CD contra herramientas de seguridad , entre ellas Trivy, Checkmarx y sus imágenes Docker de KICS, además de LiteLLM, en una larga campaña de recolección de credenciales. Más que una fila de la tabla: el mismo mecanismo.
La superficie de ataque se ha desplazado al momento de la instalación
El hilo conductor de todo el año 2026 es el momento oportuno.
Los atacantes aprovecharon la misma vulnerabilidad en npm, PyPI y Cargo desde tres ángulos diferentes, y TrapDoor es el ejemplo más claro porque una de las campañas utilizó los tres. Un hook de postinstalación en npm, la ejecución en el momento de la importación en PyPI y un script `build.rs` que se activa durante el proceso «cargo build» en Crates.io. Desencadenantes diferentes, misma idea. El código se ejecuta como parte de la obtención del paquete, no como parte de su uso. La parte en Go de PolinRider funciona de forma diferente, ya que la carga útil se aloja en los archivos de configuración de las herramientas de compilación y en las tareas de VS Code en lugar de en un hook de instalación, por lo que se activa cuando las herramientas del desarrollador abren el proyecto, en lugar de al ejecutar «go get». El mismo abuso de confianza, pero en un punto diferente del proceso.
Las herramientas estándar parten de la base de que existe un intervalo de tiempo entre el momento en que aparece una dependencia y el momento en que se ejecuta, lo suficientemente largo como para que un análisis pueda detectar algún problema antes. La ejecución durante la instalación elimina ese intervalo para todo aquello que solo inspeccione los artefactos tras la resolución.
Imagina un equipo de ingeniería de 40 personas con un proceso de desarrollo razonablemente maduro. Dependabot abre solicitudes de incorporación de cambios (PR), una herramienta SCA analiza el archivo de bloqueo, la integración continua (CI) bloquea cualquier elemento de alta gravedad y se genera una SBOM en el momento de la compilación. Esa configuración gestiona bien las dependencias con vulnerabilidades conocidas. Sin embargo, es mucho menos eficaz frente a una versión publicada hace una hora que parece una simple actualización de parche, se ejecuta durante la instalación y se retira antes de la hora de comer. No había ningún aviso de seguridad que coincidiera con ningún elemento de esa cadena y, en los casos de axios y Mastra, la carga maliciosa se encontraba un nivel más abajo, dentro de una dependencia que el escáner no tenía motivos para revisar dos veces.
Atención: El «pinning» exacto ofrece más de lo que la gente cree y menos de lo que la gente espera. Cualquiera que haya fijado una versión en un Axios limpio y no haya realizado una instalación nueva durante ese intervalo de tres horas no ha tenido ningún problema. Lo que el «pinning» no te dice es si la versión a la que has cambiado deliberadamente es fiable, y no sirve de nada cuando un rango abierto en una dependencia transitiva resuelve el problema por ti. Así es exactamente como ocurrió con Mastra, ya que la dependencia «easy-day-js» inyectada se declaró como un rango «caret» y npm actualizó alegremente a la versión parcheada y con vulnerabilidades. El «pinning» también asume que el artefacto detrás de una versión no puede cambiar, algo que Laravel-Lang refutó al reescribir las etiquetas históricas para que apuntaran a un nuevo commit.
La comprobación de los paquetes antes de que lleguen al equipo de un desarrollador o a un agente de compilación es uno de los pocos puntos de la cadena en los que se puede detener el código en el momento de la instalación, en lugar de notificarlo a posteriori. Esa es la laguna SecureChain for OSS ha sido diseñado para subsanar, y es también la razón por la que se sitúa a nivel del registro en lugar de añadir un escáner más al final del proceso.
Por qué tu escáner siempre llega tarde
El análisis tradicional de la composición del software centrado en las vulnerabilidades conocidas (CVE) es eficaz para responder a una pregunta concreta: qué componentes con vulnerabilidades conocidas se han incluido en esta compilación. Es realmente eficaz en eso, y merece la pena mantenerlo.
Sin embargo, por sí solo, esto no responde a otra pregunta: ¿es este artefacto, en este preciso momento, lo mismo que publicó su responsable?
Se trata más de un problema de datos que de un problema del producto. El SCA centrado en vulnerabilidades compara tu inventario de dependencias con los datos de los avisos de seguridad, y un aviso solo existe una vez que alguien ha encontrado el paquete malicioso, lo ha notificado y se ha publicado el aviso. La detección suele ser rápida. Socket detectó la versión maliciosa de jscrambler seis minutos después de su publicación, y los paquetes TrapDoor tardaron una media de menos de seis minutos desde su publicación hasta su detección. El aviso que consulta tu escáner es la parte lenta, y muchos de estos incidentes nunca generan un CVE, lo que también explica por qué ninguno de ellos aparecerá jamás en el Catálogo de Vulnerabilidades Explotadas Conocidas de la CISA. Las fuentes de avisos son, por naturaleza, un registro de lo que ya se ha descubierto.
Información de interés: Varias campañas de 2026 publicaron versiones maliciosas que parecían simples actualizaciones de parche, sin que hubiera detrás ningún commit, solicitud de incorporación de cambios (pull request) ni etiqueta que coincidieran. jscrambler 8.14.0 es el caso más claro, ya que los investigadores no encontraron ningún commit, etiqueta ni solicitud de incorporación de cambios para esta versión en el repositorio de GitHub del proyecto, donde la última etiqueta seguía siendo 8.13.0. Los actualizadores convencionales no comprueban si un artefacto se corresponde con un cambio en el código fuente. Al ver un nuevo número de versión, abren una solicitud de incorporación de cambios y algunos equipos la fusionan automáticamente. Un incremento de versión y un cambio verificado no son lo mismo.
Hacia dónde apuntan las cifras del ecosistema
A lo largo de 2024 y la mayor parte de 2025, npm acaparó toda la atención, gracias a sus cifras de adopción y a los scripts de ciclo de vida que se ejecutan automáticamente durante la instalación. Esa atención ya ha llegado a su fin.
TrapDoor afectó a tres ecosistemas en la misma semana de mayo, con 34 paquetes maliciosos y más de 384 versiones en npm, PyPI y Crates.io. Se trataba de herramientas falsas, más que de herramientas secuestradas, con nombres que parecían utilidades que un desarrollador de criptomonedas o de IA instalaría sin pensárselo dos veces, y cada registro tenía su propia ruta de ejecución. También dejó archivos .cursorrules y CLAUDE.md para manipular a los asistentes de programación basados en IA, lo que ofrece una buena idea de hacia dónde se dirige esto.
Packagist también tuvo un mes de mayo complicado. Los atacantes reescribieron todas las etiquetas de Git de cuatro repositorios de localización de Laravel-Lang en un intervalo de unos 90 minutos entre el 22 y el 23 de mayo, y más de 700 versiones históricas acabaron apuntando a una confirmación maliciosa que el autocargador de Composer ejecutó posteriormente en cada solicitud. La vía de acceso fue un token de GitHub filtrado, y el código fuente del proyecto nunca se vio afectado. Por otra parte, una campaña de ocho paquetes ocultó su carga útil en el archivo package.json en lugar de en composer.json, lo que la situaba exactamente donde era menos probable que se fijara una revisión centrada en PHP.
También puedes descubrir las mejores prácticas para proteger tu ecosistema PHP en nuestra guía completa sobre seguridad en Laravel.
Y en diciembre de 2025, justo antes del periodo que abarca este artículo, un libro de Jackson con un nombre similar, fruto de un typosquatting, apareció en Maven Central con una baliza de Cobalt Strike. El truco consistía en un cambio de prefijo: «org.fasterxml» en lugar del «com.fasterxml» que utiliza la biblioteca auténtica, algo que la convención de dominio inverso de Java no detecta. Aikido, que lo descubrió, lo calificó como el primer malware sofisticado que su equipo había detectado en Maven Central, así que hay que interpretarlo como una primicia para esos investigadores en concreto, más que para todo el ecosistema. Al menos, su retirada fue rápida, unos 90 minutos desde la notificación.
Hay que interpretarlo como un cambio en el objetivo de las campañas de seguridad, más que como un antes y un después bien definidos, ya que ya se habían detectado paquetes maliciosos en la mayoría de esos registros anteriormente. Para una empresa poliglota, la conclusión práctica es que las defensas por ecosistema dejan de sumar una cobertura real. Unos controles sólidos en npm, unos hábitos poco rigurosos en PyPI y la ausencia total de medidas en Go o Rust te dejan con la puerta principal cerrada con llave y varias entradas laterales abiertas, y los datos de este año indican que los atacantes ya las están probando.
¿Qué se puede hacer al respecto?
Nada de esto requiere una reestructuración. Todo ello se puede llevar a cabo este trimestre.
Si tienes un ecosistema principal
Lo primero es subsanar esa brecha en el momento de la instalación. Establece «ignore-scripts=true» en el archivo .npmrc siempre que tu proceso de compilación lo permita, y canaliza las instalaciones a través de una capa de registro que filtre los paquetes antes de que se resuelvan. Sin embargo, no consideres que el bloqueo de scripts es la solución definitiva. Dos de las cinco versiones maliciosas de jscrambler trasladaron el dropper fuera del gancho de preinstalación y lo integraron en el código principal del paquete y en la CLI, donde la opción «–ignore-scripts» no tiene ningún efecto.
Si eres políglota
Averigua qué ecosistemas carecen de controles antes de profundizar en aquellos que ya cuentan con algunos. En este modelo de amenazas, las lagunas de cobertura son más graves que las de profundidad. Tanto TrapDoor como PolinRider han demostrado que basta con un solo ecosistema sin controles para echar por tierra todo el trabajo realizado en el resto.
Si dependes de las actualizaciones automáticas de dependencias
Añadir un plazo de espera para los nuevos lanzamientos. Las recomendaciones de mitigación de Unit 42 sugieren bloquear cualquier versión publicada en las últimas 24 a 72 horas, basándose en que la mayoría de los paquetes maliciosos se identifican y eliminan dentro de ese plazo, y Wiz adopta una postura muy similar con un periodo de espera de 24 horas. Una breve cuarentena convierte una buena parte de estos ataques en algo sin importancia, a costa de un ligero retraso en la aplicación de los parches.
Es mejor adelantar un control que añadir otro al final. En este caso, hay dos aspectos que son más importantes que el resto: interceptar un paquete antes de que se resuelva y verificar que el artefacto recibido se corresponde con el código fuente y la compilación de los que dice proceder.
Merece la pena activar la procedencia, con una salvedad. Mastra generaba procedencia en las publicaciones de CI, pero no la exigía, por lo que un token robado aún podía publicar sin certificaciones, mientras que la oleada de Mini Shai-Hulud de TanStack produjo paquetes con procedencia SLSA válida porque el propio proceso estaba viciado. Exigir certificaciones habría impedido el primer caso, pero no el segundo.
El alcance también varía según el ecosistema. La suplantación de cuentas en Go y los hooks de las startups en PyPI son problemas distintos que requieren soluciones diferentes, por lo que cualquier medida de control por la que merezca la pena pagar debe tener en cuenta cómo ejecuta realmente el código cada ecosistema.
En qué situación te deja esto
Aquí no hay nada exótico. 2026 no inventó una nueva clase de vulnerabilidad. Simplemente trasladó la lucha a un lugar al que la mayoría de los equipos no prestaban atención: el momento en que un paquete se resuelve y se ejecuta, en lugar del momento en que alguien finalmente lo analiza. Todas las campañas de esta lista, desde un secuestro de npm de tres horas hasta un módulo de Go al que se accedió a través de una cuenta de mantenedor secuestrada, funcionaron porque se concedió confianza antes de que ningún control tuviera oportunidad de comprobarlo, ya fuera durante la resolución, la instalación, la compilación o el momento en que un editor abrió el proyecto.
Así pues, la verdadera cuestión no es si hay que mantener la detección posterior a la instalación. Hay que mantenerla. La cuestión es si la prevención se adelanta, de modo que un análisis que se ejecute después de que la carga útil ya haya obtenido los secretos de tu infraestructura crítica no sea lo primero que te avise de ello. SecureChain para OSS está pensado para equipos que desean eso sin tener que desarrollarlo ellos mismos.
PREGUNTAS FRECUENTES
¿Qué es un ataque a la cadena de suministro de software?
Un ataque que compromete el software a través de una dependencia de confianza, un sistema de compilación, un repositorio o un canal de distribución, en lugar de atacar directamente a la aplicación. Las campañas de 2026 se dirigieron, en su gran mayoría, a los registros públicos de paquetes y a las cuentas que publican en ellos.
¿Cuántos ataques a la cadena de suministro de software se produjeron en 2026?
No existe una cifra total oficial. Este artículo aborda seis campañas principales confirmadas entre marzo y julio de 2026, y hay varias más que quedan fuera de ese conjunto, entre ellas TrapDoor, Laravel-Lang y la operación más amplia denominada TeamPCP.
¿Sirve una SBOM para prevenir los ataques a la cadena de suministro?
No. Una SBOM recoge los componentes que se han utilizado en una compilación, lo cual resulta útil para la gestión de incidentes y las auditorías. No garantiza que un artefacto incluido en la lista sea el mismo que publicó su responsable, ni impide que el código se ejecute durante la adquisición de dependencias.
¿Qué ecosistemas de paquetes se vieron más afectados?
npm fue el principal escenario de la mayoría de los incidentes más destacados de 2026, mientras que PyPI, los módulos de Go, Crates.io y Packagist fueron objeto de campañas específicas que afectaron a varios paquetes a mediados de año. Maven Central tuvo su propio momento de protagonismo justo antes de que comenzara el año.
