GitHub ist heute unverzichtbar für Millionen von Entwicklern, die dort Quellcode speichern, verwalten und gemeinsam an Projekten arbeiten. Die Plattform bietet eine enorme Reichweite, hohe Benutzerfreundlichkeit und fördert die Zusammenarbeit. Doch trotz des enormen Erfolgs gibt es Schwachstellen in GitHubs Sicherheitsmechanismen, die immer wieder von Sicherheitsspezialisten entdeckt werden. Diese Schwachstellen ermöglichen es Angreifern, Commit-Autoren zu fälschen, manipulierte Beiträge als vertrauenswürdig dastehen zu lassen und sogar Phishing-Angriffe über scheinbar harmlose GitHub-Issues durchzuführen. Das Zusammenspiel von Designentscheidungen und technischen Limitationen offenbart eine interessante Grauzone, die sowohl Angriffsmöglichkeiten als auch Herausforderungen für die Sicherheit der Nutzer bedeutet. Ein tieferer Blick auf diese Risiken lohnt sich, um zu verstehen, wie die vermeintlich sichere Plattform GitHub ausgenutzt werden kann und welche Schutzmaßnahmen sinnvoll sind.
Spoofing von Commit-Autoren gehört zu den eindrucksvollsten Spielarten der Manipulation auf GitHub. Dabei nutzt ein Angreifer, der einen GitHub-Benutzernamen sowie die zugehörige E-Mail-Adresse kennt, genau diese Daten, um eigene Commits unter dem Namen anderer Personen zu erstellen. Dies mag zunächst harmlos erscheinen, doch vermittelt es den Eindruck, als wären diese Codeänderungen tatsächlich von bekannten Mitgliedern eines Projektes oder sogar von Führungskräften. Ein prominentes Beispiel ist die Nachahmung des CEO von GitHub, Thomas Dohmke. Wer den Benutzernamen kennt und anhand öffentlicher Repositories die verwendete E-Mail-Adresse herausfindet, kann ganz einfach in einem eigenen Repository getarnte Commits einfügen, die im Anschluss mit push-Berechtigungen versehen werden. GitHub verknüpft die Commit-Metadaten – insbesondere die E-Mail – mit Benutzerprofilen und zeigt diese Verbindung in der Benutzeroberfläche an.
Dadurch entsteht ein trügerischer Eindruck von Authentizität, während die Änderungen tatsächlich von einer unautorisierten Person stammen. Dieses Szenario wird dadurch verstärkt, dass auf den ersten Blick ein gefälschtes Commit genau so aussieht wie ein echtes. Selbst bei der Sichtung des Commit-Verlaufs könnte ein unbedarfter Nutzer kaum einen Unterschied sehen, sofern die sogenannten Signaturen nicht zwingend erforderlich sind. GitHub bietet zwar die Möglichkeit, einen Commit durch GPG-Signaturen zu verifizieren, allerdings ist diese Funktion noch nicht flächendeckend aktiviert. Ein Status „Unverified“ erscheint bei gefälschten Commits, wenn Vigilant Mode aktiviert ist, wird aber oft übersehen, da die Darstellung nicht ausreichend hervorgehoben wird. Für versierte Angreifer gibt es sogar einen Trick: Die Verwendung der sogenannten „Co-authored-by“-Option, bei der mehrere Autoren in einem Commit eingetragen werden können.
So lässt sich ein teilweise verifizierter Status erzeugen – ein grünes Häkchen, das Sicherheit suggeriert und das Vertrauen weiter erhöht. Ein weiterer Aspekt, der den Angriff erleichtert, ist die Tatsache, dass öffentliche Repositories robustere Sichtbarkeit bieten. Wenn ein Repository vor dem Pushen der gefälschten Commits als öffentlich markiert wird, erscheinen die als „Mitwirkende“ gelisteten Benutzer auf der Projektseite. Das heißt: Der falsche Mitwirkende taucht an prominenter Stelle auf und verstärkt den Eindruck von Legitimität und Anerkennung. Auch wenn man die Repository-Einstellungen im Anschluss wieder ändert, bleibt die Spuren in den Statistiken sichtbar. Neben dem Commit-Spoofing war es bis 2024 möglich, Schadpayloads unbemerkt unter github. com abzulegen – und zwar über Funktionen wie das Hochladen von Dateien in Issues oder Pull Requests. Angreifer konnten so gezielt Malware verteilen, ohne dass GitHub die Dateien effektiv blockierte.
Nach einigen Malware-Kampagnen reagierte GitHub und versuchte, die Sicherheitslücken zu schließen. Temporäre Uploads finden sich nun in Benutzerordnern mit inkrementellen ID-Pfaden, die zwar immer noch theoretisch angreifbar sind, aber durch Rate Limiting und Löschmechanismen erschwert werden. Zudem werden Dateien, die keine Bezüge mehr in Issues oder Pull Requests haben, nach einer gewissen Zeit gelöscht. Wer also eine Payload in einem Issue hochlädt, kann diese nur kurzzeitig zugänglich machen, was den Missbrauch deutlich erschwert. Ein besonders kreativer Missbrauch der Plattform erfolgt durch die Nutzung der Issues-Funktion zum Phishing. Entwickler und Projektverantwortliche erhalten bei neuen Issues E-Mail-Benachrichtigungen, die Links, Formatierungen und Profilbilder enthalten. Betrüger können gezielt harmlose Links in Issues verstecken und mit stringenten Profil-Designs Aufmerksamkeit erregen.
Ein gefälschtes Profil mit vertrauenserweckendem Namen sowie passend gestaltetem Profilbild kann in der E-Mail-Benachrichtigung als Absender erscheinen. Auch wenn die Formatierungen in den Benachrichtigungen beschränkt sind, bieten Überschriften, fettgedruckte Texte und einfache Links genug Potential, um Nutzer zum Klicken und somit zur Kontenkompromittierung zu verleiten. Während die HTML-Unterstützung in E-Mail-Notifications eingeschränkt bleibt, existieren kreativ genutzte Tricks, wie das Einbetten von SVG-Grafiken oder sogar LaTeX-basierte farbige Texte, die vor allem auf der Online-Seite der Issues wirken, wenn auch nur visuell, ohne in der E-Mail zu landen. Diese visuelle Täuschung kann den Eindruck einer offizielle und wichtigen Meldung erwecken und so Phishing-Mails sehr glaubhaft machen. Das Zusammenspiel von Designschwächen und leichter Identitätsfälschung macht GitHub-Issues zu einem interessanten Angriffsvektor.
Aus der Perspektive eines erfahrenen Entwicklers oder Sicherheitsspezialisten ist es daher wichtig, mit gesundem Misstrauen auf neue Notifications zu reagieren, insbesondere wenn Links enthalten sind, die zu kritischen Einstellungen führen sollen oder Aktionen erfordern. GitHub hat zwar nach und nach viele der bekannten Schwachstellen adressiert, beispielsweise durch Limits bei den Uploads oder bessere Hinweise zur Commit-Verifizierung, dennoch bleibt die „By-Design“-Natur einiger Funktionen problematisch. Die Möglichkeit, Commit-Autoren frei zu setzen und damit Identitäten fast beliebig zu fälschen, ist im Kern ein Resultat der Offenheit von Git als verteiltem Versionskontrollsystem. Gleichwohl kann die fehlende verpflichtende Signatur für wichtige Projekte und Anwender eine gravierende Sicherheitslücke bleiben. Ein weiteres Problem zeigt sich darin, dass selbst Verantwortliche bei GitHub diese Schutzfunktionen nicht verpflichtend nutzen.
Der Einsatz von Vigilant Mode zur verpflichtenden Commit-Signierung ist selbst im höchsten Führungskreis nicht durchgängig aktiviert. Dies verdeutlicht, wie schwierig eine durchgängige Sicherheitskultur in einer so komplexen Plattform aufgebaut werden kann. Neben der Hauptplattform kann das Hosting von Dateien über Support-Tickets im Zendesk-Portal zwar genutzt werden, um Malware oder Schadcode zu speichern, doch sind die Dateien nur temporär verfügbar und werden systemseitig bereinigt. Das neue Konzept schränkt den Missbrauch stark ein und entzieht dem Angreifer die langfristige Basis. Auch der stille Versuch, Unterstützung oder Dateien über realitätsnahe Support-Tickets zu verstecken, wird nur schwerlich längerfristig erfolgreich sein. Für den Endnutzer und Entwickler empfiehlt es sich daher, neben der Verwendung von GitHub-Standards auch eigene Schutzmechanismen zu etablieren.
Hierzu zählt unter anderem die verpflichtende Signierung von Commits durch GPG oder andere anerkannte Methoden, um den Vertrauensstatus sichtbar und verifizierbar zu machen. Ebenso ist eine gesunde Skepsis bei E-Mail-Benachrichtigungen zu empfehlen, besonders wenn enthaltene Links zum Handeln animieren oder dringlich erscheinen. Wer zusätzlich auf bewährte Security-Tools setzt, beispielsweise Multi-Faktor-Authentifizierung und regelmäßige Audit-Prozesse für eigene Repositories durchführt, erhöht den Schutz erheblich. Zusammenfassend zeigt die Analyse der GitHub-Sicherheitslücken und kreativen Angriffsmöglichkeiten, dass die Plattform trotz aller Vorteile Schwachstellen kennt, die von Angreifern ausgenutzt werden können. Die Offenheit von Git, gepaart mit teilweise wenig restriktiven Features, bietet Einfallstore für Spoofing, Phishing und Malware-Hosting. Dennoch bietet GitHub mit zahlreichen Updates, Signaturmechanismen und Monitoring-Features Werkzeuge, um diese Gefahren zu begegnen.
Ein bewusster Umgang mit der Plattform, aufgeklärte Nutzer und konsequente Sicherheitsmaßnahmen sind essenziell, um den eigentlichen Zweck von GitHub – der gemeinsamen und sicheren Softwareentwicklung – bestmöglich zu erfüllen. Wer die Grenzen von GitHub kennt und gleichzeitig die bestehenden Sicherheitsangebote nutzt, kann Spaß am Entwickeln und Teilen von Code haben, ohne unnötige Risiken einzugehen.
