Tronlar
Gamma
Verificación en dos pasos activada
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
Una nueva campaña de ataques contra GitHub ha puesto en alerta a los desarrolladores.
Según una investigación publicada el 12 de noviembre de 2026 por Aikido Security, los atacantes han utilizado las credenciales de 4.837 cuentas comprometidas para introducir código malicioso en repositorios a los que tenían acceso.
Los investigadores detectaron intentos de ataque en 61.764 repositorios, de los cuales al menos 1.806 llegaron a ejecutar código diseñado para robar credenciales.
Lo preocupante es que los atacantes no buscaban simplemente modificar archivos.
Su objetivo era conseguir las claves y secretos utilizados por los sistemas de integración continua (CI/CD), especialmente GitHub Actions, para acceder posteriormente a otros servicios.
🔴 ¿Cómo funcionaba el ataque?
Los atacantes utilizaban cuentas de GitHub previamente comprometidas para comprobar en qué repositorios podían realizar cambios.
Primero creaban una rama llamada
Cuando encontraban un repositorio con los permisos adecuados, introducían código malicioso en los procesos automatizados del proyecto.
Ese código estaba preparado para recopilar información como:
Después de ejecutar el código, los atacantes revertían los cambios, en ocasiones en menos de un minuto, y eliminaban los registros de ejecución cuando podían.
Esto complica bastante la detección, porque un repositorio puede parecer normal aunque sus credenciales hayan quedado expuestas.
💻 También se han detectado paquetes afectados
La investigación identifica como maliciosa la versión 3.14.3 del paquete
El propio repositorio de paquetes muestra un aviso relacionado con malware.
También se mencionan dos versiones del módulo de Go
En el caso del módulo de Go, el código malicioso se encontraba en archivos de GitHub Actions y no en el código del módulo ni en sus binarios.
Por tanto, instalar ese módulo no implica necesariamente haber ejecutado el malware, aunque los investigadores recomiendan evitar esas versiones.
🔎 Cómo comprobar si tu repositorio puede estar afectado
Aikido ha publicado varios indicadores que pueden ayudar a identificar esta campaña.
Ramas sospechosas:
Los dos últimos patrones representan nombres de ramas variables, no nombres literales.
Título de pull request utilizado:
Mensajes de commits relacionados:
También se han identificado archivos con nombres similares a:
En algunos casos, los atacantes modificaban el archivo
Identificador SHA-256 del script malicioso:
Direcciones utilizadas para recibir los datos robados:
Importante: encontrar alguno de estos indicadores no demuestra por sí solo que se hayan robado credenciales, pero sí es motivo suficiente para investigar.
Además, la ausencia de archivos sospechosos o registros de ejecución tampoco garantiza que un repositorio esté limpio, porque los atacantes intentaban eliminar sus huellas.
🛡️ ¿Qué hacer si encuentras alguna de estas señales?
Si utilizáis GitHub para gestionar proyectos, conviene revisar los pull requests, los commits y el historial de GitHub Actions desde el 10 de noviembre.
Si encontráis actividad sospechosa:
Un detalle especialmente preocupante es que los investigadores encontraron técnicas que podían mantener el acceso incluso después de cambiar determinadas credenciales.
Por ejemplo, el malware podía modificar políticas de confianza de AWS o añadir credenciales de identidad federada en Azure.
Por eso, cambiar las contraseñas o los tokens no siempre es suficiente: también hay que revisar los permisos y las configuraciones de seguridad.
🔗 ¿Está relacionado con los ataques de octubre?
Aikido encontró coincidencias con cuentas afectadas por la campaña GhostAction del pasado octubre.
Según los investigadores, las cuentas comprometidas durante aquella campaña tenían una probabilidad mucho mayor de aparecer también en este nuevo ataque.
En más de 100 repositorios, el nuevo código malicioso se añadió a archivos utilizados anteriormente por GhostAction.
Sin embargo, todavía no hay pruebas suficientes para afirmar que ambos ataques sean obra del mismo grupo.
La infraestructura y las técnicas utilizadas presentan diferencias, y las credenciales robadas pueden terminar en manos de distintos atacantes.
Tampoco se conoce públicamente cómo consiguieron inicialmente las credenciales de las 4.837 cuentas.
📅 ¿Qué se sabe a 12 de noviembre de 2026?
Por ahora, las principales cifras conocidas son:
Estas cifras proceden de repositorios públicos que pudieron analizarse.
Los investigadores advierten que también podrían existir repositorios privados afectados.
Además, se detectó nuevas solicitudes sospechosas durante la mañana del 12 de noviembre, aunque no pudo confirmar si llegaron a ejecutar el malware.
No se ha demostrado que los servidores de GitHub hayan sido hackeados directamente.
Lo documentado es el uso de credenciales de cuentas comprometidas para actuar sobre repositorios con permisos de escritura.
Para quienes utilizamos GitHub en proyectos web, aplicaciones o despliegues automatizados, merece la pena revisar las cuentas y los repositorios, especialmente si tenemos configuradas claves API o credenciales de servidores.
No hace falta que alguien consiga directamente la contraseña de nuestro servidor: si logra ejecutar código en un workflow con permisos suficientes, puede acceder a información igual de sensible.
🔗 Fuentes
Importante: la información corresponde a las investigaciones publicadas el 12 de noviembre de 2026.
El alcance del ataque podría cambiar conforme aparezcan nuevos datos.
Según una investigación publicada el 12 de noviembre de 2026 por Aikido Security, los atacantes han utilizado las credenciales de 4.837 cuentas comprometidas para introducir código malicioso en repositorios a los que tenían acceso.
Los investigadores detectaron intentos de ataque en 61.764 repositorios, de los cuales al menos 1.806 llegaron a ejecutar código diseñado para robar credenciales.
Lo preocupante es que los atacantes no buscaban simplemente modificar archivos.
Su objetivo era conseguir las claves y secretos utilizados por los sistemas de integración continua (CI/CD), especialmente GitHub Actions, para acceder posteriormente a otros servicios.
🔴 ¿Cómo funcionaba el ataque?
Los atacantes utilizaban cuentas de GitHub previamente comprometidas para comprobar en qué repositorios podían realizar cambios.
Primero creaban una rama llamada
wfx-docs y abrían una solicitud de cambios (pull request) con el título docs: dependency audit notes.Cuando encontraban un repositorio con los permisos adecuados, introducían código malicioso en los procesos automatizados del proyecto.
Ese código estaba preparado para recopilar información como:
- Tokens de GitHub y secretos de GitHub Actions.
- Credenciales de AWS, Azure y Google Cloud.
- Claves SSH y accesos a servidores.
- Tokens de npm, PyPI y otros gestores de paquetes.
- Variables de entorno y archivos de configuración con credenciales.
- Información del repositorio, commits recientes y artefactos de ejecución.
Después de ejecutar el código, los atacantes revertían los cambios, en ocasiones en menos de un minuto, y eliminaban los registros de ejecución cuando podían.
Esto complica bastante la detección, porque un repositorio puede parecer normal aunque sus credenciales hayan quedado expuestas.
💻 También se han detectado paquetes afectados
La investigación identifica como maliciosa la versión 3.14.3 del paquete
digitalelvis/neuronai-studio, publicado en Packagist.El propio repositorio de paquetes muestra un aviso relacionado con malware.
También se mencionan dos versiones del módulo de Go
github.com/onuragtas/docker-env:v1.0.278v1.0.280
En el caso del módulo de Go, el código malicioso se encontraba en archivos de GitHub Actions y no en el código del módulo ni en sus binarios.
Por tanto, instalar ese módulo no implica necesariamente haber ejecutado el malware, aunque los investigadores recomiendan evitar esas versiones.
🔎 Cómo comprobar si tu repositorio puede estar afectado
Aikido ha publicado varios indicadores que pueden ayudar a identificar esta campaña.
Ramas sospechosas:
Insertar CODE, HTML o PHP:
wfx-docs
chore/[a-z0-9]{8}
ci-check-[0-9]{4}Los dos últimos patrones representan nombres de ramas variables, no nombres literales.
Título de pull request utilizado:
Insertar CODE, HTML o PHP:
docs: dependency audit notesMensajes de commits relacionados:
Insertar CODE, HTML o PHP:
ci: refresh build cache
chore: add ci helper
chore: add dependency audit workflow
ci: restore
ci: cleanupTambién se han identificado archivos con nombres similares a:
Insertar CODE, HTML o PHP:
.ci-xxxxxx.sh
.github/workflows/build-audit-xxxxxx.ymlEn algunos casos, los atacantes modificaban el archivo
package.json para ejecutar scripts mediante postinstall.Identificador SHA-256 del script malicioso:
Insertar CODE, HTML o PHP:
89695abb392d5cfd4972672961e644bb46baa98aa1ed7173c2a2816c762735cfDirecciones utilizadas para recibir los datos robados:
Insertar CODE, HTML o PHP:
194.150.166[.]244:8080/exfil
18.143.168[.]96:8080/exfilImportante: encontrar alguno de estos indicadores no demuestra por sí solo que se hayan robado credenciales, pero sí es motivo suficiente para investigar.
Además, la ausencia de archivos sospechosos o registros de ejecución tampoco garantiza que un repositorio esté limpio, porque los atacantes intentaban eliminar sus huellas.
🛡️ ¿Qué hacer si encuentras alguna de estas señales?
Si utilizáis GitHub para gestionar proyectos, conviene revisar los pull requests, los commits y el historial de GitHub Actions desde el 10 de noviembre.
Si encontráis actividad sospechosa:
- Revisad la seguridad de la cuenta de GitHub, sus sesiones, tokens personales, claves SSH y aplicaciones autorizadas.
- Comprobad qué repositorios podían modificarse desde esa cuenta.
- Investigad los workflows sospechosos y las ejecuciones eliminadas.
- Si se confirma que el código malicioso llegó a ejecutarse, revocad y sustituid todas las credenciales a las que podía acceder.
- Revisad los accesos a AWS, Azure, Google Cloud y otros servicios conectados.
- Comprobad que los atacantes no hayan creado nuevos usuarios, claves o permisos para mantener el acceso.
Un detalle especialmente preocupante es que los investigadores encontraron técnicas que podían mantener el acceso incluso después de cambiar determinadas credenciales.
Por ejemplo, el malware podía modificar políticas de confianza de AWS o añadir credenciales de identidad federada en Azure.
Por eso, cambiar las contraseñas o los tokens no siempre es suficiente: también hay que revisar los permisos y las configuraciones de seguridad.
🔗 ¿Está relacionado con los ataques de octubre?
Aikido encontró coincidencias con cuentas afectadas por la campaña GhostAction del pasado octubre.
Según los investigadores, las cuentas comprometidas durante aquella campaña tenían una probabilidad mucho mayor de aparecer también en este nuevo ataque.
En más de 100 repositorios, el nuevo código malicioso se añadió a archivos utilizados anteriormente por GhostAction.
Sin embargo, todavía no hay pruebas suficientes para afirmar que ambos ataques sean obra del mismo grupo.
La infraestructura y las técnicas utilizadas presentan diferencias, y las credenciales robadas pueden terminar en manos de distintos atacantes.
Tampoco se conoce públicamente cómo consiguieron inicialmente las credenciales de las 4.837 cuentas.
📅 ¿Qué se sabe a 12 de noviembre de 2026?
Por ahora, las principales cifras conocidas son:
- 4.837 cuentas de GitHub utilizadas por los atacantes.
- 61.764 repositorios que recibieron solicitudes de prueba.
- Al menos 1.806 repositorios donde llegó a ejecutarse el código malicioso.
- Una versión maliciosa identificada en Packagist.
- Dos versiones de un módulo de Go con workflows maliciosos.
Estas cifras proceden de repositorios públicos que pudieron analizarse.
Los investigadores advierten que también podrían existir repositorios privados afectados.
Además, se detectó nuevas solicitudes sospechosas durante la mañana del 12 de noviembre, aunque no pudo confirmar si llegaron a ejecutar el malware.
No se ha demostrado que los servidores de GitHub hayan sido hackeados directamente.
Lo documentado es el uso de credenciales de cuentas comprometidas para actuar sobre repositorios con permisos de escritura.
Para quienes utilizamos GitHub en proyectos web, aplicaciones o despliegues automatizados, merece la pena revisar las cuentas y los repositorios, especialmente si tenemos configuradas claves API o credenciales de servidores.
No hace falta que alguien consiga directamente la contraseña de nuestro servidor: si logra ejecutar código en un workflow con permisos suficientes, puede acceder a información igual de sensible.
🔗 Fuentes
Importante: la información corresponde a las investigaciones publicadas el 12 de noviembre de 2026.
El alcance del ataque podría cambiar conforme aparezcan nuevos datos.
