Para: personas y organizaciones que desarrollan o gestionan repositorios en GitHub, y quienes usan GitHub Actions o credenciales de nube (incluida la federación OIDC). Este artículo se basa en publicaciones públicas de las empresas de seguridad que investigaron y en un aviso de un proveedor relacionado. No trata los pasos del ataque.
続報待ち：この記事は公式発表に合わせて更新します
- A quién afecta
personas y organizaciones que desarrollan o gestionan repositorios en GitHub, y quienes usan GitHub Actions o credenciales de nube (incluida la federación OIDC).
- Confirmado hasta ahoraVer la tabla ↓
- Unas 4.800 cuentas abusadas
- Pull requests de sondeo a 61.764 repositorios
- Repositorios con cambios maliciosos
3 más
- El código malicioso se ejecutó y se enviaron credenciales
- Robo de secretos y credenciales de nube
- Contaminación de paquetes publicados
Señalado como posiblemente afectado
- Persistencia en la nube (ajustes que sobreviven a la rotación)
- Aún sin confirmar
- Cifra final de cuentas y repositorios afectados (las empresas que investigan cuentan de forma distinta)
- Cómo se robaron los tokens por primera vez (no establecido para la campaña en conjunto, salvo el caso del proveedor de nube)
- Una declaración oficial de GitHub (no indicada a fecha de la comprobación del 14 de noviembre)
2 más
- Relación con una campaña distinta de octubre del mismo actor (las empresas A y C no afirman que sea un único actor)
- Finalización de la revocación de tokens del proveedor de nube (el proveedor añadió que se detuvo a medias)
- Qué hacer ahoraVer los pasos ↓
- Revise si hay pull requests, ramas y ejecuciones de Actions que no reconozca
- Revoque los tokens, autorizaciones y sesiones de la cuenta comprometida
- Si los cambios maliciosos pueden haberse ejecutado, rote todos los secretos y permisos de nube que ese repositorio podía leer
3 más
- Revise en la nube los cambios que sobreviven a una rotación
- Haga inventario de sus tokens y apps de terceros
- Compruebe que sus propias apps no exponen la carpeta de control de versiones
- Dónde verificarlo (fuente)Todas las fuentes ↓
- GitHub, «Changelog» y «Security» (blog oficial y registro de cambios; sin entrada sobre esto; consultado el 14 de noviembre)
- Última comprobación
- a fecha del 14 de noviembre de 2026
Próximos avisos y qué comprobamos
Las publicaciones de las empresas que investigan salieron todas el 12 de noviembre y deben leerse como sujetas a revisión. A fecha del 14 de noviembre, el blog, el registro de cambios y el historial de estado de GitHub no mostraban ninguna entrada sobre esto.
Qué deben hacer hoy los propietarios de repositorios y los desarrolladores
Revise si hay pull requests, ramas y ejecuciones de Actions que no reconozca
En cada repositorio en el que su cuenta pueda escribir (incluidas las organizaciones donde es colaborador), compruebe estas tres cosas desde el 10 de noviembre. Según la empresa A, de 61.839 pull requests de sondeo, 10.431 fueron a repositorios que la cuenta no posee, alcanzados mediante acceso de colaborador u organización.
- Pull requests que no abrió usted ni un compañero. Aunque el título parezca inofensivo (como una actualización de documentación), el mismo patrón en muchos repositorios es una señal de alerta
- Ramas efímeras que no reconozca, o indicios de que se crearon y borraron ramas
- Historial de ejecuciones de Actions con ejecuciones que no reconozca o huecos en los números de ejecución. Las empresas A y C escriben que el atacante borra ejecuciones y registros en aproximadamente un minuto, por lo que un hueco en la numeración es una pista. Revise también el registro de auditoría de la organización
Si encuentra alguno de estos indicios, continúe a continuación. La empresa A escribe que una cuenta con un pull request de sondeo debe tratarse como comprometida aunque la fase posterior no se ejecutara.
Revoque los tokens, autorizaciones y sesiones de la cuenta comprometida
Este orden sigue la guía de las empresas B y C.
- Revoque los tokens de acceso personal, las autorizaciones a apps de terceros (apps OAuth y apps de GitHub), las claves SSH y las sesiones activas, y vuelva a crear solo lo necesario
- Active la autenticación en dos pasos. Un token ya robado funciona sin ella, por lo que primero hay que revocar el token (opinión de este sitio)
- Cierre el pull request de sondeo y borre las ramas que no reconozca. Antes de borrar, anote bajo qué cuenta se crearon
Si los cambios maliciosos pueden haberse ejecutado, rote todos los secretos y permisos de nube que ese repositorio podía leer
Las empresas A y B escriben que, si el cambio malicioso se ejecutó, todos los secretos y roles de nube disponibles para ese flujo de trabajo deben tratarse como robados.
- Reemita los secretos y variables de Actions (a nivel de repositorio, de entorno y de organización), los tokens de publicación (incluidos los de paquetes) y las claves de despliegue, e invalide los antiguos
- Si usa OIDC para acceder a una cuenta de nube, incluya ese permiso de nube (siguiente paso)
- Si compiló en una máquina de desarrollo un repositorio que pudo recibir un cambio malicioso, rote también las credenciales que esa máquina podía leer (claves SSH, credenciales de nube, tokens de publicación de paquetes, etc.). Las empresas B y C informan de cambios que se ejecutan al instalar paquetes
- Si publicó paquetes desde el 10 de noviembre, compruebe que las versiones publicadas no contienen el cambio malicioso; si lo contienen, retírelas y vuelva a publicar desde un estado limpio
Revise en la nube los cambios que sobreviven a una rotación
Como cambios que sobreviven a la rotación de secretos, la empresa A menciona la reescritura de una política de confianza de un rol de AWS y la adición de credenciales federadas de Azure (la empresa B señala también claves de acceso de AWS dejadas atrás). Revise estas dos áreas tanto en los registros de auditoría como en los ajustes actuales.
- AWS: claves de acceso recién creadas y cambios en las políticas de confianza de roles (si la confianza se ha ampliado a cuentas o condiciones no previstas)
- Azure (Entra ID): credenciales federadas añadidas a aplicaciones que apuntan de vuelta a un repositorio
Aparte, como comprobación de escalada de privilegios con credenciales robadas, revise también Google Cloud (uso inusual de cuentas de servicio o llamadas de emisión de tokens) y Vault o Kubernetes (inicios de sesión OIDC de GitHub que no reconozca).
Aunque no encuentre nada, compruebe si sus condiciones de confianza OIDC están acotadas al repositorio, la rama y el entorno (véase «Qué revisar» más abajo).
Haga inventario de sus tokens y apps de terceros
En los ajustes de GitHub, haga una lista de lo siguiente y elimine lo que no necesite o no reconozca.
- Tokens de acceso personal: borre los que no use; para el resto, limite repositorios, permisos y vida útil
- Apps OAuth y apps de GitHub que autorizó, incluidas las conectadas para alojamiento o despliegue de CI. Elimine la autorización de las que ya no use
- Claves SSH y claves de despliegue: elimine las que no use y las que no tengan propietario
- Permisos de las cuentas de bots y de automatización: compruebe si alguna puede saltarse las reglas de ramas protegidas
Según el aviso del proveedor de nube, es necesario reconectar la app de ese proveedor. Si la usa, siga las instrucciones del proveedor.
Compruebe que sus propias apps no exponen la carpeta de control de versiones
El mismo proveedor explica que algunas apps desplegadas mediante GitHub publicaron todo el directorio de compilación, por lo que podía recuperarse un token dejado allí. Compruebe que la URL pública de su app no sirve el contenido de la carpeta de control de versiones (.git). Si lo hace, exclúyala de la imagen, vuelva a desplegar y rote las credenciales que contuviera. Compruebe también si su plataforma de despliegue usa un mecanismo similar.
Qué pasó (según las empresas que investigan y el proveedor relacionado)
Lo siguiente se basa en publicaciones públicas de las empresas de seguridad A, B y C (todas del 12 de noviembre de 2026) y en un aviso de un proveedor de nube (conocido la noche del 12 de noviembre, adenda el 13 de noviembre). Son relatos de las propias partes y de los investigadores y GitHub no los ha confirmado. Las horas son UTC salvo que se indique otra cosa.
10 nov., hacia las 12:45
Según la empresa A, el atacante empezó a operar, con tokens robados, en los repositorios en los que cada token podía escribir. En cada repositorio envió primero un pull request de sondeo, luego hizo un cambio malicioso, lo revirtió en aproximadamente un minuto y borró la ejecución y los registros. La empresa B también sitúa el primer cambio malicioso a las 12:46.11 nov., 15:00
Fin del periodo de los 61.839 pull requests de sondeo contados por la empresa A.12 nov., 04:36
Fin del periodo de los 8.093 repositorios públicos con cambios maliciosos contados por la empresa B.12 nov., 07:40
Momento en que la empresa C contó más de 63.000 pull requests de sondeo. Las empresas A, B y C publicaron sus textos el mismo día.12 nov., 22:00 (zona horaria no indicada)
Un proveedor de nube publicó un aviso diciendo que había sabido (el 12 de noviembre; sin hora) que una parte no autorizada había usado tokens emitidos a su app de GitHub en repositorios de clientes (aviso del proveedor).13 nov., 15:54
El proveedor añadió que la revocación de todos los tokens de usuario se detuvo a medias y que GitHub está investigando (aviso del proveedor).
Token robado válido
Un pull request de sondeo comprueba si puede escribir
↓→
Cambio malicioso
Recopila secretos de CI y credenciales de nube y los envía al exterior
↓→
Borrado de huellas
Revierte el cambio, borra ejecuciones y registros; pueden quedar ajustes en la nube
Cifras por fuente (no las sume)
| Fuente (papel) | Qué se contó | Cifra | Nota |
|---|---|---|---|
| Empresa A (primera en informar) | Cuentas que enviaron / repositorios que recibieron pull requests de sondeo | 4.837 cuentas / 61.764 repositorios | Alrededor del 92 % siguen abiertos (el denominador son los 10.431 PR enviados a repositorios que la cuenta no posee) |
| Empresa A | Repositorios donde el código malicioso se ejecutó y se enviaron credenciales | Al menos 1.835 (1.806 en otro lugar) | Dos cifras dentro del texto; dice que el número puede ser un mínimo |
| Empresa A | Cuentas que pueden publicar paquetes | Al menos 50 | Derechos de publicación en npm, Go, PyPI, Packagist y crates, según su entendimiento |
| Empresa B | Repositorios públicos con cambios maliciosos (10 nov. 12:46 a 12 nov. 04:36) | 8.093 | No es el número donde se ejecutó. El desglose suma 8.096; la diferencia no se explica |
| Empresa B | Pull requests de sondeo | 61.879 PR / 4.833 cuentas / 61.734 repositorios | No incluidos en los 8.093 |
| Empresa C | Pull requests de sondeo (a 12 nov., 07:40) | Más de 63.000 | Alrededor del 90 % abiertos. 173 de ellos (19 cuentas) vinieron de tokens emitidos a la app de GitHub de un proveedor de nube |
| Proveedor de nube (su propio aviso) | Pull requests de sondeo hallados en cuentas de clientes afectados | Más de 250 | Dice que se vio afectado un pequeño número de clientes |
La empresa B escribe que sus cifras proceden de la búsqueda de GitHub, que cubre solo las ramas predeterminadas de repositorios públicos, por lo que el total real probablemente sea mayor.
- Qué se robó
- Secretos y variables de GitHub Actions, tokens de flujos de trabajo, credenciales de nube (AWS, Azure, Google Cloud) y credenciales de desarrolladores y de servicios de IA (empresa A)
- Causa (según los investigadores)
- Abuso de tokens robados válidos, no un fallo de GitHub Actions (empresa C). Los commits aparecen con los nombres de los usuarios reales, sin firmar, lo que apunta a tokens robados (inferencia de la empresa B)
- Cómo se obtuvieron los tokens
- No establecido para la campaña en conjunto. Para la parte que llegó a través de la app del proveedor de nube, la empresa C también dice que no pudo establecer cómo se obtuvieron los tokens y que no tiene pruebas de una vulneración de la infraestructura del proveedor
- Relato del proveedor de nube
- Su infraestructura no fue vulnerada. En los despliegues basados en GitHub se dejó un token en un archivo de configuración del directorio de compilación, y algunas apps publicaron todo el directorio, por lo que podía recuperarse. Se vio afectado un pequeño número de clientes y se les contactó individualmente. Empezó a revocar todos los tokens de usuario emitidos a la app y cambió el proceso de despliegue. Dice que los despliegues mediante su herramienta de línea de comandos, sus tokens de API y las apps en ejecución no se ven afectados
- Impacto en paquetes
- La empresa B examinó 218 paquetes de npm, Go y Packagist cuyos repositorios de origen recibieron cambios maliciosos. Existieron versiones maliciosas en tres paquetes (uno de Packagist, dos de Go), cinco versiones en total en su lista; no encontró otras. No se comprobaron PyPI y otros. La empresa A también ve como objetivo del atacante los secretos de CI, y la contaminación de paquetes como un efecto secundario de la publicación automatizada
- Relación con una campaña distinta de octubre
- La empresa A dice que las cuentas afectadas por una campaña de octubre tenían más probabilidades de verse afectadas en esta, pero las evalúa como operaciones distintas de actores distintos. La empresa C también dice que la coincidencia no demuestra un único actor (los tokens robados se comparten y se venden)
- Declaración oficial de GitHub
- No indicada (blog, registro de cambios e historial de estado consultados el 14 de noviembre de 2026)
Qué se sabe y qué no
Estado a fecha del 14 de noviembre de 2026. Actualizaremos la columna de estado cuando haya novedades.
| Elemento | Qué se publicó | Estado |
|---|---|---|
| Unas 4.800 cuentas abusadas | Tokens robados válidos usados para enviar pull requests de sondeo | Confirmado (empresas A y B) |
| Pull requests de sondeo a 61.764 repositorios | Una cifra distinta de si hubo cambios después | Confirmado (empresa A; la empresa B cuenta 61.734) |
| Repositorios con cambios maliciosos | 8.093 repositorios públicos | Confirmado (empresa B; solo repositorios públicos y ramas predeterminadas) |
| El código malicioso se ejecutó y se enviaron credenciales | Al menos 1.835 repositorios | Confirmado (empresa A; da también 1.806) |
| Robo de secretos y credenciales de nube | En los repositorios donde se ejecutó | Confirmado (empresas A y B) |
| Persistencia en la nube (ajustes que sobreviven a la rotación) | Reescritura de una política de confianza de un rol de AWS y adición de credenciales federadas de Azure (empresa A); la empresa B señala también claves de acceso de AWS dejadas atrás | Posible (empresas A y B) |
| Explotación de un fallo de GitHub Actions | No se usó | No incluido (empresa C) |
| Contaminación de paquetes publicados | Tres paquetes (uno de Packagist, dos de Go), cinco versiones en total (no se hallaron otros) | Confirmado (empresa B; no se comprobaron PyPI y otros) |
| Vulneración de la infraestructura del proveedor de nube | Sin pruebas (empresa C); el proveedor niega una vulneración | No confirmado (empresa C, el proveedor) |
| Cómo se robaron los tokens por primera vez | Explicado para parte de los tokens de la app del proveedor de nube; desconocido en conjunto | En investigación |
| Vínculo con una campaña distinta de octubre | La empresa A ve operaciones distintas; la empresa C no afirma que sea una | En investigación |
| Declaración oficial de GitHub | No se encontró ninguna | No indicada |
| Una lista confirmada de organizaciones afectadas | No publicada | No indicada |
Cómo leer esto: las cifras cuentan cosas distintas y han cambiado en dos días
Los 1.835 de la empresa A son una estimación de ejecuciones, los 8.093 de la empresa B son repositorios públicos con cambios maliciosos, y los 63.000 de la empresa C son pull requests de sondeo. No son lo mismo. Muchos repositorios que solo recibieron un pull request de sondeo pueden no haber sufrido cambios ni robo. Sin embargo, según la empresa A, una cuenta que envió un pull request de sondeo debe tratarse como comprometida aunque no hubiera cambio posterior.
Qué puede pasar cuando se usan tokens robados válidos
Lo siguiente es general y no significa que esto ocurriera aquí. Lo que las empresas que investigan informan que ocurrió está en «Qué pasó» más arriba.
Si un token es válido, el atacante puede escribir como un usuario legítimo. No hay debilidad en una función de GitHub que explotar, y una actualización de software no lo detiene. Si una cuenta con acceso de escritura puede modificar un flujo de trabajo de CI, los secretos y permisos de nube que ese flujo puede leer pasan a ser objetivo a la vez. Si la confianza OIDC con una cuenta de nube es laxa (cualquier rama o flujo de trabajo puede entrar), pueden emitirse credenciales temporales aunque no haya un secreto almacenado. Si su cuenta es colaboradora en otra organización, el daño se extiende más allá de lo que usted posee.
Qué revisar en CI y en los permisos de nube
Esta sección no es una evaluación de las partes afectadas. Basada en los informes de los investigadores, se centra en qué comprobar en su propia configuración como opinión de este sitio.
No mantenga tokens amplios ni duraderos
Aquí se usaron tokens robados válidos. Limite los tokens de acceso personal a repositorios y permisos concretos, deles una vida útil corta y bórrelos cuando ya no se usen (use el tipo de permisos detallados). Autorice apps de terceros solo para el alcance que necesiten (opinión de este sitio).
Acote los permisos de los flujos de trabajo y las condiciones para entrar en la nube
Haga que el permiso predeterminado de los flujos de trabajo sea de solo lectura y conceda escritura solo donde haga falta. Acote la confianza OIDC de la nube al repositorio, la rama y el entorno, de modo que no cualquier flujo de trabajo pueda entrar. Poner aprobadores en los secretos de entorno hace que un flujo de trabajo reescrito no pueda leer sin más los secretos de producción (opinión de este sitio).
Corrija la protección de ramas con revisiones obligatorias
La empresa A escribe que el código incluye un mecanismo pensado para sortear la protección de ramas. No confíe solo en los nombres de las comprobaciones: exija revisiones aprobatorias de los propietarios del código y no permita excepciones para cuentas de bots (opinión de este sitio).
Detecte huecos en los números de ejecución y cambios de configuración en la nube
En este caso se borraron ejecuciones y registros y los huecos en la numeración fueron la pista. Conserve el registro de auditoría de la organización y configure alertas para cambios en flujos de trabajo y para la creación de claves de acceso en la nube, cambios en políticas de confianza y federación de identidad añadida. La empresa C recomienda además limitar el tráfico saliente de CI a una lista de permitidos.
No guarde secretos en el repositorio
Aparte de los secretos de CI, las credenciales del historial del código se llevan junto con el token robado de cualquiera que pueda leerlas. Para detectarlas antes del commit, véase Cómo detener secretos antes del commit con gitleaks; para el orden de revocación, véase 540.000 credenciales expuestas en GitHub siguen siendo válidas.
Fuentes (registros públicos)
Los hechos de este artículo proceden de la siguiente información pública. GitHub no tiene una declaración oficial al respecto (consultado el 14 de noviembre). No se tratan los detalles de los pasos del ataque.
- GitHub, «Changelog» y «Security» (blog oficial y registro de cambios; sin entrada sobre esto; consultado el 14 de noviembre) — github.blog / github.blog
- GitHub Status (historial oficial de incidentes; sin entrada sobre esto; consultado el 14 de noviembre) — githubstatus.com
- Aviso de un proveedor de nube, «Security: GitHub tokens exposed by apps deployed from GitHub» (foro oficial de la comunidad; conocido el 12 de noviembre, adenda el 13 de noviembre; consultado el 14 de noviembre) — community.fly.io
- Empresa A (empresa de seguridad; primera en informar), «wfx-loot campaign pushes CI secret stealer to tens of thousands of repositories» (12 de noviembre de 2026; consultado el 14 de noviembre) — aikido.dev
- Empresa B (empresa de seguridad), «wfx: GitHub Actions Credential Stealer Hits 8,000 Repos» (12 de noviembre de 2026; consultado el 14 de noviembre) — safedep.io
- Empresa C (empresa de seguridad), «WFX Phantom: The GitHub Actions Secret Stealer That Deletes Its Tracks» (12 de noviembre de 2026; consultado el 14 de noviembre) — stepsecurity.io
- Prensa: BleepingComputer, «Hackers compromise 4,800 GitHub accounts to steal cloud credentials» (consultado en noviembre; cobertura del texto de la empresa A) — bleepingcomputer.com
Historial de actualizaciones
2026-11-14: Primera versión. Basada en las publicaciones públicas de tres empresas de seguridad (todas del 12 de noviembre) y en el aviso de un proveedor de nube. GitHub no tiene una declaración oficial. Donde los informes de prensa difieren, se trata como fuente primaria la publicación original de cada parte. Actualizaremos cuando se publique más.
Lectura recomendada
- Credenciales publicadas que siguen siendo válidas porque no se revocan: 540.000 credenciales expuestas en GitHub siguen siendo válidas
- Otro caso en el que se atacó el desarrollo basado en GitHub: El ataque a la cadena de suministro de TanStack y Nx
- Orden de revocación y daños a través de paquetes: Cómo defenderse de los ataques a la cadena de suministro de npm
- Proteger su cuenta: Autenticación en dos pasos de GitHub / Conceptos básicos de variables de entorno y claves de API
- Incidentes que ocurren con credenciales legítimas: Las brechas de 2026 ocurren con credenciales legítimas
- Otros incidentes de 2026: Filtraciones de datos y ciberataques de 2026