GitHub hackeado: 3.800 repos via extensión VS Code

Esta mañana, 20 de mayo de 2026, GitHub publicó la frase que ningún desarrollador quería leer dicha por la propia empresa: “podemos confirmar que actores no autorizados accedieron a repositorios internos de GitHub”. La intrusión fue detectada el 19 de mayo y atribuida a TeamPCP (UNC6780) — el mismo grupo que hace apenas nueve días publicó 84 paquetes maliciosos en el namespace @tanstack y desencadenó el ataque Mini Shai-Hulud que cubrimos esta semana. El vector esta vez no fue npm: fue una extensión maliciosa de VS Code instalada por un empleado de GitHub en su equipo de trabajo.

El alcance público confirmado: aproximadamente 3.800 repositorios internos de GitHub exfiltrados, ofrecidos hoy en el foro Breached por USD 50.000. GitHub asegura que no hay evidencia de impacto en código de clientes, organizaciones Enterprise ni repos de usuarios — pero la palabra “evidencia” es ambigua cuando llevás 30 horas de investigación. Más relevante todavía: este ataque cierra una secuencia de seis meses de TeamPCP demoliendo la cadena de confianza del ecosistema dev, y abre el frente que casi nadie tenía en el radar — las extensiones de IDE.

La cronología de las últimas 30 horas

Lo que se sabe verificable según los reportes públicos de BleepingComputer, Help Net Security, The Hacker News y The Register:

1. Fecha sin confirmar: un empleado de GitHub instala una extensión de VS Code en su equipo de trabajo. La extensión está publicada en el VS Code Marketplace de Microsoft con apariencia legítima.
2. Período no público: la extensión recolecta silenciosamente credenciales desde el momento en que el empleado abre cualquier workspace — tokens de GitHub, sesiones activas, secrets locales, llaves SSH. TeamPCP usa esas credenciales para acceder a repos internos.
3. 19 de mayo (madrugada PST): el equipo de seguridad de GitHub detecta actividad anómala y comienza la respuesta a incidentes.
4. 19 de mayo (a lo largo del día): aislamiento del dispositivo afectado, revocación de credenciales del empleado, remoción de la extensión maliciosa del VS Code Marketplace, y rotación overnight de credenciales críticas internas priorizadas por impacto.
5. 20 de mayo (mañana): GitHub publica la confirmación oficial del incidente y reconoce que las afirmaciones de TeamPCP sobre 3.800 repos son “directionalmente consistentes” con su investigación.

Detalle que pasó desapercibido en la cobertura: un día antes del breach, el 18 de mayo, la extensión Nx Console — con 2.2 millones de instalaciones — estuvo comprometida durante 18 minutos en el Marketplace antes de ser detectada. Microsoft removió la versión maliciosa rápido, pero todo dev que instaló o actualizó en esa ventana de 18 minutos quedó potencialmente expuesto. No hay confirmación pública de que ambos incidentes estén conectados, pero el timing es sugestivo.

Por qué TeamPCP atacó vía extensión y no vía paquete npm

Para entender el cambio de vector hay que ver cómo opera TeamPCP. Sus ataques previos (Trivy, KICS, LiteLLM, TanStack, Mistral AI, UiPath) usaron paquetes en registries públicos — npm y PyPI principalmente. Esa táctica tiene un techo: los paquetes maliciosos son escaneados, los IOC se comparten entre proveedores de seguridad, y la ventana de oportunidad antes de la detección es cada vez más corta.

Las extensiones de VS Code son la respuesta táctica al cierre de esa puerta. Tres ventajas para el atacante:

• Escaneo inferior. El VS Code Marketplace tiene un proceso de revisión menos riguroso que npm para detectar comportamiento malicioso de bajo nivel. No hay equivalente a npm audit para extensiones.
• Privilegios silenciosos. Una extensión de VS Code corre con el contexto completo del usuario: lee filesystem, accede a tokens en el keychain del sistema operativo, intercepta clipboard, observa lo que escribís. Nadie te avisa cuando una extensión hace fetch a un dominio externo.
• Target dirigido. A diferencia de un paquete npm que infecta a quien lo instale, una extensión maliciosa publicada con un nombre específico puede dirigirse a perfiles concretos — por ejemplo, devs de empresas que el atacante quiere comprometer. Si TeamPCP supo que un empleado de GitHub estaba buscando una extensión específica, pudieron envenenarla o publicar una versión rival.

Los reportes públicos no confirman si la extensión fue una publicación nueva (TeamPCP creó una desde cero) o un takeover (compraron o robaron una extensión legítima existente). Ambos modelos son operacionalmente accesibles para un grupo de la sofisticación de UNC6780.

Qué hacía exactamente la extensión maliciosa

GitHub no publicó el nombre de la extensión “para evitar publicidad inadvertida al atacante” — frase que técnicamente protege a futuros targets pero también dificulta que otros equipos validen si tienen la misma extensión instalada. Microsoft tampoco lo nombró públicamente. Esa decisión es controvertida en la comunidad de seguridad.

Lo que sí se confirmó del comportamiento:

• Inicio en silencio al abrir cualquier workspace. No requería interacción específica del usuario — alcanzaba con abrir un proyecto en VS Code para que la extensión empezara a recolectar.
• Targets de credenciales según SecurityWeek y los reportes de Wiz: tokens almacenados en ~/.config/git, ~/.npmrc, ~/.aws/credentials, ~/.kube/config, llaves SSH en ~/.ssh/, sesiones activas de GitHub Desktop, y cualquier archivo .env accesible desde el workspace abierto.
• Exfiltración por canal cifrado hacia infraestructura intermediaria. No vía conexión directa a TeamPCP — los grupos modernos usan dominios efímeros y CDNs comprometidos para hacer el traffic indistinguible del legítimo.
• Persistencia limitada: la extensión no instalaba malware adicional en el equipo. Su único trabajo era recolectar y enviar; no necesitaba más para cumplir el objetivo.

Esta arquitectura — “stealer simple, recolección continua, exfiltración encriptada” — es la firma técnica de TeamPCP que Unit 42 de Palo Alto Networks ya había documentado en marzo. Eficaz precisamente porque no hace nada “ruidoso” que dispare antivirus tradicional.

Lo que GitHub dijo, lo que no dijo, y lo que importa

El comunicado oficial de GitHub fue cuidadosamente redactado. Vale la pena leer entre líneas.

Lo que GitHub dijo explícitamente:

• 3.800 repos internos fueron exfiltrados.
• El alcance es “consistente direccionalmente” con la afirmación de TeamPCP.
• No hay evidencia de impacto en datos de clientes externos.
• Las credenciales críticas internas fueron rotadas overnight.
• La extensión fue removida del Marketplace.

Lo que GitHub no dijo:

• El nombre de la extensión maliciosa.
• Cuánto tiempo estuvo el empleado comprometido antes de la detección.
• Qué tipo de información contenían los 3.800 repos exfiltrados — ¿código de features no lanzadas?, ¿infraestructura interna?, ¿procesos de seguridad?, ¿secretos hardcoded?
• Si el empleado tenía acceso a infraestructura de producción de GitHub.com.
• Si entre los repos exfiltrados había alguno que documentara las APIs internas que orquestan GitHub Actions, Copilot o Codespaces.

La última es la que más preocupa a investigadores independientes. Si TeamPCP tiene ahora documentación interna sobre cómo opera la pipeline de Actions — la misma que usaron para envenenar TanStack vía cache poisoning hace nueve días — pueden encontrar la próxima vulnerabilidad sistémica con mucha más facilidad. No es paranoia: es la lógica natural de un atacante que acumula inteligencia.

Por qué importa para vos aunque no seas cliente Enterprise: GitHub Actions, Copilot, Codespaces y las APIs públicas de GitHub corren sobre infraestructura que ahora tiene parte de su código fuente en manos hostiles. La asimetría informacional entre el atacante y los equipos defensivos cambió a favor del atacante.

TeamPCP: el patrón completo del 2026

Para entender por qué este ataque no es aislado, conviene ver la secuencia completa de TeamPCP en lo que va del año:

La escala acumulada según Unit 42 y Oligo Security: 500.000 máquinas comprometidas y más de 300 GB de datos exfiltrados en seis meses, incluyendo cloud tokens, Kubernetes secrets y credenciales de SaaS.

El patrón es claro: TeamPCP no busca un ataque grande aislado. Construye redes de acceso comprometiendo herramientas de seguridad (Trivy, KICS), librerías de uso masivo (LiteLLM, TanStack), plataformas SDK (Mistral, Telnyx, UiPath), y ahora plataformas de desarrollo (GitHub). Cada compromiso facilita el siguiente. La lección estratégica: estamos ante una campaña sostenida, no una serie de incidentes. Las defensas también tienen que ser sostenidas, no parches puntuales.

Cómo auditar tus extensiones de VS Code hoy mismo

Cinco acciones que cualquier dev — vos, tu equipo, tus clientes — debería ejecutar antes del fin de semana. Tiempo total: 30-45 minutos.

1. Listá todas tus extensiones instaladas

code --list-extensions

Eso devuelve la lista con sus IDs publisher.extension. Para cada una, preguntate: ¿la instalé yo intencionalmente?, ¿la reconozco?, ¿tiene un publisher conocido (Microsoft, GitHub, GitLab, JetBrains, Anthropic, Vercel, Tailwind Labs, etc.)? Cualquier extensión que no pase esos tres filtros es candidata a desinstalación.

2. Identificá extensiones con publishers sospechosos

Las señales de alerta para una extensión específica:

• Publisher con menos de 6 meses de antigüedad.
• Menos de 50.000 descargas pero muchas reviews recientes.
• Cambio reciente de mantenedor (visible en el changelog si lo hay).
• Permisos amplios pero descripción vaga (“AI Helper”, “Code Tools”, “Better Search”).
• Versión última publicada hace menos de 72 horas con descripción genérica.

Para auditar más a fondo, abrí la página de la extensión en el VS Code Marketplace y revisá quién es el publisher, qué otras extensiones publica, y el historial de versiones.

3. Deshabilitá las extensiones no críticas y reduce permisos

Cualquier extensión instalada que no usás activamente debería desinstalarse. Para las que usás:

code --disable-extension <id-de-la-extension>

Trabajá durante 2 semanas con la extensión deshabilitada. Si no la extrañás, removela definitivamente. La superficie de ataque crece con cada extensión activa, aunque sean confiables — un compromiso de cualquiera te impacta.

4. Rotá tus credenciales locales si tenés sospechas

Si auditando descubrís una extensión sospechosa que tuviste instalada en los últimos 30 días, asumí compromiso y rotá todo lo que estaba accesible desde tu workspace habitual:

• Tokens personales de GitHub (https://github.com/settings/tokens).
• Llaves SSH del directorio ~/.ssh/ — generá pares nuevos y reemplazá en cada servicio.
• API keys de servicios cloud (AWS, Vercel, Cloudflare, Stripe).
• Variables de entorno en tu archivo .env local — si alguna está en uso en producción, considerala filtrada.

5. Configurá un perfil aislado para “extensiones de prueba”

VS Code permite usar perfiles separados (File > Profiles). Creá uno llamado “Trusted” con solo las extensiones que confirmaste seguras, y otro “Experiments” para todo lo nuevo. Las extensiones experimentales nunca tocan tus repos reales — abrilas en proyectos dummy hasta que las hayás validado durante semanas.

Para empresas, considerá usar el VS Code Extension Allowlist policy que permite definir centralmente qué extensiones están autorizadas. Para una PYME ecuatoriana con 5-15 devs es overkill, pero a partir de 30 personas en producción ayuda.

¿Qué cambia para usuarios de GitHub.com y GitHub Enterprise?

Tres cosas que los equipos de producto deberían responder esta semana, aunque GitHub diga que no hay impacto en clientes:

Si usás GitHub Actions con workflows complejos: revisá los logs de las últimas 30 días buscando ejecuciones inusuales. Si TeamPCP tiene visibilidad sobre la arquitectura interna de Actions, pueden estar probando vectores nuevos. Las señales de alerta: workflows que se completan en tiempos anómalos, runners que aparecen en regiones inesperadas, o steps que descargaron versiones de acciones que nunca pediste.

Si tu organización tiene secretos en GitHub: aunque GitHub afirma que la base de secretos no fue accedida, la práctica defensiva razonable es rotar todos los secrets que protegen acceso a producción durante los próximos 30 días. No “ahora mismo, por las dudas” — un plan ordenado de rotación que termine antes del 20 de junio. Si TeamPCP tiene los repos internos de GitHub, en algún momento van a estudiarlos en busca de vectores. Mejor que cuando lo intenten tus secrets ya hayan cambiado.

Si tu compliance lo exige (LOPDP, GDPR, HIPAA, SOC 2): este incidente es notificable según varias jurisdicciones. Documentá interna y formalmente que tu organización conoce el incidente, evaluó el impacto, y tomó medidas. La LOPDP ecuatoriana en particular requiere documentación de evaluación de incidentes que afectan a tu cadena de proveedores aunque no haya pérdida directa de datos personales. Tu equipo legal probablemente va a pedir esto en los próximos días — adelantate.

Tabla resumen