GitHub bestätigt Breach von 3.800 Repos durch vergiftete VSCode-Extension
ki-pentesting

GitHub bestätigt Breach von 3.800 Repos durch vergiftete VSCode-Extension

ki-pentesting8 unabhängige QuellenFlowKI Newsroom

GitHub hat einen Sicherheitsverstoß bestätigt, der sein internes Code-Repository kompromittiert hat. Wie Bleeping Computer meldet, erhielten Hacker der Gruppe TeamPCP Zugriff auf etwa 3.800 interne Repositories über eine böswillig präparierte Visual Studio Code-Extension. Ein GitHub-Mitarbeiter installierte die vergiftete Extension, wodurch Attackern der Zugang zu Entwicklungs-Umgebungen und damit zu sensiblem Quellcode ermöglicht wurde.

TeamPCP hatte die Sicherheitsverletzung zunächst öffentlich gemacht und bot die gestohlenen Daten in einem Cybercrime-Forum zum Verkauf an. Laut Help Net Security startete GitHub unverzüglich eine Untersuchung und konnte den Kompromiss inzwischen dokumentieren. Die Sicherheitsverletzung ist typisch für moderne Supply-Chain-Attacken: Statt direkter Zugriff auf zentrale Systeme nutzen Angreifer vertrauenswürdige Entwickler-Tools als Einstiegspunkt.

Für DACH-Unternehmen mit eigenen Entwickler-Teams hat dieser Vorfall unmittelbare Konsequenzen. Die Episode zeigt, dass VSCode-Extensions — trotz ihres Verbreitungsgrads — ein erhebliches Sicherheitsrisiko darstellen, wenn keine Policies für die Extension-Installation existieren. Mittelständische Softwarefirmen müssen ihre KI-Pentesting und Red-Team-Prozesse nun auch auf Entwickler-Workstations ausweiten, nicht nur auf Cloud-Infrastruktur. Zugleich ist dies ein Lehrbuch-Beispiel für unzureichende Awareness: Ein installiertes Entwickler-Tool war ausreichend, um 3.800 Repositories zu kompromittieren — ohne technische Segmentierung oder MFA hätte das nicht geschehen dürfen.

Unternehmen sollten sofort ihre VSCode-Extension-Policies überprüfen. Konkrete Schritte: Zentrale Kontrolle durch Extension-Whitelisting, regelmäßige Audits der installierten Extensions in Teams, und Integration solcher "low-sophistication, high-impact"-Szenarien in Safety-Pipelines für interne Tools und Apps. TeamPCP nutzte hier eine klassische Human-Element-Schwachstelle — die Sicherheitsarchitektur selbst war nicht das Problem, sondern die fehlende Enforcement-Schicht.

Quellen