#Netzwerk & Sicherheit · 3 Min. Lesezeit · Tim Rinkel

REPO-BEBEN BEI MICROSOFT! Der Konzern reißt JETZT 73 eigene GitHub-Projekte vom Netz — in nur 105 Sekunden

REPO-BEBEN BEI MICROSOFT! Der Konzern reißt JETZT 73 eigene GitHub-Projekte vom Netz — in nur 105 Sekunden

Es ging blitzschnell: Microsoft hat 73 eigene GitHub-Repositories vom Netz genommen — in gerade einmal 105 Sekunden. Betroffen waren Projekte aus den Organisationen Azure, microsoft, Azure-Samples und MicrosoftDocs. Der Grund: ein Lieferketten-Angriff aus der laufenden Miasma/Shai-Hulud-Welle.

Was genau passiert ist

Ausgangspunkt war ein schädlicher Commit im Repository Azure/durabletask, eingeschleust über ein offenbar kompromittiertes Mitwirkenden-Konto. Mehrere Forscher bestätigten: Die Repos wurden im Zuge einer Miasma/Shai-Hulud-Kampagne kompromittiert — derselben Wurm-Familie, die zuvor schon offizielle npm-Pakete großer Anbieter erwischt hatte.

Microsoft reagierte mit dem Holzhammer: Lieber kurz alles abschalten, als das Risiko laufen zu lassen. Ein großer Teil der gesperrten Repos hängt an Azure Functions — Laufzeit, SDKs, sprach-spezifische Worker und Deploy-Werkzeuge.

Der Kollateralschaden: kaputte Pipelines

Die heftigste unmittelbare Folge war das Deaktivieren von Azure/functions-action — einer GitHub-Action, mit der unzählige Entwickler ihre Azure-Functions ausrollen. Plötzlich fand die Pipeline nichts mehr unter der angegebenen Adresse: Workflows brachen ab, Deployments standen still, Verwirrung machte sich breit. Ein Lehrstück, wie ein einziges gesperrtes Repo eine ganze CI/CD-Kette lahmlegt.

Entwarnung — aber mit Beigeschmack

Inzwischen sind laut Microsoft alle Repositories wiederhergestellt und gelten als sauber und sicher. Die Aktion zeigt zweierlei: Erstens, dass die Lieferketten-Angriffe längst auch die First-Party-Repos der Tech-Riesen treffen — nicht nur kleine Pakete. Zweitens, dass schnelle, harte Reaktion (105 Sekunden!) den Schaden begrenzen kann — wenn sie denn die eigene Infrastruktur mitreißt.

Was du daraus mitnehmen solltest

Wer in seiner Pipeline auf fremde GitHub-Actions setzt, hat eine Abhängigkeit, die jederzeit verschwinden kann. Drei einfache Lehren:

  • Actions auf einen festen Commit-Hash pinnen statt auf ein bewegliches Tag — dann ändert sich nichts unter dir.
  • Kritische Actions spiegeln oder vendorn, damit ein gesperrtes Repo dich nicht ausbremst.
  • Mitwirkenden-Konten absichern (2FA, Hardware-Schlüssel) — der Einstieg lief auch hier über ein gekapertes Konto.

Hinweis: Die Darstellung beruht auf Berichten von Sicherheitsmedien zum Vorfall vom 5. Juni. Microsoft hat die betroffenen Repos nach eigener Angabe wiederhergestellt.

Häufige Fragen

Welche Repositories waren betroffen?
73 Repos aus den GitHub-Organisationen Azure, microsoft, Azure-Samples und MicrosoftDocs. Ein großer Teil hängt an Azure Functions — Laufzeit, SDKs, sprach-spezifische Worker und Deploy-Werkzeuge. Einstiegspunkt war ein schädlicher Commit in Azure/durabletask.
Sind meine Deployments noch in Gefahr?
Laut Microsoft sind alle Repos wiederhergestellt und gelten als sauber. Während der Sperre fiel jedoch die GitHub-Action Azure/functions-action aus, sodass abhängige Deploy-Workflows abbrachen. Prüfe deine Pipelines auf Fehlläufe in diesem Zeitfenster.
Wie hängt das mit npm-Würmern zusammen?
Der Vorfall gehört zur Miasma/Shai-Hulud-Lieferketten-Welle, die zuvor schon offizielle npm-Pakete großer Anbieter traf. Hier erwischte sie über ein kompromittiertes Mitwirkenden-Konto Microsofts eigene Git-Repos.
Wie schütze ich meine CI/CD vor so etwas?
Pinne fremde GitHub-Actions auf einen festen Commit-Hash statt auf ein bewegliches Tag, spiegele oder vendore kritische Actions und sichere Mitwirkenden-Konten mit 2FA und Hardware-Schlüsseln ab.

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert