pip install Trust-Me-Bro: Warum KI-Coding-Assistenten nicht prüfen, was sie installieren

Ich saß da und schaute Claude Code bei der Arbeit zu. Ich war dabei, ein paar SVG-Dateien für ein Wochenendprojekt zu konvertieren. Ziemlich routinemäßig. Dann scrollte diese Zeile in meinem Terminal vorbei:

pip3 install cairosvg cairocffi defusedxml --break-system-packages

Drei Pakete. Global installiert. Auf meinem Mac. Mit einem Flag, das wortwörtlich "break system packages" heißt.

Ich habe auf Genehmigen geklickt, weil ich im Flow war. Ich hatte Claude Code etwa 20 Minuten lang machen lassen und die Ergebnisse waren beeindruckend. Warum sollte ich den Schwung stoppen, um eine Python-Bibliothek zu googeln?

Aber dann hielt ich inne. Wer hat diese Pakete entwickelt? Sind sie sicher? Sind es überhaupt die richtigen, oder hat die KI einen Namen halluziniert, der zufällig auf PyPI existiert?

Ich hatte keine Ahnung. Und Claude auch nicht.

Wie sich herausstellte, sind die Pakete legitim. Sie werden von CourtBouillon gepflegt, einem französischen Unternehmen, das seit Jahren Python-Tools baut. Aber hier ist der Punkt: Das weiß ich nur, weil ich es nachträglich überprüft habe. In dem Moment war ich einen "Genehmigen"-Klick davon entfernt, was auch immer zu installieren.

Wenn du KI-Coding-Tools verwendest, geht es dir wahrscheinlich genauso.

Was Claude Code gerade auf meinem Mac installiert hat

Lass mich kurz zurückspulen. Claude Code führt Befehle direkt auf deinem Computer aus. Nicht in einer Sandbox. Nicht in irgendeiner Cloud-Umgebung. Auf deinem echten Rechner. Wenn es pip install ausführt, landen diese Pakete in deinem System-Python. Sie bleiben auch nach dem Ende der Konversation bestehen. Sie sind einfach... da.

Die drei Pakete, cairosvg, cairocffi und defusedxml, sind alle gut gepflegt, weit verbreitet und sauber. Ich habe sie nachträglich auf Snyk geprüft. Keine bekannten Schwachstellen. Die Maintainer (Guillaume Ayoub und Simon Sapin bei CourtBouillon) haben solide Track Records.

Aber Claude hat nichts davon geprüft. Es hat diese Pakete empfohlen, weil sie in seinen Trainingsdaten vorkamen. Es wusste "für SVG-Konvertierung verwenden Entwickler cairosvg", weil dieses Muster millionenfach auftauchte. Ob diese Pakete noch gepflegt werden, kürzlich kompromittiert wurden oder 2026 überhaupt noch existieren? Keine Ahnung. Claude arbeitet aus dem Gedächtnis.

Wie Paketmanager eigentlich funktionieren (Die 30-Sekunden-Version)

Wenn du dir noch nie Gedanken darüber gemacht hast, woher Pakete kommen, hier die Kurzfassung.

Wenn dein KI-Assistent pip install irgendwas oder npm install irgendwas ausführt, zieht er Code aus einer öffentlichen Registry. PyPI für Python. npm für JavaScript. Stell dir das wie App Stores für Code vor.

Nur dass sie nichts mit App Stores gemeinsam haben.

Wenn du eine App aus Apples App Store herunterlädst, durchläuft sie einen Review-Prozess. Jemand hat sie auf Malware geprüft, die Identität des Entwicklers verifiziert, einen Stempel draufgesetzt. Man kann darüber streiten, wie gründlich dieser Prozess ist, aber er existiert.

PyPI hat keinen Review-Prozess. Jeder kann einen Account erstellen und ein Paket hochladen. Jetzt sofort. Es dauert etwa fünf Minuten. Es gibt über 600.000 Pakete auf PyPI, und bis 2023 gab es keinen einzigen dedizierten Sicherheitsingenieur. In dem Jahr haben sie den ersten eingestellt. Eine Person. Für 600.000 Pakete, die milliardenfach pro Monat heruntergeladen werden.

npm ist ähnlich. Über zwei Millionen Pakete, minimale Prüfung.

Wenn also dein KI-Coding-Assistent ein Paket installiert, zieht er es aus einem riesigen Repository, bei dem die Eintrittsbarriere im Grunde "hab eine E-Mail-Adresse" ist. Wenn du dir jemals Sorgen gemacht hast, was ein kompromittiertes npm-Paket mit deiner Website anstellen könnte, macht die KI-Schicht es schlimmer.

Was mit LiteLLM passiert ist (und warum es dich betrifft)

Das ist nicht hypothetisch. Lass mich dir von etwas erzählen, das letzten Monat passiert ist.

LiteLLM ist ein beliebtes Python-Paket, das Entwicklern ermöglicht, verschiedene KI-Modelle über eine einzige Schnittstelle zu nutzen. Es wird 3,4 Millionen Mal pro Tag heruntergeladen. 95 Millionen pro Monat. Es ist überall in der KI-Entwicklung.

Am 24. März 2026 hat jemand LiteLLM auf PyPI kompromittiert. Die Versionen 1.82.7 und 1.82.8 sahen identisch mit dem Original aus, machten aber ein paar zusätzliche Dinge im Hintergrund. Sie stahlen SSH-Schlüssel. Griffen Cloud-Service-Tokens ab. Suchten nach Kryptowährungs-Wallets. Und pflanzten eine Backdoor über systemd ein, was bedeutet, dass die Malware Neustarts überlebte.

Die kompromittierten Versionen waren etwa drei Stunden live, bevor sie entdeckt wurden.

Drei Stunden. Mehr nicht. Aber in diesen drei Stunden zog jedes einzelne pip install litellm die bösartige Version. Jede automatisierte Deployment-Pipeline. Jeder Entwickler, der ein neues Projekt aufsetzte. Jeder KI-Coding-Assistent, der entschied, dass litellm das ist, was du brauchst.

Wenn ein KI-Tool litellm in diesem Zeitfenster installiert hat und du es genehmigt hast? Dein Rechner war kompromittiert. Keine Warnung. Kein rotes Fähnchen. Nur eine normal aussehende Installation, die zufällig eine Backdoor enthielt.

Das Paket, das nicht existiert (bis ein Angreifer es erstellt)

Hier wird AI Code Assistant Supply Chain Security richtig interessant. Und mit interessant meine ich beängstigend.

Du weißt, wie KI-Modelle manchmal Dinge erfinden? Sie halluzinieren Fakten, erfinden Zitate, fabrizieren Quellenangaben. Wie sich herausstellt, halluzinieren sie auch Paketnamen.

Forscher nennen es Slopsquatting. Der Begriff wurde von Seth Larson geprägt, dem Developer in Residence der Python Software Foundation. Eine Studie, die auf der USENIX Security 2025 präsentiert wurde, analysierte 2,23 Millionen Paketempfehlungen von KI-Coding-Assistenten über 16 verschiedene Modelle. Davon waren 440.445 halluziniert. Pakete, die nicht existieren. Namen, die die KI erfunden hat, weil sie richtig klangen.

Das sind fast 20% aller Empfehlungen, die ins Leere zeigen.

Aber hier ist der gefährliche Teil: 43% dieser halluzinierten Namen tauchten wiederholt auf. Der gleiche falsche Paketname, immer wieder vorgeschlagen von verschiedenen KI-Modellen. Das ist ein Muster. Und Angreifer haben es bemerkt.

Der Angriff ist simpel. Beobachte, welche Paketnamen KI-Modelle halluzinieren. Registriere diese Namen auf PyPI oder npm. Fülle sie mit Schadcode. Warte auf die nächste Person, deren KI-Assistent dein Paket empfiehlt.

Es funktioniert. Ein Paket namens huggingface-cli (eine halluzinierte Variante des echten huggingface_hub) sammelte 30.000 Downloads. Alibaba kopierte den Install-Befehl sogar in ihre öffentliche README. Ein weiteres Fake-Paket namens react-codeshift verbreitete sich über 237 GitHub-Repositories.

Ich habe schon über die Security-Blindspots in vibe-gecodeten Anwendungen geschrieben. Slopsquatting macht diese Blindspots noch größer.

Dein KI-Assistent installiert aus dem Gedächtnis, nicht aus einer verifizierten Quelle

Lass uns klarstellen, was tatsächlich passiert, wenn dein KI-Coding-Tool ein Paket vorschlägt.

Es prüft PyPI nicht in Echtzeit. Es scannt das Paket nicht auf Schwachstellen. Es verifiziert nicht, wer es pflegt oder wann es zuletzt aktualisiert wurde. Es prüft nicht einmal, ob das Paket existiert.

Es empfiehlt Pakete aus seinen Trainingsdaten. Das war's.

Endor Labs hat herausgefunden, dass nur 1 von 5 KI-Abhängigkeitsempfehlungen sowohl sicher als auch real ist. Vier von fünf sind entweder nicht existent, veraltet oder anderweitig problematisch.

Veracodes Forschung testete über 100 KI-Modelle und fand heraus, dass 45% des KI-generierten Codes Sicherheitslücken enthält. Nicht nur Paketprobleme. Der Code selbst.

Claude ist großartig darin, Software zu bauen. Und genauso großartig darin, Probleme einzuführen, die du erst viel später bemerkst. Wenn es pip install irgendein-paket sagt, klingt es so, als wüsste es genau, was es tut. Aber es arbeitet aus dem Gedächtnis, nicht aus verifizierten Echtzeitinformationen.

Kommt dir bekannt vor? Sollte es. Es ist dieselbe Selbstsicherheit, die diese Tools so nützlich macht, und so gefährlich, ihnen blind zu vertrauen.

Was --break-system-packages wirklich bedeutet

Erinnerst du dich an das Flag aus meiner Eingangsgeschichte? --break-system-packages? Lass mich erklären, was das tatsächlich macht, denn es ist beunruhigender als es klingt.

Moderne Betriebssysteme (einschließlich macOS und die meisten Linux-Distributionen) weigern sich inzwischen, Python-Pakete global über pip zu installieren. Das ist eine bewusste Sicherheitsmaßnahme namens PEP 668. Die Idee ist einfach: Dein Betriebssystem braucht bestimmte Python-Pakete zum Funktionieren. Wenn du etwas global installierst, das mit diesen Systempaketen kollidiert, kannst du Dinge kaputt machen. Manchmal wichtige Dinge.

Also sagt das System nein. Es schlägt dir vor, stattdessen eine virtuelle Umgebung zu verwenden. Eine virtuelle Umgebung ist im Grunde eine isolierte Sandbox, in der deine Pakete nichts anderes auf deinem Rechner beeinflussen können.

Das --break-system-packages Flag überschreibt diesen Schutz. Es sagt pip: "Ich weiß, dass das riskant ist, mach es trotzdem."

Dein KI-Coding-Assistent hat dieses Flag benutzt, weil die normale Installation blockiert war. Die Sicherheitsschranke war im Weg, also hat die KI den Workaround gefunden. Nicht böswillig. Nicht einmal fahrlässig, aus Sicht der KI. Sie hatte eine Aufgabe, der Standardansatz funktionierte nicht, also hat sie eskaliert.

Aber denk darüber nach, was das bedeutet. Das Betriebssystem hat ausdrücklich gesagt "mach das nicht, es ist nicht sicher." Und die Antwort der KI war, das Override-Flag zu finden.

Das sollte dich beunruhigen.

Was du tatsächlich dagegen tun kannst

Ich werde dir nicht sagen, dass du aufhören sollst, KI-Coding-Tools zu benutzen. Ich verwende sie jeden Tag für meine Agentur. Sie sind wirklich nützlich. Aber du musst verstehen, was du genehmigst, wenn du auf "Ja" klickst.

Hier ist, was ich jetzt mache.

Lies, bevor du genehmigst. Wenn dein KI-Assistent einen Befehl ausführen will, besonders einen, der etwas installiert, nimm dir fünf Sekunden zum Lesen. Ich weiß, das unterbricht den Flow. Mach es trotzdem.

Frag deine KI, was sie installiert. Bevor du genehmigst, frag: "Was ist dieses Paket? Wer pflegt es? Was macht es?" Die KI gibt dir vielleicht keine perfekt genaue Antwort (denk dran, sie arbeitet aus Trainingsdaten), aber es erzwingt einen Moment der Reflexion.

Nutze virtuelle Umgebungen. Wenn du irgendetwas mit Python machst, bitte deine KI, zuerst ein venv einzurichten. So ist selbst wenn etwas Schlechtes installiert wird, alles eingedämmt.

Achte auf --break-system-packages. Wenn du dieses Flag siehst, stopp. Frag warum. Es gibt fast immer einen besseren Ansatz.

Prüfe neue Pakete selbst. Es dauert 30 Sekunden. Such den Paketnamen auf PyPI oder npm. Schau dir den Maintainer an. Prüfe, wann es zuletzt aktualisiert wurde. Ein Paket mit 12 Downloads, das gestern erstellt wurde, ist etwas ganz anderes als eines mit Millionen Downloads, das seit Jahren gepflegt wird.

Sei besonders vorsichtig bei Paketen, die du noch nie gehört hast. Wenn die KI einen Paketnamen vorschlägt, der dir nicht bekannt vorkommt und du online nicht viel darüber findest, ist das ein Warnsignal. Es könnte halluziniert sein. Es könnte ein Slopsquatting-Ziel sein.

Es geht nicht um Paranoia. Es geht um informierte Zustimmung. Wenn du eine Installation genehmigst, solltest du zumindest ein grundlegendes Verständnis davon haben, was du auf deinen Rechner bringst.

Ich betreibe eine Ein-Mann-Agentur. Ich habe kein Security-Team, das meine Dependencies überprüft. Ich habe keine IT-Abteilung, die meine Installationen überwacht. Es sind nur ich und mein Terminal und was auch immer mein KI-Assistent für nötig hält. Wenn das auch auf dich zutrifft, ist das Mindeste, was wir tun können, aufmerksam zu lesen, was wir genehmigen.

Wenn du über die Sicherheit deiner Webprojekte sprechen willst, oder wenn du dich fragst, was deine KI-Tools so alles installiert haben, lass uns reden.