GitHub confirmó que cerca de 3.800 de sus repositorios internos fueron comprometidos luego de que un empleado instalara una extensión maliciosa de VS Code en su equipo de trabajo. La compañía detectó y contuvo el incidente el 19 de mayo de 2026, retiró la versión maliciosa de la extensión del marketplace y aisló el dispositivo afectado.
Cómo fue el ataque
El vector de entrada no fue una vulnerabilidad en la infraestructura de GitHub, sino una sola estación de trabajo. Un empleado instaló una extensión troyanizada desde el marketplace de Visual Studio Code y, con esos permisos, el atacante logró exfiltrar repositorios internos de la empresa.
GitHub no hizo público el nombre de la extensión. El mecanismo, sin embargo, es conocido: una extensión de VS Code corre con los mismos permisos que el editor, así que puede leer el código abierto en el workspace, los archivos de configuración, las variables de entorno y las credenciales (.env), y ejecutar procesos en la máquina. En ataques recientes del mismo tipo —como el del paquete Nx Console, con 2,2 millones de instalaciones— bastaron unos pocos kilobytes de JavaScript inyectados en un archivo minificado para recolectar credenciales de forma automática apenas el desarrollador abría un proyecto, en una actividad casi indistinguible del uso normal.
Qué se llevaron y a quién afecta
Según la evaluación de GitHub, la actividad se limitó a la exfiltración de repositorios internos de la compañía. La cifra de unos 3.800 repos es, en palabras de la empresa, «direccionalmente consistente» con su investigación. GitHub afirma que, hasta el momento, no tiene evidencia de que se haya visto afectada información de clientes almacenada fuera de esos repositorios.
Para dimensionar la plataforma: GitHub aloja unos 420 millones de repositorios de más de 180 millones de desarrolladores, y lo usa el 90% de las empresas del Fortune 100.
Quién lo reivindicó
El grupo TeamPCP se atribuyó el ataque en el foro de cibercrimen Breached, donde aseguró tener cerca de 4.000 repositorios de código privado y pidió un mínimo de 50.000 dólares por los datos, con la amenaza de filtrarlos gratis si no aparecía un comprador.
No es un actor nuevo: TeamPCP ya fue vinculado a ataques de cadena de suministro (supply chain) contra GitHub, PyPI, NPM y Docker, y a la campaña «Mini Shai-Hulud», un gusano (worm) del ecosistema npm que se propagaba a través de secretos de CI/CD.
La respuesta de GitHub
Según comunicó la empresa —principalmente a través de su cuenta en X—, las acciones tras la detección fueron inmediatas: removió la versión maliciosa de la extensión, aisló el endpoint comprometido e inició el proceso de incident response. Durante la noche rotó los secretos críticos, priorizando primero las credenciales de mayor impacto, y continúa analizando logs, validando la rotación de secretos y monitoreando posible actividad posterior. GitHub anticipó un informe más completo «una vez que la investigación esté finalizada».
No es la primera extensión maliciosa
El caso se suma a una seguidilla de extensiones maliciosas en el marketplace de VS Code. En los últimos meses se removieron varias con millones de instalaciones: una con 9 millones, otra con 1,5 millones que enviaba datos de desarrolladores a servidores en China (enero), además del ya citado Nx Console y los habituales cryptominers y robadores de credenciales. El patrón es claro: el toolchain del desarrollador —el editor y sus extensiones— se consolidó como una superficie de ataque de primer orden.
Qué recomiendan los especialistas
Las recomendaciones que circulan entre los equipos de seguridad apuntan a tratar las extensiones como lo que realmente son: código de terceros corriendo en tu máquina.
- Revisar y desinstalar las extensiones que no se usan, para reducir la superficie de ataque.
- Verificar el publisher antes de instalar (estado verificado, cantidad de instalaciones, antigüedad) y no asumir que «oficial» o «verificado» equivale a seguro.
- Aplicar bloqueo por antigüedad mínima (por ejemplo, 48 horas) a las actualizaciones de paquetes y extensiones, para no recibir de forma automática una versión recién comprometida.
- En entornos corporativos, definir allowlists de extensiones y usar devcontainers que aíslen el toolchain.
- Monitorear los endpoints con foco en npm, PyPI y el marketplace de VS Code, y rotar tokens y credenciales ante cualquier sospecha.
¿Estamos mirando el lugar equivocado?
Durante años, la seguridad del desarrollo se pensó del lado del repositorio, el pipeline y el servidor. Este caso mueve la primera línea un paso atrás: la máquina del desarrollador y las herramientas que elige instalar. Si una sola estación de trabajo alcanzó para comprometer 3.800 repositorios internos de la empresa que, justamente, aloja el código del mundo, quedan algunas preguntas sobre la mesa: ¿tu equipo tiene una política sobre qué extensiones se pueden instalar?, ¿revisás los permisos antes de darle install a una extensión?, ¿qué tan preparada está tu organización para un ataque que entra por el IDE? Te leemos en los comentarios.
Fuentes
GitHub comunicó el incidente a través de sus canales oficiales (su cuenta en X) y anticipó un informe detallado al cierre de la investigación. Cobertura del caso: BleepingComputer, The Register y Help Net Security.
