In den meisten Sicherheitsgeschichten dieses Newsletters geht es um Dinge, die unmittelbar dir passieren: eine Phishing-SMS, ein geleaktes Passwort, eine gefälschte Shopping-Website. Diese hier ist anders. Die folgenden Vorfälle betrafen Entwickler – die Menschen, die die Apps und Dienste schreiben, die du täglich nutzt. Aber warum sie hierhergehören, ist einfach: Wenn jemand die Werkzeuge vergiftet, mit denen Software entwickelt wird, bleibt das Gift nicht beim Entwickler. Es wird mit dem Produkt ausgeliefert.

Vor Kurzem sind zwei Dinge passiert, die das veranschaulichen. Keines davon machte so Schlagzeilen wie ein großer Datenleak, weil es sich bei keinem um einen direkten Angriff auf dich handelt. Beide sind Angriffe auf die Pipeline, in der die Software entsteht, die du später installierst, öffnest oder in der du dich anmeldest.

Gefälschte Erweiterungen im Gewand vertrauenswürdiger Marken

Open VSX ist ein öffentliches Verzeichnis für Erweiterungen von Code-Editoren – kleine Add-ons, die Entwickler installieren, um Autovervollständigung, Linting und Integrationen für die täglich verwendeten Tools zu erhalten (Visual Studio Code und mehrere seiner Open-Source-Verwandten beziehen Erweiterungen daraus). Zwischen dem 26. Juli und dem 1. August 2026 fanden Sicherheitsforscher von Manifold Security 77 gefälschte Erweiterungen im Verzeichnis. Jede davon kopierte den Namen und Namespace einer echten, vertrauenswürdigen Erweiterung, wurde aber von einem Konto veröffentlicht, dem das Original nicht gehörte – ein klassischer Identitätsmissbrauch, manchmal auch Namespace-Squatting genannt.

Die besetzten Namen waren nicht zufällig gewählt. Sie liehen sich die Identitäten von AMD, LEGO Education, Hyperledger, Azure, Artsy, Open-Source-Projekten von Salesforce, einer US-Bundesbehörde und – mit einer gewissen düsteren Ironie – dem Erweiterungsmarktplatz selbst. Jedes der 77 Pakete telefonierte mit einer einzigen Domain nach Hause, die erst 11 Tage vor dem Auftauchen des ersten gefälschten Pakets registriert worden war – ein Muster, das eher auf eine koordinierte, eigens dafür entwickelte Kampagne als auf opportunistisches Nachahmen hindeutet.

Die meisten gefälschten Erweiterungen taten etwas eher Harmloses: Sie meldeten unauffällig einen Hostnamen an den Server des Angreifers zurück, was für sich genommen lediglich ein Test sein kann, um herauszufinden, wer den Köder installiert hat. Die Forscher stellten jedoch fest, dass etwa ein Viertel der 77 – 19 Pakete – weiterging. Sekunden nach der Aktivierung sammelten sie den Hostnamen, den Benutzernamen des Betriebssystems, Editorinformationen und eine Geräte-ID. Anschließend lasen sie das gerade geöffnete Projekt des Entwicklers aus: die Git-Remote (die Aufschluss über die Organisation und den Repository-Host gibt), die Domain der Commit-E-Mail-Adresse, den aktuellen Branch und den letzten Commit. Außerdem zogen sie Werte aus der Continuous Integration ab – Zugangsdaten und Konfigurationen, mit denen automatisierte Systeme Code erstellen und bereitstellen können, ohne dass jedes Mal ein Mensch ein Passwort eingeben muss.

Keine dieser Daten ist nützlich, um das Bankkonto einer Person leerzuräumen. Sie sind für etwas anderes nützlich: herauszufinden, für welche Unternehmen ein Entwickler arbeitet, wie deren interne Infrastruktur aussieht und wie man sich darin einen Fuß in die Tür stellt.

Ein Bug mit einem Wert von 9,8 von 10 in der Maschine, die die Software erstellt

Der zweite Vorfall betrifft TeamCity, eine Plattform für Continuous Integration und Continuous Delivery (CI/CD) von JetBrains. Wenn ein Code-Editor der Ort ist, an dem Entwickler Software schreiben, ist eine CI/CD-Plattform die automatisierte Fabrikhalle, in der dieser Code kompiliert, getestet und in die Produktion gebracht wird – oft ohne dass überhaupt ein Mensch auf „Bereitstellen“ klicken muss. TeamCity ist bei vielen Unternehmen ein zentraler Bestandteil dieser Maschinerie.

Eine als CVE-2026-63077 erfasste Sicherheitslücke mit einem Schweregrad von 9,8 von maximal 10 wurde in den On-Premises-Versionen von TeamCity veröffentlicht. Es handelt sich um eine Deserialisierungsschwachstelle – eine Fehlerklasse, bei der ein Programm eingehenden Daten so weit vertraut, dass es sie direkt in ausführbaren Code umwandelt, ohne vorher zu prüfen, worum es sich bei diesen Daten tatsächlich handelt. Praktisch ermöglichte sie einem Angreifer, ohne erforderliche Anmeldung eine Anfrage an einen verwundbaren TeamCity-Server zu senden und beliebige Befehle mit denselben Berechtigungen wie der TeamCity-Dienst selbst auszuführen. JetBrains veröffentlichte Patches (Versionen 2025.11.7 und 2026.1.3 sowie ein Patch-Plugin für ältere Installationen ab 2017.1), doch die US-amerikanische Cybersecurity and Infrastructure Security Agency (CISA) warnte inzwischen, dass Angreifer ungepatchte Systeme aktiv ausnutzen.

Wer den Build-Server eines Unternehmens kontrolliert, kontrolliert, was dieses Unternehmen ausliefert. Das ist keine hypothetische Annahme – es ist buchstäblich die Funktion dieses Tools.

Dasselbe Vorgehen, zwei verschiedene Türen

Diese Vorfälle stehen in keinem Zusammenhang und stammen von unterschiedlichen Forschern, haben aber eine gemeinsame Struktur. Keiner von beiden greift ein fertiges Produkt an. Beide greifen eine Stufe früher an – den Editor, in dem ein Entwickler Code schreibt, oder den Server, der diesen Code in ein ausgeliefertes Release verwandelt. Das ist das entscheidende Merkmal eines Software-Lieferkettenangriffs: Statt in ein einzelnes Ziel einzubrechen, kompromittiert man etwas vorgelagertes, von dem viele Ziele abhängen, und lässt deren eigenen vertrauenswürdigen Prozess den Zugriff für einen weitertragen.

Wir sollten ehrlich damit sein, was wir noch nicht wissen. Keiner der in dieser Woche veröffentlichten Berichte nannte einen bestätigten Fall, in dem eine nachgelagerte App oder ein Nutzer als direkte Folge kompromittiert wurde – die Kampagne mit den Erweiterungen sieht nach Aufklärung und dem Sammeln von Zugangsmöglichkeiten aus, und die Ausnutzung von TeamCity wird als aktiv beschrieben, jedoch ohne namentlich genannte Opfer. Das ist normal; Kompromittierungen der Lieferkette werden oft lange vor (oder anstelle) der Rückverfolgung des eigentlichen Nutzens am Einstiegspunkt entdeckt.

Warum das dein Problem ist, nicht nur ihres

Wahrscheinlich wirst du niemals eine Coding-Erweiterung installieren oder einen CI/CD-Server betreiben. Aber du nutzt die Ergebnisse von Hunderten davon: deine Banking-App, deinen Passwortmanager, das Schulportal deines Kindes, den Browser, in dem du das hier liest. All das durchlief den Editor irgendeines Entwicklers und die Build-Pipeline irgendeines Unternehmens, bevor es dein Smartphone erreichte. Wenn eines dieser Glieder unbemerkt kompromittiert ist, kann die bösartige Änderung zusammen mit einem gewöhnlichen, routinemäßigen Softwareupdate mitgeliefert werden – genau der Art von Update, die du installierst, weil man dir gesagt hat, Aktualisieren sei sicher.

Das ist auch der Grund, warum die Ratschläge in einem Bericht zur Aufarbeitung eines Sicherheitsvorfalls für technisch nicht versierte Leser manchmal seltsam klingen: Ein Unternehmen sagt, seine Systeme seien über einen Build-Server, ein gestohlenes Entwicklerkonto oder eine bösartige Abhängigkeit kompromittiert worden, und im Vergleich zu „Jemand hat mein Passwort erraten“ kann das abstrakt wirken. Das ist es nicht. Es ist dasselbe Ergebnis – deine Daten oder die Integrität deiner App wurden kompromittiert –, das durch eine Tür erreicht wurde, von deren Existenz du nichts wusstest.

Was tatsächlich hilft

Du kannst die CI/CD-Pipeline deiner Bank nicht prüfen, und das solltest du auch nicht müssen. Aber ein paar Gewohnheiten verringern deine Gefährdung durch diese Risikokategorie tatsächlich:

Lass automatische Updates aktiviert, betrachte Updates aber nicht automatisch als vertrauenswürdig. Patches sind der Weg, auf dem Fehlerbehebungen wie die oben erwähnte für TeamCity die von dir verwendete Software erreichen – wenn du auf dem aktuellen Stand bleibst, schließt du Fenster, die Angreifer aktiv überprüfen. Gleichzeitig ist ein Update nur so gut wie die Pipeline, die es erstellt hat – und genau diese wird hier angegriffen; gegen ein tatsächlich vergiftetes vorgelagertes Release gibt es für Einzelpersonen keinen perfekten Schutz. Deshalb ist dies grundsätzlich ein Problem in der Verantwortung des Anbieters und nicht dein Problem.

Wenn du mit Entwicklern arbeitest oder sie betreust, gibt es zwei konkrete, überprüfbare Dinge: Vergewissere dich, dass jede Code-Editor-Erweiterung tatsächlich vom verifizierten Herausgeberkonto und nicht nur unter einem passenden Namen installiert wurde (Open VSX und ähnliche Marktplätze zeigen die Identität des Herausgebers an – überprüfe sie und vertraue nicht allein auf Symbol und Titel); und falls deine Organisation TeamCity On-Premises betreibt, stelle noch heute sicher, dass 2025.11.7 oder 2026.1.3 installiert ist oder das Patch-Plugin angewendet wurde, nicht erst im nächsten Wartungsfenster – die Warnung der CISA bedeutet, dass dies aktiv ausgenutzt wird und nicht nur theoretisch ist.

Für alle anderen besteht die nützliche Veränderung lediglich in mehr Bewusstsein: Wenn du über einen Unternehmensangriff liest, der auf „ein kompromittiertes Entwickler-Tool“ oder „ein Build-System“ zurückgeht, ist das keine nebensächliche technische Fußnote. Es handelt sich um dieselbe Kategorie von Vorfall wie bei den Passwort-Leaks und Phishing-Betrügereien, über die dieser Newsletter häufiger berichtet – er begann nur eine Ebene weiter vorgelagert, bevor das Produkt dich überhaupt erreichte.