Die FakeGit-Malware-Kampagne ist in großem Umfang zu GitHub zurückgekehrt. Forscher entdeckten 17.610 Repositories, die zur Verbreitung von SmartLoader verwendet werden, einer anfänglichen Payload, die weitere Malware herunterladen kann. Die erneute Aktivität begann am 4. Oktober 2026, nachdem die Kampagne Anfang des Monats bereits zur Verbreitung von StealC eingesetzt worden war, einer Informationsdiebstahl-Malware.
Die Kampagne stützt sich größtenteils auf temporäre Konten. Die Forscher identifizierten jedoch mindestens 700 Konten, die offenbar legitimen Entwicklern gehören. Die bösartigen Repositories verwenden überzeugend gestaltete README-Dateien mit einer Download-Schaltfläche, die zu einem ZIP-Archiv mit SmartLoader führt.
Schnelle Eskalation durch die Nutzung bestehender Repositories
Laut einem Bericht der auf Software-Lieferkettensicherheit spezialisierten Plattform Apiiro veröffentlichte die Kampagne innerhalb von 34 Stunden mehr als 13.000 Repositories. Die Aktivität erreichte dabei mit 2.999 Repositories pro Stunde ihren Höchststand. In den von den Forschern untersuchten Commit-Stichproben beschränkten sich 97 % auf die Änderung einer README-Datei, während die Download-Schaltfläche in 88 % der Fälle auf eine ZIP-Datei verwies, die SmartLoader installierte.
Dies deutet darauf hin, dass die Betreiber keine neuen Repositories erstellen mussten. Stattdessen lenkten sie eine bereits vorhandene Flotte auf bösartige Links um. Das Unternehmen Island hatte den Namen FakeGit bereits im Juli mit diesem Vorgang in Verbindung gebracht, als es 7.600 gefälschte Repositories dokumentierte, die SmartLoader verbreiteten. Darunter befanden sich 800 Repositories, die sich als Skills für künstliche Intelligenz oder als MCP-Server tarnten und in öffentlichen Registern und Katalogen auftauchten.
Warum ist die Kampagne schwer einzudämmen?
Die Apiiro-Forscher sind der Ansicht, dass das Entfernen der Repositories nur einen Teil der bösartigen Infrastruktur abdeckt. Die blockierten Payloads und ihre Backups bleiben weiterhin verfügbar. Dadurch können die Angreifer den Download-Link ändern und das Repository selbst aktiv halten. Die Forscher stellten fest, dass 71 % der Flotte vor der Veröffentlichung ihres Berichts nicht in URLhaus gelistet waren.
Die bösartigen Archive sind auf Forks, alten Dateien, Release-Assets, Issue-Anhängen und separaten, eigens für das Hosting eingerichteten Repositories verteilt. Daher verhindert das Löschen einer einzelnen Datei oder eines einzelnen Links nicht, dass der Betreiber das Opfer zu einer alternativen Kopie weiterleitet.
Was ändert sich dadurch praktisch für die Nutzer?
Die Existenz eines Repositories auf GitHub reicht nicht als Beleg für dessen Vertrauenswürdigkeit aus, insbesondere beim Herunterladen von KI-Skills oder MCP-Servern. Die Forscher empfehlen, den Besitzer des Repositories zu überprüfen und offizielle Register oder Repositories der Softwareanbieter als Installationsquellen zu nutzen.
Wenn ein Nutzer den Verdacht hat, dass SmartLoader ausgeführt wurde, sollte der Vorfall als möglicher kompromittierter GitHub-Account behandelt werden. Anschließend sollten aktive Sitzungen und Zugriffstoken widerrufen und auf Passkeys umgestellt werden. Die Kampagne verdeutlicht, dass der Einsatz von Link-Blocklisten oder das Löschen einzelner Repositories nur begrenzt wirksam ist, wenn der Angreifer Kopien, Branches und Release-Assets wiederverwenden kann.