Incidente de seguridad en GitHub: riesgos reales y cómo proteger tus repositorios

Inicio » Windows » Incidente de seguridad en GitHub: riesgos reales y cómo proteger tus repositorios

La creciente dependencia de GitHub, GitLab y sus flujos de CI/CD ha convertido a estas plataformas en un objetivo prioritario para los atacantes. Lo que antes se veía solo como “un repositorio de código” ahora es, en realidad, el corazón de la cadena de suministro de software de muchas empresas, desde pequeños proyectos open source hasta grandes corporaciones.

En los últimos meses han salido a la luz incidentes de seguridad que afectan tanto a repositorios privados como a utilidades de GitHub Actions y a mecanismos de comentarios, dejando claro que un simple descuido de configuración, un bug de diseño o una acción maliciosa aparentemente menor pueden acabar en filtraciones masivas de datos, robo de credenciales o distribución de malware a través de canales completamente legítimos.

Incidentes recientes: de Red Hat Consulting a utilidades maliciosas en GitHub Actions

Uno de los casos más llamativos ha sido el acceso no autorizado a una instancia de GitLab usada por Red Hat Consulting, que inicialmente se confundió en algunos medios con un problema en GitHub, lo que generó bastante ruido y confusión hasta que se aclaró que la plataforma afectada era GitLab.

Según la información difundida por medios especializados, un grupo de extorsión que se hace llamar Crimson Collective afirmó haber accedido a repositorios privados de la consultora y haberse llevado varios cientos de gigabytes de datos comprimidos, con un impacto potencial sobre miles de proyectos internos.

Los atacantes aseguraron haber comprometido alrededor de 28.000 proyectos y cerca de 800 Customer Engagement Reports (CERs), informes de consultoría donde suelen aparecer detalles muy sensibles sobre la infraestructura de los clientes: configuraciones, credenciales, topologías de red y otros datos que, en manos equivocadas, se convierten en un trampolín perfecto hacia intrusiones adicionales en redes corporativas.

En su comunicación pública, Red Hat reconoció el incidente, pero fue prudente con las cifras y matices facilitados por los atacantes. La compañía recalcó que había detectado accesos no autorizados a una instancia de GitLab interna, había revocado ese acceso, aislado el entorno y notificado a las autoridades, iniciando una investigación en profundidad para determinar el alcance real de la brecha.

De acuerdo con ese comunicado, la instancia afectada contenía principalmente datos de proyectos de consultoría como especificaciones técnicas, fragmentos de código de ejemplo y comunicaciones internas, y no se esperaba que almacenase información personal especialmente sensible. Hasta el momento del último informe, el análisis no había identificado datos personales delicados, aunque Red Hat se comprometió a avisar individualmente a los clientes que pudieran verse impactados.

Para el resto de clientes, la compañía subrayó que, con la información disponible, no había indicios de que el incidente afectara a otros productos, servicios ni a su cadena de suministro de software, manteniendo su confianza en la integridad de los canales oficiales de descarga.

Por su parte, Crimson Collective afirmó que en los repositorios y en los CERs hallaron tokens de autenticación, URIs completas de bases de datos e información privada con la que podían pivotar hacia infraestructuras de terceros. Como demostración, publicaron listados de repositorios y de informes recopilados desde 2020, en los que mencionaban a grandes organizaciones financieras, operadores móviles, grandes superficies, entidades militares y organismos públicos de Estados Unidos.

El grupo también señaló que había intentado contactar con Red Hat para exigir un rescate, pero que solo obtuvieron respuestas automáticas que les remitían al procedimiento de reporte de vulnerabilidades, algo que ilustra el choque frecuente entre los flujos formales de divulgación y las tácticas de extorsión de muchos grupos criminales.

Compromiso de una utilidad de GitHub Actions y robo masivo de credenciales

En paralelo a los incidentes en plataformas de repositorios, se ha detectado un ataque directo a la cadena de CI/CD mediante la modificación maliciosa de una acción de GitHub muy popular, utilizada en miles de flujos de trabajo de desarrollo.

La herramienta afectada es tj-actions/changed-files, una acción que muchos equipos emplean para identificar qué ficheros han cambiado en un commit o en una pull request y así optimizar qué pruebas o tareas ejecutar. Esta utilidad, aparentemente inocua, estaba presente en más de 23.000 repositorios de GitHub, lo que la convertía en un punto de apoyo ideal para un atacante con ambición de escalar a gran escala.

Investigadores de StepSecurity descubrieron que todas las versiones de la acción hasta la 45.0.7 habían sido alteradas el 14 de marzo por un actor malicioso, introduciendo un script en Python con la capacidad de exfiltrar información sensible desde los entornos de ejecución de CI.

Ese script malicioso permitía a un atacante remoto obtener claves de API, tokens de acceso, contraseñas y otros secretos presentes en los flujos de trabajo, lo que abría la puerta no solo a comprometer repositorios concretos, sino a moverse lateralmente hacia otros servicios, proveedores cloud o sistemas internos ligados a esas credenciales.

GitHub asignó a la vulnerabilidad el identificador CVE-2025-30066 y, una vez descubierta, revocó el acceso a la herramienta maliciosa, sustituyéndola por una versión corregida. Sin embargo, esa reacción, aunque rápida, no elimina la incertidumbre: cualquier pipeline que haya usado la acción maliciosa podría haber dejado ya rastros de credenciales robadas o paquetes comprometidos en circulación.

Desde Endor Labs se advirtió de que cualquier repositorio público que construya paquetes o contenedores en sus flujos de CI podría haberse visto alcanzado. El objetivo del atacante no parecía limitarse a sacar credenciales de repositorios públicos, ya de por sí accesibles, sino aprovechar el acceso para inyectar malware en bibliotecas open source, binarios y artefactos generados por esos flujos, contaminando potencialmente la cadena de suministro de terceros.

Tal y como apuntaba el CTO de Enfor Labs, es perfectamente posible que ya existan paquetes infectados que todavía nadie ha identificado, con un alcance que podría variar desde unos pocos miles hasta millones de artefactos afectados, algo que solo se clarificará con el paso del tiempo y los análisis forenses correspondientes.

Abuso de comentarios en GitHub y GitLab para alojar y distribuir malware

Más allá de las intrusiones directas y de los ataques a acciones de CI/CD, se ha expuesto un problema de diseño en el sistema de comentarios de GitHub y GitLab que ha sido aprovechado por grupos de ciberdelincuentes para distribuir malware a través de URLs legítimas de estas plataformas.

La lógica de colaboración de estos servicios permite que los usuarios adjunten archivos a comentarios en issues, commits o pull requests, por ejemplo para subir capturas de pantalla, documentos o ficheros de prueba que ayuden a reproducir un fallo. Esos adjuntos se almacenan en la CDN de la plataforma y quedan referenciados por URLs con un formato predecible y asociado al repositorio y al usuario.

El detalle problemático es que, en el caso de GitHub, la URL de descarga se genera nada más subir el archivo al borrador del comentario, incluso aunque el usuario nunca llegue a pulsar en “Publicar”. Ese fichero pasa a estar disponible en la CDN a través de un enlace funcional, pero el comentario permanece en estado de borrador y ni el propietario del repositorio ni otros usuarios llegan a verlo en la interfaz.

Esto se traduce en que cualquier atacante puede subir un archivo malicioso a prácticamente cualquier repositorio público, obtener una URL que parece completamente legítima (incluyendo el nombre del proyecto y del propietario, como si fuera un archivo oficial) y usarla en campañas de phishing o distribución de malware, sin que los responsables del repositorio tengan forma directa de bloquear o eliminar ese contenido por sí mismos.

Los propietarios no ven el comentario ni el adjunto en la interfaz, no tienen un panel para gestionar esos ficheros, y solo podrían intentar mitigar el problema desactivando los comentarios del repositorio por completo durante cierto tiempo, lo que a su vez rompe el canal habitual de feedback y reporte de errores de la comunidad.

GitLab sigue un esquema parecido para sus comentarios, con URLs del tipo gitlab.com/{usuario}/{repositorio}/uploads/{id}/{nombre_fichero}, aunque en este caso el impacto se reduce algo gracias a que solo los usuarios registrados y autenticados pueden subir adjuntos, lo que introduce una fricción mínima pero relevante para los atacantes.

Campañas reales: RedLine Infostealer y repositorios de Microsoft como señuelo

Este bug de diseño no es teórico: investigadores de McAfee han detectado campañas activas que lo explotan para distribuir el malware RedLine Infostealer, orientado al robo de credenciales, cookies, datos de tarjetas y otra información sensible de los equipos infectados.

En estos ataques, los ciberdelincuentes utilizaron repositorios públicos muy conocidos, incluyendo proyectos de Microsoft como vcpkg, para subir ficheros maliciosos como parte de comentarios en issues o commits. Esos archivos no forman parte del código fuente del proyecto, pero las URLs generadas parecen perfectamente legítimas y están alojadas en la infraestructura oficial de GitHub.

De este modo, los enlaces de descarga del malware pueden tener una forma similar a https://github[.]com/microsoft/vcpkg/files/…/NombreDelArchivo.zip, lo que hace que un usuario medio, o incluso alguien con cierto conocimiento técnico pero con prisa, pueda asumir que se trata de un recurso confiable ligado al repositorio original.

El proceso es sencillo desde el punto de vista del atacante: sube el archivo a un comentario, obtiene la URL generada automáticamente y ni siquiera necesita llegar a publicar ese comentario. Aunque decida enviarlo y luego borrarlo, los ficheros permanecen en la CDN y las URLs siguen siendo válidas, de manera que la superficie de abuso es enorme.

El impacto potencial es significativo, porque prácticamente cualquier repositorio público se puede usar como “escaparate” aparente de archivos maliciosos. No solo hablamos de proyectos de Microsoft, sino de innumerables repositorios de herramientas de seguridad, proyectos de firmware y hardware, frameworks y complementos de IDE como Visual Studio Code, o librerías utilizadas en entornos empresariales.

Algunos escenarios especialmente preocupantes incluyen la suplantación de parches de seguridad o herramientas de protección, donde el atacante podría colar versiones troyanizadas de instaladores o actualizaciones disfrazadas de mejoras legítimas, o la subida de firmware adulterado a repositorios dedicados a dispositivos físicos, con el riesgo de manipular el comportamiento de equipos en producción.

A la hora de responder, las organizaciones afectadas se encuentran con que no existe una opción global en GitHub para gestionar o limpiar todos los adjuntos subidos a través de este mecanismo. Pueden, como mucho, contactar con el soporte de GitHub para solicitar la eliminación de ficheros concretos, lo cual puede funcionar para incidentes puntuales, pero no escala si los atacantes automatizan la generación masiva de URLs maliciosas.

Riesgos para la cadena de suministro de software y repositorios de código abierto

La combinación de estos problemas —intrusiones en instancias internas, acciones de CI/CD comprometidas y abuso de la infraestructura de comentarios— termina convergiendo en una misma preocupación: la vulnerabilidad de la cadena de suministro de software moderna.

Cada vez más organizaciones dependen de paquetes open source, contenedores, artefactos binarios y plantillas de infraestructura como código que se construyen y distribuyen a través de GitHub, GitLab y sus pipelines. Un pequeño eslabón débil en uno de estos puntos puede contaminar, de forma silenciosa, cientos o miles de proyectos que confían en esos artefactos.

Cuando una acción como tj-actions/changed-files se ve comprometida, no solo corren peligro los repositorios que la usan directamente, sino también todos los paquetes y contenedores generados a partir de esos flujos de CI, que pueden acabar en registros públicos, repositorios de paquetes o incluso en productos comerciales que llegan al cliente final.

Algo parecido ocurre con el abuso de los comentarios en GitHub y GitLab: las URLs que empiezan por un dominio legítimo y contienen nombres de proyectos y empresas conocidas tienen un aura de confianza muy difícil de replicar para un atacante si tuviera que alojar sus archivos en un dominio anónimo.

Además, los repositorios de código abierto son terreno fértil para tácticas como el typosquatting, donde se crean proyectos con nombres casi idénticos al original (cambiando una letra o jugando con mayúsculas y minúsculas) para atraer a usuarios despistados que buscan una librería concreta y acaban instalando un paquete malicioso.

En este contexto, las organizaciones que descuidan la seguridad de sus repositorios y pipelines corren el riesgo de convertirse, sin darse cuenta, en vectores involuntarios de distribución de malware o de exfiltración de secretos, con consecuencias que van desde daños reputacionales hasta sanciones regulatorias y pérdidas económicas importantes.

Buenas prácticas para usar GitHub y GitLab de forma segura

Para reducir la exposición a este tipo de incidentes, es clave adoptar un conjunto de buenas prácticas de seguridad en el uso cotidiano de GitHub y GitLab, tanto a nivel de cuentas individuales como de organizaciones y proyectos.

Un primer pilar es la protección de las cuentas de usuario. Es fundamental habilitar la autenticación de dos factores (2FA) y exigirla a todos los miembros de la organización, colaboradores externos y responsables de facturación, de modo que una contraseña filtrada no se traduzca automáticamente en una intrusión exitosa.

Junto a esto, conviene insistir en la creación y gestión adecuada de contraseñas fuertes, evitando su reutilización entre servicios y reforzando la protección con gestores de contraseñas. GitHub ofrece recomendaciones específicas y mecanismos como la protección de inserción (push protection) que ayudan a minimizar errores humanos.

A nivel de organización, es recomendable limitar la visibilidad y capacidad de manipulación de los repositorios: deshabilitar el cambio arbitrario de visibilidad, restringir la creación de repositorios a privados o internos por defecto, y controlar quién puede borrar o transferir repositorios, evitando acciones irreversibles por parte de usuarios con privilegios innecesarios.

También resulta útil revisar la política de forks y el alcance de los personal access tokens, asegurando que solo conceden los permisos mínimos imprescindibles y no se reutilizan indiscriminadamente en múltiples herramientas o entornos.

Por último, merece la pena verificar el dominio de correo de la organización y restringir las notificaciones a dominios comprobados, lo que dificulta la suplantación y aporta un plus de confianza de cara a colaboradores y clientes.

Secret scanning, auditoría y protección de ramas

Una vez se ha reforzado la base, es importante desplegar mecanismos automáticos de detección y respuesta frente a filtraciones de datos, especialmente en lo referente a secretos (claves, tokens, credenciales) que pudieran colarse en el histórico de Git.

GitHub ofrece funcionalidades de secret scanning que analizan el historial completo de los repositorios en busca de patrones de claves reconocidos por proveedores asociados o definidos por la propia organización. Estas alertas se muestran en la pestaña de seguridad del repositorio y permiten reaccionar rápido ante un posible compromiso.

Existen dos grandes modalidades: por un lado, las alertas para partners, activadas por defecto en repositorios y paquetes públicos, y por otro, las alertas de examen de secretos para usuarios, que amplían la cobertura a repositorios privados e internos de organizaciones con licencias específicas de seguridad.

Además, se puede habilitar secret scanning como protección de inserción, de forma que se bloquee directamente cualquier push que contenga un secreto detectado antes de que llegue al repositorio remoto, evitando así que la información sensible se incruste en el historial.

Para entornos con requisitos avanzados, es posible definir patrones personalizados de secretos, adaptados a los formatos internos de tokens, claves o identificadores utilizados por la organización, aumentando el alcance del análisis y reduciendo los puntos ciegos.

En paralelo, es recomendable aprovechar el registro de auditoría de la organización y su API GraphQL para monitorizar acciones críticas: cambios de permisos, creación o eliminación de repositorios, modificaciones de políticas de seguridad, etc., todo ello encaminado a detectar comportamientos anómalos o actividades maliciosas internas o externas.

Otro elemento clave son las reglas de protección de ramas y los conjuntos de reglas, que permiten exigir revisiones de código, aprobaciones mínimas, estado de checks en verde y otros requisitos antes de permitir que el código llegue a la rama principal o a ramas críticas.

Los conjuntos de reglas ofrecen ventajas adicionales, como un mejor seguimiento del estado y la posibilidad de aplicar múltiples políticas simultáneas sobre las mismas ramas, lo que facilita adaptar la seguridad a distintos equipos o tipos de proyecto dentro de una misma organización.

Seguridad en GitHub Actions y pipelines de CI/CD

Dado que muchos de los incidentes recientes giran en torno a los flujos de CI/CD y las acciones de GitHub, es vital tratarlos como parte integral de la superficie de ataque y no como simples ficheros de configuración secundarios.

Una práctica básica es el principio de mínimo privilegio para los tokens usados en los workflows: el GITHUB_TOKEN generado por defecto debe contar con los permisos estrictamente necesarios, y el uso de tokens de acceso personales debería limitarse a casos muy justificados y bien controlados.

Igualmente importante es anclar las acciones de terceros a un commit SHA concreto en lugar de referirse a ramas como main o tags genéricos como latest, ya que estos últimos pueden cambiar sin previo aviso y abrir la puerta a ataques de cadena de suministro si un repositorio externo es comprometido.

Los flujos de trabajo que aceptan entradas desde forks públicos o pull requests de colaboradores externos deben validar cuidadosamente esas entradas y evitar que se mezclen con pasos de despliegue o publicación de artefactos, separando en workflows diferentes las tareas sensibles de las no sensibles.

Conviene, además, revisar y auditar periódicamente los ficheros .yml de los workflows para detectar permisos excesivos, uso de acciones sin pinning, dependencias peligrosas o patrones de riesgo. Herramientas de terceros, como Xygeni, pueden complementar a GitHub Advanced Security analizando la lógica de CI/CD, no solo el código fuente.

La automatización juega un papel clave: integrar escaneos de código, análisis de dependencias, detección de secretos e infraestructuras como código directamente en las pull requests y en las pipelines ayuda a bloquear fusiones inseguras antes de que el problema llegue a producción.

Commits, fusiones y gestión segura de repositorios

Más allá de la configuración global y de los workflows, cada commit y cada fusión representan un punto de entrada potencial para vulnerabilidades o filtraciones, por lo que merece la pena afinar los hábitos cotidianos de los desarrolladores.

Antes de confirmar cambios, es recomendable revisar con calma qué archivos se están añadiendo y qué diferencias se van a subir, usando comandos como git status y git diff, para evitar que se cuele por descuido un archivo .env, claves SSH o configuraciones locales llenas de secretos.

El uso riguroso de .gitignore para excluir ficheros temporales, credenciales y configuraciones locales es una medida sencilla pero crucial, ya que reduce de raíz la probabilidad de que información confidencial llegue siquiera al área de staging.

En entornos regulados o de alta seguridad puede ser conveniente firmar los commits para garantizar la integridad de la autoría y disponer de una trazabilidad más robusta, algo que, combinado con reglas de fusión estrictas, dificulta las manipulaciones maliciosas del historial.

Los hooks de pre-commit y los controles automáticos en CI permiten bloquear commits que contengan secretos, patrones de código inseguros o configuraciones erróneas, trasladando parte de la responsabilidad a herramientas automatizadas que trabajan de forma constante sin depender del despiste humano.

A la hora de fusionar ramas, es buena idea recurrir siempre a pull requests con reglas de protección activadas, exigir aprobaciones, análisis de seguridad y comprobaciones de estado, y considerar estrategias de squash para mantener un historial limpio que no arrastre cambios indeseados.

Por último, los repositorios deben tratarse siempre como activos sensibles, aunque sean públicos. Mantenerlos privados por defecto, restringir el acceso de colaboradores al mínimo necesario y monitorizar regularmente posibles filtraciones o configuraciones débiles son pasos básicos para evitar sorpresas desagradables.

Todo este conjunto de incidentes y medidas pone de manifiesto que la seguridad en GitHub, GitLab y sus ecosistemas asociados ya no es un “extra” opcional, sino un requisito imprescindible para cualquier organización que quiera desarrollar software con garantías. Desde los grandes casos de brechas en instancias de GitLab y acciones comprometidas hasta el aparente detalle de un comentario no publicado que genera una URL útil para campañas de phishing, cada pieza cuenta. Blindar cuentas, repositorios, workflows y hábitos de desarrollo, apoyándose en funciones nativas como 2FA, secret scanning o protección de ramas y en herramientas especializadas para analizar la lógica de CI/CD, marca la diferencia entre ser víctima —o incluso canal involuntario— de un incidente de seguridad en GitHub, y poder seguir trabajando con rapidez sin dejar la puerta abierta a los atacantes.