Wenn Ihr Coding-Assistent ein Paket erfindet, registrieren Angreifer es zuerst

Bitten Sie einen KI-Coding-Assistenten, Importe aufzuräumen, und er liefert Ihnen möglicherweise einen Paketnamen, der nicht existiert. Der Name wirkt plausibel. Er kombiniert zwei echte Tools oder folgt einer Namenskonvention, die Sie kennen. Sie fügen den Installationsbefehl ein, und wenn jemand diesen Namen bereits registriert hat, haben Sie gerade installiert, was auch immer dieser veröffentlicht hat.

Sicherheitsforscher nennen das Slopsquatting. Es ist ein Verwandter des Typosquatting, nur dass der Angreifer nicht möchte, dass Sie sich vertippen. Er muss lediglich wissen, was das Modell tendenziell erfindet, und dann der Erste sein, der es beansprucht.

Das Ausmaß ist nicht anekdotisch

Eine USENIX-Security-Studie aus dem Jahr 2025 testete 16 codegenerierende Modelle an 576.000 Codebeispielen in Python und JavaScript. Sie fand mehr als 205.000 eindeutige Paketnamen, die in keiner Registry existierten. Die Halluzinationsrate lag bei mindestens 5,2 % für kommerzielle Modelle und 21,7 % für Open-Source-Modelle. Eine Nachfolgestudie aus dem Jahr 2026 testete fünf neuere Frontier-Modelle und maß Raten zwischen 4,62 % und 6,10 %, was niedriger ist, aber in jedem getesteten Modell weiterhin vorkommt.

Der Teil, der eine Eigenheit in eine Angriffsfläche verwandelt, ist die Wiederholbarkeit. Als die Forscher identische Prompts erneut ausführten, kam ein großer Teil der halluzinierten Namen jedes Mal wieder. Modelle raten nicht zufällig; sie konvergieren auf dieselben falschen Antworten, weil sie dieselben Muster aus denselben Trainingsdaten gelernt haben. Diese Vorhersagbarkeit ist die Schwachstelle. Ein Angreifer kann dieselben Prompts ausführen, die Namen sammeln, die sich wiederholen, und sie vor allen anderen registrieren.

Die Studie von 2026 identifizierte 127 Paketnamen, die alle fünf getesteten Modelle hervorbrachten, obwohl sie nicht existierten; 53 davon waren nach Anwendung der Registry-Schutzmaßnahmen noch zur Registrierung verfügbar.

Echte Pakete, echte Installationen

Das ist bereits passiert. Anfang 2026 fanden Forscher ein Paket namens react-codeshift, das in 237 GitHub-Repositories referenziert wurde. Der Name vermischt zwei echte Tools, jscodeshift und react-codemod. Es war nie veröffentlicht worden. Ein KI-generierter Skill, der das fiktive Paket enthielt, war kopiert und geforkt worden, sodass sich die Referenz von selbst verbreiten konnte.

Ein Paket namens metro-evaluator auf npm enthielt bösartigen Code in vier Versionen, die im Dezember 2025 veröffentlicht wurden, bevor es fünf Tage später entfernt und durch einen Sicherheits-Platzhalter ersetzt wurde. Die getesteten Modelle hatten diesen Namen zehnmal vorgeschlagen. Ein weiteres, unused-imports, ahmte das echte eslint-plugin-unused-imports nach und sammelte weiterhin Installationen von Entwicklern, deren Assistent sie darauf verwies.

Die größere Operation ist eine Kampagne, die das Sicherheitsunternehmen Koi Security PhantomRaven nennt und die mindestens seit August 2025 aktiv ist. Koi schreibt ihr 126 bösartige npm-Pakete und mehr als 86.000 Downloads zu. Der Trick unterscheidet sich von einem halluzinierten Namen. Die package.json sieht sauber aus, enthält manchmal kaum mehr als eine Logzeile, verweist aber auf eine Abhängigkeit, die unter einer einfachen HTTP-URL gehostet wird, statt auf ein weiteres npm-Paket. Die meisten Scanner folgen keinen rohen URLs, sodass die Payload, die npm-Tokens, GitHub-Anmeldedaten und CI-Geheimnisse erntet, bei der Installation unsichtbar geladen wird. Endor Labs dokumentierte drei weitere Wellen derselben Kampagne zwischen November 2025 und Februar 2026, wodurch 88 weitere Pakete hinzukamen, die über rund 50 Wegwerf-Konten hochgeladen wurden.

Paketregistries blockierten die meisten Namen, aber nicht alle

Es gibt eine gute Nachricht in der Forschung. Paketregistries sind besser darin geworden, die Namen zu blockieren, die Modelle tendenziell erfinden. Sie normalisieren ähnliche Namen, führen Verbotslisten und achten auf die Muster, die in vielen generierten Stichproben auftauchen. Als die Studie von 2026 ihre Liste von 127 geteilten halluzinierten Namen prüfte, waren die meisten bereits von legitimen Projekten und Registry-Abwehrmaßnahmen beansprucht oder blockiert worden.

Das Problem ist, dass „die meisten“ nicht „alle“ sind. Dieselbe Studie fand 53 Namen, die nach Anwendung der Schutzmaßnahmen noch zur Registrierung verfügbar waren. Ein einziger registrierbarer Name, auf den sich mehrere Frontier-Modelle einigen, reicht aus, um einen Angriff darauf aufzubauen, denn der Angreifer muss nur das Modell erraten, nicht den Entwickler. Die Registry-Betreiber haben die meisten Türen geschlossen; die verbleibende Lücke ist schmal, aber offen.

Dasselbe Muster hat sich inzwischen über Paketmanager hinaus ausgebreitet. Sicherheitsforscher haben dokumentiert, dass Angreifer Domains registrieren, die Modelle halluzinieren, sowie Repositories und Skills, die Agenten wahrscheinlich erfinden. Der Mechanismus ist in jedem Fall identisch: Ein Modell sagt einen plausiblen Namen voraus, und ein System, das darauf ausgelegt ist, dieser Vorhersage zu vertrauen, handelt danach. Jede neue Oberfläche, die ein Agent erreichen kann, wird zu einem weiteren Ort, an dem ein Name platziert werden kann, nach dem der Agent greifen wird.

Warum Agenten es schlimmer machen

Ein menschlicher Entwickler bemerkt möglicherweise einen verdächtigen Paketnamen. Ein Agent nicht. Agenten installieren Abhängigkeiten autonom, oft ohne dass ein Mensch den Befehl zuerst liest. Forscher haben Prompt-Injection-Techniken demonstriert, die Agenten dazu bringen, von Angreifern kontrollierte Paketnamen anzufordern, mit berichteten Erfolgsraten von bis zu 100 % bei Tools wie Cursor, Windsurf und GitHub Copilot.

Diese Kombination hat das Risikoprofil verändert. Die Halluzination liefert den Namen. Der Agent liefert die Ausführung. Der Angreifer muss nur warten, bis die beiden aufeinandertreffen.

Das Leck-Problem ist dasselbe Problem

Ein verwandter Bericht des Unternehmens Glow fand heraus, dass Agenten mehr als 13.000 interne Bilder auf GitHub offenlegten, die aus über 300 Organisationen stammten. Der Mechanismus ist banal: Agenten und ihre Nutzer legen Screenshots, Diagramme und Dokumente in öffentlichen Repositories ab, manchmal ohne zu verstehen, dass „öffentlich“ durchsuchbar und dauerhaft bedeutet. Dieselben Tools, die Entwickler schneller machen, erleichtern es auch, internes Material dorthin zu verschieben, wo es nicht hingehört.

Beide Probleme haben eine gemeinsame Ursache. Agenten handeln mit Maschinengeschwindigkeit auf Anweisungen, die falsch (ein halluzinierter Name) oder sensibel (ein interner Screenshot) sein können. Der menschliche Kontrollpunkt, der früher zwischen Absicht und Handlung stand, ist genau das, was der Agent entfernt.

Was tatsächlich zu tun ist

Die Abwehrmaßnahmen sind nicht kompliziert, was angesichts der Geschwindigkeit, mit der sich die Bedrohung entwickelt hat, eine gute Nachricht ist.

Behandeln Sie jeden Installationsbefehl, den ein Agent erzeugt, als nicht vertrauenswürdige Eingabe. Prüfen Sie, ob das Paket existiert, bevor Sie es installieren. Prüfen Sie, wie alt es ist; ein halluzinierter Name, der registriert wurde, wird jung sein. Prüfen Sie, ob der Herausgeber eine Historie hat. Für npm und PyPI beantwortet ein schneller Metadaten-Lookup alle drei Fragen in Sekunden.

Verlangen Sie menschliche Genehmigung, bevor ein Agent eine Abhängigkeit hinzufügt. Das ist die einzelne Maßnahme mit dem höchsten Wert, denn sie fängt die halluzinierten Namen, die bösartigen Registrierungen und die per Prompt-Injection eingeschleusten Anfragen auf einmal ab. Sie verlangsamt den Agenten ein wenig und schließt das größte Loch.

Halten Sie die Reichweite des Agenten klein. Ein Coding-Agent benötigt Repository-Zugriff; er braucht selten Produktions-Anmeldedaten und sollte keinen Paketmanager ohne Prüfung auf eine private Registry zeigen lassen. Tools wie Socket und Snyk können den Registry-Lookup innerhalb der IDE oder der CI-Pipeline automatisieren, was die Kosten wert ist, sobald ein Team Agenten über viele Repositories hinweg einsetzt.

Der unangenehme Teil ist, dass nichts davon ein Bug ist, der gepatcht wird. Halluzination ist fester Bestandteil der Art und Weise, wie diese Modelle Text vorhersagen: Sie erzeugen den nächsten plausiblen Namen, keinen verifizierten. Die Lösung muss im Workflow rund um das Modell liegen, und das ist ein Prozess, den die meisten Teams diese Woche starten können.