GitHub hackeado vía extensión de VS Code: el caso TeamPCP

18 minutos. Es el tiempo que la versión 18.95.0 de Nx Console estuvo disponible en el Visual Studio Code Marketplace antes de ser eliminada — tiempo más que suficiente para que el grupo TeamPCP comprometiera a un empleado de GitHub y exfiltrara cerca de 3.800 repositorios internos de la empresa. El incidente, confirmado por GitHub el 20 de mayo de 2026, es uno de los casos más emblemáticos de ataque a la cadena de suministro de software del año.

Qué es Nx Console y por qué esto te importa

Nx Console es una extensión legítima y muy popular de VS Code, usada por desarrolladores que trabajan con el framework Nx para monorepos. Tiene cientos de miles de instalaciones activas. Es decir: no estamos hablando de una extensión oscura que alguien instaló por descuido — es una herramienta mainstream, confiable, con historial limpio.

Ese es exactamente el punto. Atacar una extensión popular significa comprometer de una sola vez un número enorme de objetivos calificados: desarrolladores con acceso a tokens de repositorio, pipelines de CI/CD e infraestructura corporativa. Quien instala Nx Console no es un usuario cualquiera — es alguien con credenciales valiosas.

Cómo funcionó el ataque, paso a paso

La cadena de compromiso, según el análisis de Bleeping Computer y Help Net Security, siguió este camino:

1. Publicación de la extensión maliciosa: el 18 de mayo, los atacantes publicaron la versión 18.95.0 en el Marketplace, sustituyendo (o haciéndose pasar por el paquete oficial). Estuvo activa entre 11 y 18 minutos.
2. Ejecución automática al iniciar VS Code: cada vez que la extensión cargaba, ejecutaba en silencio un comando npx apuntando a un commit específico en el repositorio oficial nrwl/nx en GitHub.
3. Descarga y ejecución del payload oculto: ese commit plantado instalaba y ejecutaba un paquete llamado nx-next, disfrazado como parte de una configuración de MCP (una tarea rutinaria en el ecosistema Nx). El objetivo real de nx-next: robar tokens de acceso a GitHub y otras credenciales del entorno.
4. Exfiltración: con el token capturado del dispositivo de un empleado de GitHub, los atacantes accedieron y clonaron repositorios internos de la empresa.

El vector es especialmente sofisticado porque el código malicioso no estaba directamente en la extensión: solo llamaba a código de otro lugar (el commit plantado en el repositorio legítimo de Nx). Esto dificulta la detección por parte de escáneres que analizan únicamente el paquete en sí.

Quién es TeamPCP

TeamPCP — rastreado por el Google Threat Intelligence Group como UNC6780 — es un grupo criminal especializado en ataques a la cadena de suministro contra herramientas de desarrollo e infraestructura open source. Antes de GitHub, el grupo ya había comprometido:

• El escáner de seguridad Trivy, de Aqua Security
• KICS, de Checkmarx
• La biblioteca LiteLLM
• El Telnyx SDK
• Paquetes de TanStack y de MistralAI

El patrón es consistente: los objetivos son desarrolladores y equipos de seguridad — personas con acceso privilegiado. Los 3.800 repositorios robados de GitHub se pusieron a la venta por US$ 95.000, en una operación conjunta con el grupo LAPSUS$. GitHub confirmó que la cifra es "consistente con la investigación interna".

Qué perdió GitHub — y qué se mantuvo a salvo

GitHub fue claro: los datos de clientes, los repositorios de usuarios y las cuentas enterprise no se vieron afectados. El compromiso quedó restringido al entorno corporativo interno de la empresa — código fuente de sistemas internos, herramientas e infraestructura propia.

Esto no es poca cosa. El código interno puede revelar arquitectura, flujos de autenticación, dependencias críticas y potenciales puntos débiles que un adversario persistente puede explotar meses después. No es una filtración de datos de usuarios, pero sí un vector para ataques futuros más dirigidos.

Este tipo de incidente tiene un paralelo directo con lo que ocurrió con Trellix, cuando el grupo RansomHouse robó código fuente de una empresa de seguridad — demostrando que ni quien protege a los demás está inmune.

No es el primer ataque de este tipo — y no será el último

Este patrón de comprometer la herramienta del desarrollador para llegar al objetivo final viene creciendo. En abril de este año, cubrimos aquí en el blog el ataque de cadena de suministro a JDownloader vía un paquete Python envenenado — misma lógica: comprometer una herramienta confiable para escalar el acceso.

La diferencia aquí está en la sofisticación: el código malicioso no estaba dentro del paquete publicado, sino que se descargaba dinámicamente desde una fuente aparentemente legítima (el propio repositorio de Nx en GitHub). Esto hace que la detección sea mucho más difícil para las soluciones tradicionales de análisis estático.

Qué debes hacer ahora

Si usas Nx Console en VS Code, el primer paso es inmediato:

• Actualiza a la versión 18.100.0 o superior, confirmada como libre del payload malicioso.
• Revisa el historial de tokens de GitHub asociados a tu dispositivo en Settings → Developer Settings → Personal Access Tokens y revoca cualquier token sospechoso.
• Si instalaste la extensión entre el 17 y el 19 de mayo de 2026, trata tus credenciales como comprometidas: rota tokens, revisa los registros de acceso a GitHub y audita los repositorios accedidos en ese período.
• Considera restringir qué extensiones de VS Code tienen permiso para ejecutar scripts de red al iniciar — las políticas de extensiones corporativas existen exactamente para esto.

Para equipos que gestionan varias estaciones de trabajo de desarrolladores, vale la pena revisar los registros de ejecución de VS Code y de la terminal. La auditoría de registros con PowerShell puede ayudar a identificar ejecuciones sospechosas de npx fuera del flujo normal de trabajo.

La lección más grande

Confiar en una extensión porque es popular y tiene un historial limpio es una heurística razonable — pero TeamPCP demostró que basta una ventana de 18 minutos para convertir esa confianza en un vector de ataque. La superficie de riesgo del desarrollador moderno incluye cada plugin, cada dependencia, cada gestor de paquetes invocado en la terminal.

GitHub sobrevivió al incidente sin exponer datos de usuarios. Otros no tendrán tanta suerte. Si administras un equipo de desarrollo, este es el momento de revisar la política de extensiones aprobadas — antes de que alguien en tu empresa sea el próximo empleado con un token capturado.

Si te viste afectado o quieres discutir cómo implementar controles de extensiones en tu entorno, cuéntanos en los comentarios.