GitHub (repositorios internos) · extensión para Visual Studio Code · Exfiltración de ~3.800 repositorios internos

Durante años nos hemos preocupado por blindar el servidor, el firewall o el repositorio, pero el eslabón que falló esta vez fue mucho más mundano: el ordenador de un programador. GitHub —la mayor plataforma del mundo para alojar y colaborar en código fuente, propiedad de Microsoft— ha confirmado que un empleado instaló una extensión maliciosa en su editor Visual Studio Code y que, desde ese equipo, se filtraron unos 3.800 de sus repositorios internos. La compañía sostiene que la fuga se limita a su propio código y que no hay indicios de que afecte a datos de clientes.

Descripción

Qué ha pasado. Entre el 19 y el 20 de mayo de 2026, GitHub reconoció públicamente una intrusión. El origen fue el equipo de un empleado, comprometido tras instalar una extensión maliciosa de Visual Studio Code (abreviado «VS Code»; un editor de código muy usado por programadores, al que se le añaden «extensiones» o complementos para ampliar funciones). Desde ese dispositivo se produjo la exfiltración (la salida no autorizada de datos) de aproximadamente 3.800 repositorios internos —los «repositorios» son los almacenes donde se guarda el código fuente y su historial de cambios—.

A quién y a qué afecta

• Afectado directo: GitHub, en sus repositorios internos (código, documentación, scripts de despliegue y, en el peor de los casos, credenciales incrustadas por error).
• Datos de clientes: GitHub afirma que, según su valoración provisional, no hay evidencia de que se hayan visto afectados datos de clientes almacenados fuera de ese conjunto de repositorios, si bien matiza que la conclusión podría variar a medida que avance la investigación.
• Versiones / producto: no se trata de un fallo en un producto con «versiones afectadas». El elemento concreto señalado por la prensa como vector es una versión troyanizada de una extensión de VS Code; varios medios la identifican como Nx Console (paquete nrwl.angular-console, versión 18.95.0, publicada el 18 de mayo de 2026). Conviene subrayar que GitHub no confirmó oficialmente el nombre de la extensión en sus primeras comunicaciones, lo que varios investigadores criticaron; la identificación de Nx Console procede de investigadores y medios, no de un comunicado de GitHub.

No hay CVE asignado ni puntuación CVSS oficial, porque no es una vulnerabilidad de un software concreto sino un incidente por código malicioso (en términos de debilidad genérica, CWE-506, «código malicioso incrustado»).

Mecánica

Cómo funciona el ataque

La idea clave es que una extensión del editor tiene prácticamente el mismo poder que el usuario que la instala: puede leer ficheros, variables de entorno, claves de acceso (tokens), credenciales en la nube o claves SSH guardadas en la máquina. Por eso un complemento manipulado es tan peligroso como un programa malicioso cualquiera.

1. Infección inicial: el empleado instala desde el marketplace (la tienda oficial de extensiones) una versión manipulada. El complemento roba credenciales y tokens del entorno local de desarrollo.
2. Robo de código: con esas credenciales, los atacantes acceden a los repositorios internos y los clonan/descargan masivamente.

Los análisis técnicos de esta oleada —atribuida por varias firmas al grupo TeamPCP (también rastreado como UNC6780)— describen un gusano de cadena de suministro apodado «Mini Shai-Hulud» (un «gusano» es un programa que se auto-propaga; la «cadena de suministro de software» es el conjunto de dependencias, paquetes y herramientas de las que depende un proyecto). Entre las técnicas descritas en esta campaña, no todas confirmadas por GitHub para este caso concreto, figuran:

• Persistencia y reinfección mediante cambios en ficheros de configuración del propio entorno: inyecciones en .vscode/tasks.json con disparadores como folderOpen, o alteraciones en el directorio .claude (p. ej. .claude/settings.json con disparador SessionStart). El riesgo práctico: basta con volver a clonar y abrir un repositorio contaminado para que se reactive la carga maliciosa.
• Abuso de scripts de instalación en npm (el gestor de paquetes de JavaScript), como preinstall o postinstall, y descarga del runtime Bun como arranque del código dañino.
• Indicador de infección propuesto para búsquedas (hunting) en historiales de commits: la cadena IfYouRevokeThisTokenItWillWipeTheComputerOfTheOwner.
• Ataques a GitHub Actions (el sistema de automatización de GitHub), con «envenenamiento» de versiones mediante force push para apuntar etiquetas a commits maliciosos y robar secretos en los runners.

Importante: la exfiltración de ~3.800 repositorios está confirmada por GitHub; la mayoría de las técnicas anteriores proceden de análisis de la campaña más amplia y no han sido detalladas por GitHub como parte de su incidente.

Respuesta del creador

Respuesta de GitHub

GitHub comunicó el incidente a través de sus canales (una publicación en X y declaraciones a varios medios). Sus afirmaciones, citadas por la prensa, incluyen:

«Nuestra valoración actual es que la actividad implicó la exfiltración de repositorios internos de GitHub únicamente».

«Las afirmaciones actuales del atacante de ~3.800 repositorios son coherentes, en líneas generales, con nuestra investigación hasta el momento».

«Retiramos la versión maliciosa de la extensión, aislamos el endpoint [el equipo comprometido] e iniciamos la respuesta al incidente de inmediato».

GitHub añadió que rotó credenciales críticas el mismo día y durante la noche, priorizando los secretos de mayor impacto, y que continúa analizando registros, validando la rotación de secretos y vigilando actividad posterior. Anunció que publicará un informe más completo cuando concluya la investigación.

Atribución y demandas del atacante (no confirmadas)

El grupo TeamPCP reivindicó el acceso en un foro delictivo y afirmó poseer «~4.000 repositorios de código privado». Ofreció los datos por un mínimo de 50.000 dólares, con amenaza de filtrarlos gratis si no aparecía comprador. Conviene tratar esto con cautela: la atribución a TeamPCP es periodística y de firmas de seguridad, no un pronunciamiento de GitHub, que inicialmente no atribuyó públicamente el ataque; el precio, las cifras del atacante y la supuesta venta no se han verificado de forma independiente.

Autoridades

A fecha de redacción de este aviso no consta inclusión en el catálogo CISA KEV (de vulnerabilidades explotadas) —lógico, al no existir CVE— ni un aviso específico de INCIBE-CERT sobre este incidente. El carácter de «explotación activa» aquí se refiere a que la intrusión y la fuga ocurrieron realmente y así lo confirma la propia GitHub, no a la explotación de una vulnerabilidad catalogada.

Parches y mitigaciones

Qué hacer ya

No hay un «parche» en el sentido clásico (no es un fallo de producto), sino acciones de contención y endurecimiento. GitHub ya retiró la versión maliciosa, aisló el equipo y rotó credenciales. Para cualquier organización que desarrolle software, las recomendaciones consolidadas de GitHub y de las firmas de seguridad son:

• Tratar las extensiones del editor como software privilegiado: restringir su instalación mediante políticas corporativas, listas de permitidos (allowlists) y bloqueo de orígenes no autorizados; mantener un inventario auditado de las extensiones instaladas. Aplicar control a nivel de equipo con MDM o políticas gestionadas, sin fiarse de los ficheros de «recomendaciones» del repositorio.
• Rotar secretos: asumir que cualquier repositorio interno puede contener credenciales expuestas por error. Rotar tokens de acceso personal (PAT), credenciales de CI/CD, secretos de GitHub Actions y tokens de GitHub Apps.
• Revisar registros y telemetría tras la rotación: buscar accesos anómalos, clonados masivos y operaciones fuera de patrón.
• Aplicar mínimo privilegio a cuentas de desarrollador y permisos sobre repositorios, para reducir el «radio de explosión» desde un único equipo comprometido.

Medidas preventivas adicionales

• Imponer un periodo de enfriamiento (p. ej. 24-72 h) antes de permitir instalar o actualizar nuevas versiones de extensiones y dependencias en equipos y en CI.
• Endurecer la cadena de dependencias en npm: lockfiles, npm ci y, cuando sea viable, desactivar los scripts de ciclo de vida con ignore-scripts en CI.
• Enrutar las descargas a través de un proxy o registro privado con control de salida (egress) y limitar el acceso directo a registros públicos.
• Añadir detecciones en EDR/SIEM para ejecuciones de bun tras npm install o lanzadas por VS Code, y vigilar la creación inesperada de repositorios públicos o commits con patrones anómalos, posibles canales de exfiltración encubierta.

Sobre versiones «corregidas»: algún medio menciona una versión limpia de Nx Console (18.100.0, siendo la previa sin alterar la 18.94.0) y un aviso de seguridad GHSA-c9j4-9m59-847w. Dado que la identidad exacta de la extensión no fue confirmada oficialmente por GitHub y que algún dato es de fuente única, conviene verificar estos extremos directamente en el proyecto antes de actuar sobre ellos. En cualquier caso, actualizar la extensión no deshace el robo de credenciales ya producido: la rotación de secretos sigue siendo imprescindible.

Fuentes

• GitHub confirms breach of 3,800 repos via malicious VSCode extension — BleepingComputer
• GitHub confirms being hacked by TeamPCP, says customer data unaffected — The Record (Recorded Future News)
• TeamPCP breached GitHub's internal codebase via poisoned VS Code extension — Help Net Security
• GitHub Confirms Breach of Internal Repositories Via Malicious VS Code Extension — Infosecurity Magazine
• GitHub internal repositories breached — Sophos
• GitHub breach via a malicious VS Code extension — Aikido Security
• GitHub confirma la exfiltración de 3.800 repositorios internos — Hispasec, Una al Día