Die aktuelle Sicherheitsmeldung aus dem JetBrains-Ökosystem ist kein Randthema für ein paar IDE-Nerds, sondern ein sehr praktischer Hinweis darauf, wie verwundbar moderne Entwickler-Workflows geworden sind. Aikido Security hat eine koordinierte Kampagne mit mindestens 15 JetBrains-Plugins aufgedeckt, die sich als AI-Assistenten, Code-Review-Helfer oder Git-Tools ausgaben und dabei die in den Plugin-Einstellungen hinterlegten AI-API-Keys abgriffen. Zusammen kamen die Pakete laut Aikido auf fast 70.000 Installationen. BleepingComputer hat den Fall unabhängig aufgegriffen und ein betroffenes Plugin analysiert. Für Teams, die heute mit KI-Coding-Tools, Enterprise-Modellen und IDE-Erweiterungen arbeiten, ist das ein realer Supply-Chain-Vorfall im Alltag der Entwickler.
Worum es konkret geht
Die Analyse von Aikido ist klar: Die Angreifer haben nicht versucht, eine spektakuläre Zero-Day-Lücke im JetBrains-Client zu demonstrieren. Stattdessen nutzten sie etwas viel Alltäglicheres und damit Gefährlicheres: Vertrauen in den Marketplace und Vertrauen in ein Plugin, das im ersten Moment exakt das tut, was es verspricht. Wer ein Tool installiert, das angeblich DeepSeek-, OpenAI- oder andere KI-Dienste in die IDE integriert, erwartet nun einmal eine Stelle, an der ein API-Key hinterlegt wird. Genau an diesem Punkt schlug die Kampagne zu.
Beim Speichern der Einstellungen wurde der Key nicht nur für legitime Modellaufrufe verwendet, sondern zusätzlich an einen vom Angreifer kontrollierten Server weitergeleitet. Aikido beschreibt einen festen HTTP-Endpunkt unter einer öffentlichen IP-Adresse. Das ist aus zwei Gründen bemerkenswert. Erstens ist der Exfiltrationspfad banal und deshalb schwerer im normalen Alltag zu bemerken als eine komplexe Malware-Kette. Zweitens passierte der Abfluss direkt aus der Entwicklungsumgebung, also dort, wo Menschen oft mit den sensibelsten Zugriffen arbeiten: auf Quellcode, interne Repositories, Ticketing, Cloud-Konten und produktionsnahe Daten.
Warum das mehr ist als ein Plugin-Problem
Viele Unternehmen unterschätzen das Sicherheitsmodell ihrer IDEs. Ein Plugin wirkt auf den ersten Blick wie ein Komfortbaustein. Praktisch ist es aber Code mit Berechtigungen, Netzwerkzugriff und oft unmittelbarem Kontakt zu Secrets. Wer in einer IDE einen API-Key einträgt, speichert meist keine bloße Testkennung, sondern einen Produktionszugang, mit dem ein Modellabruf abgerechnet oder ein interner Dienst angesprochen wird. Genau deshalb ist der Verlust nicht nur ein Credential-Problem, sondern auch ein Kosten-, Governance- und Missbrauchsproblem.
Der Fall zeigt außerdem, wie sich Sicherheitsrisiken im KI-Zeitalter verschieben. Früher standen im Fokus häufig SSH-Keys, Git-Token oder Cloud-Credentials. Heute kommen zusätzlich AI-Provider-Keys dazu, und die landen nicht selten in einer wachsenden Zahl von Erweiterungen, Agenten und Integrationen. Das Problem ist nicht die KI selbst. Das Problem ist die neue Menge an Stellen, an denen ein Schlüssel eingegeben, zwischengespeichert, synchronisiert oder weitergereicht werden kann. Je mehr Werkzeuge sich um denselben Workflow gruppieren, desto größer wird die Angriffsfläche.
Was an der Kampagne besonders unangenehm ist
Besonders kritisch ist, dass die Plugins laut Aikido nicht sofort als offensichtlich bösartig auffielen. Sie funktionierten in vielen Fällen tatsächlich wie beworben. Das ist ein bekanntes Muster in modernen Supply-Chain-Angriffen: Das legitime Verhalten schafft Vertrauen, das schädliche Verhalten läuft daneben. Im Marketplace-Kontext ist das doppelt unangenehm, weil Sternebewertungen, Downloadzahlen und hübsche Beschreibungen eine Scheinsicherheit erzeugen können. Aikido weist ausdrücklich darauf hin, dass Downloadzahlen manipulierbar sind und teils gefälschte Fünf-Sterne-Bewertungen auftauchen können.
Auch die Zeitachse ist relevant. Die ersten betroffenen Versionen tauchten laut Aikido bereits Ende Oktober 2025 auf, neue Varianten wurden noch im Juni 2026 veröffentlicht. Das spricht nicht für einen einmaligen Fehltritt, sondern für eine länger laufende, koordinierte Kampagne. Wenn ein Angriff über Monate im Marketplace überlebt, ist das ein Hinweis darauf, dass App-Store-Governance allein nicht ausreicht. Wer Software aus einer zentralen Quelle installiert, hat damit noch keine ausreichende Vertrauensbasis. Es braucht zusätzliche Kontrollen auf Team- und Unternehmensebene.
Was Teams jetzt praktisch tun sollten
Die wichtigste Reaktion ist nicht Panik, sondern Inventur. Unternehmen sollten prüfen, welche JetBrains-Plugins im Einsatz sind, welche AI-Provider-Keys dort hinterlegt wurden und ob dieselben Erweiterungen in mehreren Umgebungen eingesetzt werden. Idealerweise verwendet man für externe Dienste ohnehin getrennte Keys pro Team, pro Tool und pro Umgebung. Ein kompromittierter Schlüssel darf nicht den Zugriff auf alles andere mitziehen. Wer heute noch einen generischen, breit berechtigten Schlüssel für mehrere Integrationen verwendet, baut sich unnötig viel Blast Radius ein.
Zweitens gehört die Netzwerkperspektive stärker in die IDE-Hygiene. Ein Plugin, das bei der Eingabe eines Keys ohne nachvollziehbaren Grund einen fremden HTTP-Endpunkt anspricht, ist verdächtig. In gut kontrollierten Umgebungen sollten aus Entwicklungsumgebungen ohnehin nur die notwendigen Ziele erreichbar sein. Netzwerk-Egress-Filter, DNS-Überwachung und Proxy-Logs sind nicht nur für Produktionsserver nützlich. Auch die Arbeitsplätze der Entwickler sind heute ein relevanter Sicherheitsrand.
Drittens sollten Security- und Plattform-Teams ihre Secret-Detection ernst nehmen. Viele Organisationen scannen Repositories auf geleakte Token, aber deutlich weniger prüfen die lokalen Toolketten. Wenn ein AI-Key in einer IDE-Erweiterung abgefragt wird, ist das ein anderer Kanal als ein versehentlich committeter String im Code. Trotzdem gehört beides in dieselbe Risikoklasse. Ein guter Prozess erkennt nicht nur Leaks im Git-Repo, sondern auch untypische Schlüsselverwendung in Telemetrie, Abrechnung und Provider-Logs.
Viertens braucht es klare Kriterien für Marketplace-Software. Nur Plugins mit echter betrieblicher Notwendigkeit sollten auf Entwickler-Rechnern landen. Alles andere ist Komfort, kein Muss. Für produktive Teams ist ein Whitelisting-Modell oft vernünftiger als eine offene Installation nach Zuruf. Das klingt streng, spart aber Zeit, wenn sich später herausstellt, dass eine scheinbar harmlose Erweiterung Daten abgezogen hat. Gerade in Teams mit Zugriff auf Kundendaten, Secrets oder Produktionssysteme ist diese Disziplin kein Overkill.
Die Einordnung für FreshCore-Leser
Für Leser mit Fokus auf Monitoring, Automatisierung, DevOps und Security ist der Fall besonders anschlussfähig. Er zeigt, dass Sicherheit nicht erst im Rechenzentrum beginnt, sondern schon am Arbeitsplatz der Menschen, die Infrastruktur bauen und betreiben. Wer heute AI-gestützte Workflows einführt, sollte dieselben Fragen stellen wie bei jeder anderen produktionsnahen Integration: Welche Daten fließen wohin? Welche Secrets werden verwendet? Welche Protokolle verlassen das System? Wie schnell lässt sich ein kompromittierter Schlüssel sperren und ersetzen? Und welche Signale würden wir überhaupt bemerken, wenn etwas schiefgeht?
Genau dort liegen die praktischen Konsequenzen. Beobachtbarkeit ist nicht nur etwas für Services, sondern auch für Entwicklungswerkzeuge. Wenn ein Plugin unerwartet mit externen Hosts spricht, wenn Provider-Keys plötzlich in untypischen Regionen auftauchen oder wenn ein Tool ungewöhnlich viele API-Aufrufe produziert, dann ist das ein Incident-Signal. Teams, die solche Muster früh sehen, können schnell rotieren, Keys tauschen und betroffene Erweiterungen entfernen, bevor ein größerer Schaden entsteht.
Fazit
Die JetBrains-Kampagne ist ein Lehrstück dafür, wie moderne Angriffe aussehen: Sie hängen nicht an einem einzelnen spektakulären Exploit, sondern an Vertrauen, Gewohnheit und einer Kette normal wirkender Schritte. Genau deshalb ist der Fall wichtig. Er betrifft Entwickler direkt, er berührt AI-Nutzung im Alltag und er zeigt, dass Supply-Chain-Sicherheit auch im kleinsten Werkzeug ernst genommen werden muss. Wer AI-Tools in der IDE nutzt, sollte nicht nur auf Produktivität schauen, sondern auf die Frage, wo die verwendeten Keys landen, welche Verbindungen das Tool aufbaut und ob der Marketplace wirklich schon eine ausreichende Vertrauensgrenze ist. Die ehrliche Antwort ist in vielen Teams: noch nicht.
Quellen
- Aikido Security: Multiple JetBrains IDE plugins caught stealing AI keys, 16. Juni 2026.
- BleepingComputer: Malicious JetBrains Marketplace plugins steal AI API keys from developers, 16. Juni 2026.
