Die technische Ursache liegt darin, wie GitHub von Nutzern hochgeladenen Code intern verarbeitet. Wie Alexis Wales von GitHub in der Offenlegung erläutert, durchläuft solcher Code mehrere interne Dienste. Metadaten wie der Repository-Typ und die vorgesehene Umgebung werden dabei über ein internes Protokoll zwischen den Diensten weitergereicht.
Angreifbar war die Behandlung von sogenannten Push-Optionen — einer regulären Funktion von git, mit der Clients beim Push Schlüssel-Wert-Paare an den Server senden können. Laut Wales flossen die vom Nutzer gelieferten Werte ohne ausreichende Bereinigung in die internen Metadaten ein. Da das interne Metadatenformat ein Trennzeichen verwendete, das auch in Nutzereingaben vorkommen konnte, ließen sich zusätzliche Felder einschleusen, die ein nachgelagerter Dienst als vertrauenswürdige interne Werte interpretierte. Wiz zeigte, dass ein Angreifer mehrere solcher Werte verketten konnte, um Schutzmechanismen und interne Beschränkungen zu umgehen und Code auszuführen.
GitHub und Wiz raten Kunden von GitHub Enterprise Server, auf eine korrigierte Version zu aktualisieren (3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 sowie 3.19.3). Anders als bei den übrigen betroffenen Produkten erfordert das Patchen beim Enterprise Server einen authentifizierten Nutzer mit Push-Zugriff. GitHub Enterprise Cloud in allen Varianten sowie github.com wurden bereits gepatcht, ohne dass Anwender eingreifen müssen. Der Sicherheitsforscher Sagi Tzadik von Wiz rief betroffene Nutzer zum Update auf und merkte an, dass zum Zeitpunkt der Veröffentlichung noch 88 Prozent der Instanzen verwundbar waren.
Der eigentliche Schwerpunkt liegt jedoch auf der Methodik. Wiz hatte GitHub Enterprise Server bereits zuvor auf Schwachstellen untersucht, doch das Extrahieren und Prüfen der großen Menge kompilierter Blackbox-Binärdateien dieser Pipeline erforderte bislang einen unpraktikablen Zeit- und Arbeitsaufwand. Den Durchbruch brachte laut Wiz das KI-gestützte Werkzeug IDA MCP, mit dem sich GitHubs kompilierte Binärdateien schnell analysieren, interne Protokolle rekonstruieren und Stellen identifizieren ließen, an denen Nutzereingaben das Serververhalten beeinflussen können.
Gegenüber Dark Reading erklärte Tzadik, Wiz habe dieses Ziel seit September 2024 verfolgt, ohne den nötigen Aufwand für die Reverse-Engineering-Arbeit rechtfertigen zu können. Manuell hätte dies vermutlich Wochen oder Monate gedauert; mit Unterstützung durch KI-Werkzeuge habe es weniger als 48 Stunden von der Idee bis zu einem funktionierenden Exploit gebraucht.
Bedeutsam sei auch der geschlossene Quellcode, so der Forscher: Closed-Source-Software sei historisch der Ort mit den größten Sicherheitsrisiken und der größten Undurchsichtigkeit gewesen. Mit den jüngsten KI-Modellen sei es einfacher, schneller und günstiger geworden, kompilierte Binärdateien zu analysieren oder aus einer CVE-Kennung und einem git-Commit-Hash einen funktionierenden Exploit zu erzeugen. Hinzu komme der Skalierungseffekt: Während Forscher früher nur an einer begrenzten Zahl von Projekten gearbeitet hätten, ließen sich heute automatisierte Pipelines gegen mehrere Ziele zugleich laufen.