La compañía identificó el vector de ataque: un dispositivo de empleado comprometido. Es el segundo incidente de seguridad que enfrenta en lo que va del año.
GitHub confirmó este miércoles los detalles del acceso no autorizado a sus repositorios internos que había detectado un día antes. Según la empresa, el ataque se originó en el dispositivo de un empleado comprometido mediante una extensión envenenada de Visual Studio Code.
«Ayer detectamos y contenimos una violación en un dispositivo de un empleado que involucraba una extensión envenenada de VS Code. Eliminamos la versión maliciosa de la extensión, aislamos el punto final y comenzamos la respuesta al incidente de inmediato. Nuestra evaluación actual es que la actividad involucró únicamente la exfiltración de repositorios internos de GitHub. Las afirmaciones actuales del atacante sobre ~3.800 repositorios son direccionalmente consistentes con nuestra investigación hasta el momento. Nos movimos rápidamente para reducir el riesgo. Los secretos críticos fueron rotados ayer y durante la noche, priorizando primero las credenciales de mayor impacto», señaló la compañía en un comunicado publicado en su cuenta oficial de X. GitHub indicó que eliminó la versión maliciosa de la extensión, aisló el dispositivo afectado e inició de inmediato su protocolo de respuesta a incidentes.
Alcance del ataque
La empresa confirmó que la actividad se limitó a la exfiltración de repositorios internos propios, descartando por ahora impacto en repositorios de clientes. Respecto a las afirmaciones del atacante sobre el robo de aproximadamente 3,800 repositorios, GitHub señaló que esa cifra es «direccionalmente consistente» con su investigación hasta el momento.
Como medida de contención, la compañía rotó secretos y credenciales críticas durante la noche del martes, priorizando las de mayor impacto potencial. GitHub indicó que continúa analizando registros, validando la rotación de secretos y monitoreando actividad posterior al incidente.
Un patrón que se repite
Lo que hace este anuncio especialmente llamativo es que no es el primero en lo que va del año. El 14 de marzo, GitHub envió un aviso a usuarios afectados revelando un bug separado, detectado en enero, que había expuesto secretos de webhooks entre septiembre de 2025 y enero de 2026.
En aquel incidente, una falla en la nueva versión de la plataforma de entrega de webhooks hacía que el secreto de cada webhook fuera incluido inadvertidamente en una cabecera HTTP llamada X-Github-Encoded-Secret, accesible para cualquier sistema receptor en formato base64. El bug estuvo activo entre el 11 de septiembre de 2025 y el 10 de diciembre de 2025, y brevemente el 5 de enero de 2026, antes de ser corregido definitivamente el 26 de enero.
Los secretos de webhook son tokens que permiten verificar que los payloads recibidos provienen auténticamente de GitHub. Si un tercero los hubiera capturado, por ejemplo, en logs del sistema receptor, podría haber forjado entregas falsas haciéndolas pasar por legítimas. GitHub aclaró en esa ocasión que no encontró evidencia de interceptación y que el propio sistema de GitHub no fue vulnerado.
Contexto más amplio
El escenario se suma a una serie de incidentes de seguridad que han rodeado a GitHub en los últimos meses. En marzo, investigadores de Wiz divulgaron una vulnerabilidad crítica de ejecución remota de código (CVE-2026-3854, con una puntuación CVSS de 8.7, que permitía a cualquier usuario autenticado ejecutar código arbitrario en la infraestructura de GitHub con un solo comando git push), lo que en el caso de GitHub.com habría dado acceso a repositorios públicos y privados de millones de usuarios de otras organizaciones. GitHub parcheó GitHub.com en dos horas y liberó correcciones para GitHub Enterprise Server el 10 de marzo, confirmando que la vulnerabilidad no fue explotada antes de los parches.
El nuevo incidente está bajo investigación activa. GitHub no ha revelado el vector de ataque ni el alcance del acceso a sus repositorios internos.
