18 minutos bastaron: cómo una extensión de VS Code se llevó 3.800 repos privados de GitHub

Ni un firewall roto, ni un día cero: un clic

Estamos acostumbrados a imaginar los grandes hackeos como asaltos a una fortaleza: muros derribados, exploits imposibles, semanas de asedio. La realidad de mayo de 2026 fue mucho más humilde y mucho más inquietante. A GitHub —propiedad de Microsoft, casa del código de medio planeta— le robaron los repositorios internos, y todo empezó en el portátil de uno de sus desarrolladores, que instaló la actualización de una extensión que usaba a diario.

La ventana de exposición fue de 18 minutos. Eso es todo lo que la versión troyanizada estuvo disponible. Suficiente.

Vamos a contarlo bien, porque la lección de fondo no va de GitHub: va de ti, de tu equipo y del portátil desde el que despliegas.

Qué pasó exactamente

El 18 de mayo de 2026, una actualización maliciosa de la extensión Nx Console para Visual Studio Code apareció en el Marketplace. Estuvo viva 18 minutos —de las 12:30 a las 12:48 UTC— antes de que la retirasen. En ese rato, todo el que tuviera la actualización automática activada se la tragó.

¿Qué hacía esa actualización? Era un ladrón de credenciales. En cuanto aterrizaba en el equipo de un desarrollador, rebuscaba y se llevaba todo lo jugoso que encontrara:

• bóvedas de 1Password,
• configuraciones de Claude Code (sí, hasta los tokens de las herramientas de IA),
• credenciales de npm, de GitHub y de AWS.

Uno de esos desarrolladores trabajaba en GitHub. Con sus credenciales, los atacantes accedieron a la infraestructura interna y exfiltraron unos 3.800 repositorios privados (el propio grupo presume de 4.000). El 20 de mayo GitHub lo confirmó. Y, por si quedaba duda de las intenciones, los atacantes pusieron «el código fuente y las organizaciones internas de GitHub» a la venta en un foro criminal, con un precio de salida de 50.000 dólares.

No fue suerte: fue una campaña

Aquí es donde la cosa deja de ser una anécdota y se vuelve un patrón. Detrás está un grupo conocido como TeamPCP (Google lo rastrea como UNC6780), y lo de GitHub fue solo una pieza de una campaña de cadena de suministro mucho mayor, apodada Shai-Hulud.

Entre finales de 2025 y mayo de 2026, ese mismo grupo:

• envenenó más de 170 paquetes de npm y PyPI,
• comprometió GitHub Actions de vendors de seguridad tan serios como Aqua Security y Checkmarx (Trivy),
• y secuestró una extensión de VS Code con 2,2 millones de instalaciones.

Y muchas de esas intrusiones arrancaron de algo tan tonto como un único token de acceso (PAT) mal rotado o un desarrollador comprometido. Una llave olvidada en un bolsillo abre la puerta de toda la casa.

La verdad incómoda: el eslabón débil sigue siendo el humano

Fíjate en lo que no hubo en todo esto: ningún exploit deslumbrante contra el servidor de GitHub, ninguna vulnerabilidad de día cero en su infraestructura. El atacante no rompió el muro. Engañó a quien tenía la llave.

Esa es la incomodidad que conviene asumir: en la mayoría de los grandes incidentes recientes, el humano no «hace» casi nada. Es pasivo. Es, simplemente, una credencial con patas. Instala una extensión, ejecuta un npm install, guarda un token en un fichero de configuración… y sin saberlo se convierte en la puerta de entrada. Si en tu cabeza la seguridad termina en el cortafuegos del servidor, te estás dejando fuera el dispositivo desde el que se gobierna ese servidor.

Cómo no ser tú el próximo titular

Aterricemos, que es a lo que venimos. No hace falta ser GitHub para que esto te toque: cualquiera que instale dependencias y use extensiones está en la misma diana. Lo bueno es que la defensa es de sentido común y barata.

1. Trata las extensiones como lo que son: código de terceros con permisos

• Desactiva la actualización automática de extensiones. Es el detalle que convirtió 18 minutos en un desastre global. En VS Code:

// settings.json
"extensions.autoUpdate": false

• Instala lo justo. Cada extensión es código ajeno corriendo con tus permisos. Revisa el editor y borra lo que no uses.
• Antes de instalar o actualizar, mira quién publica y desconfía de versiones recién salidas.

2. Trata las dependencias con la misma desconfianza

• Fija versiones exactas y usa el lockfile siempre. En despliegues, npm ci (no npm install): instala exactamente lo del package-lock.json, sin sorpresas.
• Desactiva los scripts de instalación, que son el vector clásico para ejecutar código al instalar un paquete:

npm config set ignore-scripts true        # global
npm ci --ignore-scripts                    # por proyecto

• Aplica un periodo de enfriamiento: no actualices a la última versión el mismo día que sale. La mayoría de paquetes envenenados se detectan y retiran en horas.

3. Trata las credenciales como si ya estuvieran filtradas

• Tokens de vida corta y permisos mínimos. Un PAT de GitHub con caducidad larga y permisos de sobra es justo lo que estos ataques buscan. Usa tokens fine-grained, con caducidad y solo los permisos imprescindibles.
• Rótalos de verdad y por completo. Medio rotar un token (dejar el viejo válido «por si acaso») fue el origen de varias de estas intrusiones.
• Nada de secretos en claro en el portátil. Las credenciales de AWS en ~/.aws, los tokens en ficheros de configuración… eso es justo lo que el ladrón vino a buscar. MFA en todo lo que lo permita.

4. El portátil del desarrollador es producción

Si desde esa máquina se despliega, se accede a repos privados o se firman releases, es un activo de producción, no «el ordenador de trabajo». Merece el mismo cuidado: actualizado, con lo mínimo instalado y con credenciales que, si se filtran, no abran el reino entero.

La recomendación, sin rodeos

El ataque a GitHub no demostró que sus muros fueran débiles. Demostró que da igual lo alto que sea el muro si dejas la llave en un portátil que ejecuta código de terceros sin pensarlo. La cadena de suministro de software —extensiones, dependencias, tokens— es hoy la superficie de ataque más rentable que existe, precisamente porque casi nadie la vigila.

Si en tu equipo se instalan dependencias y extensiones a diario, y nadie ha mirado nunca qué permisos arrastran ni cómo están de rotados los tokens, ese es exactamente el agujero del que deberíamos hablar. Revisarlo cuesta una tarde; descubrirlo en un foro de venta de código cuesta mucho más.

Referencias

• GitHub confirma la brecha de 3.800 repos vía extensión maliciosa de VS Code — BleepingComputer
• La brecha llegó vía la extensión Nx Console — The Hacker News
• TeamPCP y la venta del código por 50.000 $ — Help Net Security
• El robo de credenciales (1Password, Claude Code, AWS) — Aikido
• La campaña Shai-Hulud / UNC6780 en npm — Unit 42 (Palo Alto Networks)