Die Paperclip KI-Sicherheitslücken zeigen, wie eng „Agentenkonfiguration“ mit ausführbarem Verhalten verknüpft sein kann. In den gemeldeten Fällen können Angreifer mithilfe bösartiger Agent-Imports Befehle auf einem Netzwerkserver oder auf einem lokalen Entwickler-System starten. Zusätzlich werden API-Routen beschrieben, die nicht durchgängig die erwarteten Zugriffskontrollen durchsetzen.
Für Betreiber ist vor allem die Frage entscheidend, wie Paperclip in ihrer Umgebung registriert und bereitgestellt wird. Die gute Nachricht: Es gibt einen klar benannten Upgrade-Punkt—aber je nach Deployment-Modell greifen unterschiedliche Schutzmechanismen.
Warum Paperclip Angriffe überhaupt möglich macht
Paperclip ist eine Open-Source-„Control Plane“ für Teams von KI-Agenten. Ein zentrales Prinzip zieht sich durch die Berichte: Bestimmte Abläufe stützen sich darauf, einen Agenten zu importieren und danach zu starten. Genau diese Kette kann missbraucht werden, wenn unzuverlässige Konfigurationen die falsche Stelle erreichen.
Laut Analyse lässt sich eine Eigenschaft des Systems so zusammenfassen: Agent-Konfiguration muss wie ausführbares Input behandelt werden. Das ist an sich nicht falsch, denn „Befehl ausführen“ ist ein legitimes Feature. Die Lücken liegen vielmehr darin, wer diese Konfiguration einbringen kann und welcher Vertrauenskontext sie anschließend akzeptiert.
CVE-2026-41679: Befehle per bösartigem Agent-Import (Serverpfad)
Der schwerwiegendere Pfad wird mit CVE-2026-41679 adressiert und erhält eine CVSS-Bewertung von 10.0. Er betrifft insbesondere Netzwerk-zugängliche Deployments in einem Modus, der den beschriebenen „authenticated“-Rahmen nutzt, und erfordert keine bestehende Vorab-Anmeldung oder eine Interaktion des Opfers.
Der Ablauf beginnt dem Bericht zufolge mit Paperclips Standard-Registrierung: Eine Registrierung kann ohne Einladung oder verifizierte E-Mail erfolgen. Ein Angreifer kann sich anmelden, in die CLI-Autorisierungsroutine gelangen und dort eine Genehmigungskette anstoßen. Entscheidend ist: Dieselbe neu angelegte Identität kann eine „pending CLI challenge“ genehmigen, wodurch eine dauerhafte Board-API-Referenz entsteht—ohne dass ein separater Instanzadministrator zustimmen muss.
Damit kann der Angreifer einen Import so präparieren, dass er eine neue Company definiert und einen Agent enthält, der einen Prozessadapter nutzt. Der Import beinhaltet außerdem den konkreten Befehl, der ausgeführt werden soll. Weil der Import den Angreifer als Mitglied der neuen Company macht, besteht anschließend die normale „wakeup“-Prüfung.
Am Ende startet Paperclip den Befehl als Child Process mit den Betriebssystemrechten des Serverprozesses. Welche Auswirkung das in der Praxis hat, hängt vom Dienstkonto und vom Host ab—möglich sind unter anderem Anwendungsdaten, Quell-Repositories, lokale gespeicherte Credentials, Geheimnisse, die Agentenprozesse sehen könnten, sowie interne Dienste, die vom betroffenen Rechner erreichbar sind.
Wie Paperclip den Serverpfad gefixt hat
Als Fix wird Paperclip v2026.416.0 oder später genannt. Laut Bericht verlangt die Lösung bei Importen, die auf eine neue Company zielen, nun Instance-Administratorrechte. Zielt der Import auf eine bestehende Company, braucht er entsprechend Company-Zugriff. Diese Prüfung schützt demnach sowohl Import-Vorschau als auch den eigentlichen Ausführungsweg.
Open-Registration bleibt verfügbar. Der Unterschied ist: Eine frisch registrierte „Board“-Rolle kann den Import-Umweg für neue Companies nicht mehr als Instanzadministrationshandlung missbrauchen.
GHSA-x8hx-rhr2-9rf7: Localhost-Commands über DNS-Rebinding
Ein weiterer kritischer Pfad wird mit GHSA-x8hx-rhr2-9rf7 beschrieben (CVSS 9.6). Hier ist kein Netzwerkserver mit Standardregistrierung nötig, sondern ein anderes Deployment-Modell: der Default-local_trusted-Modus.
In diesem Modus bindet Paperclip an die Loopback-Schnittstelle. In der Historie wurde dabei vereinfacht „jede Anfrage als implizit instanzadministrativ“ behandelt. Das reduziert Reibung im lokalen Entwicklungsbetrieb, führt aber dazu, dass die „Netzwerkposition“ (Localhost) als Identitätsersatz wirkt.
Oasis beschreibt einen DNS-Rebinding-Ansatz: Eine Angreifer-Domain wird so konfiguriert, dass sie zunächst zum Angreiferserver auflöst und später auf 127.0.0.1 zurückspringt. Der Browser lädt zunächst JavaScript vom Angreifer—danach bleiben spätere Requests unter derselben Host-Identität beim lokalen Paperclip-Service. Weil die Requests weiterhin als same-origin gelten, akzeptiert Paperclip den Host im Host-Header.
Von dort aus kann die Seite die Import-API aufrufen, eine Company installieren, einen Prozess-basierten Agenten importieren und anschließend dessen Wakeup-Endpunkt triggern. Da local mode die Administratorrolle auf diese Art von Request-Gruppierung abbildet, läuft der Befehl mit den Entwickler-Rechten.
Wichtig: Der Bericht nennt ein verifiziertes Proof-of-Concept unter macOS mit Firefox. Gleichzeitig wird nicht behauptet, dass das Ende-zu-Ende-Ergebnis identisch auf allen Browsern und Systemen belegt ist.
Der direkte Fix: Hostname-Validierung
Die Korrektur besteht im Kern in einer Hostname-Validierung. Für private Deployments wird in v2026.416.0 ein „private-hostname guard“ aktiviert—und zwar unabhängig davon, ob die Umgebung im local_trusted oder im authenticated-Modus läuft. Der Guard läuft demnach vor dem Middleware-Schritt, der eine Identität für die Anfrage zuordnet. So werden Rebinding-Requests mit nicht genehmigtem Host bereits verworfen, bevor sie in die API gelangen.
API-Routen ohne ausreichend saubere Zugriffskontrollen
Zusätzlich zu den beiden Ausführungswegen wird eine weitere Schwachstellenkategorie berichtet: GHSA-xfqj-r5qw-8g4j mit einer CVSS-Bewertung von 8.3. Hier geht es um mehrere API-Routen im authentifizierten Modus, die nicht konsistent unauthentifizierte oder bereichsübergreifende (cross-company) Requests ablehnen.
Ein beschriebenes Szenario betrifft einen Aufrufer mit gültiger „heartbeat-run“ Kennung: Dabei kann er zugehörige Issue-Daten abrufen, ohne nachzuweisen, dass er Zugriff auf die betroffene Company hat. Das ist keine „voll offene“ Enumeration, weil ein valider Run-Identifier dennoch vorhanden oder entdeckbar sein muss.
Andere Routen geben Informationen preis, darunter agentenbezogene Skill-Dokumentation inklusive API-Pfade und Authentifizierungs-Konventionen. Außerdem werden Health-Infos genannt—zum Beispiel Deployment-Modus, Version, Authentifizierungsbereitschaft, Bootstrap-Status, Exposition sowie Feature-Flags. Auch eine Route für eine unauthenticated CLI-Challenge wird als Baustein in der Credential-Erzeugungskette im Kontext von CVE-2026-41679 erwähnt.
Wie Paperclip das Risiko reduziert hat
Als Grundproblem wird genannt, dass eine unauthentifizierte Anfrage eine Middleware passieren kann, die eine Identität mit „no actor“ zuweist. Danach muss jede Route selbst ihre Autorisierungsannahmen sauber durchsetzen. In der Fix-Version fügt Paperclip demnach Authentifizierung zu allgemeinen Skill-Routen hinzu, ergänzt Company-Checks bei der Heartbeat-Issue-Abfrage, macht Invite-Scoped Onboarding korrekt und reduziert die Health-Antwort für unauthentifizierte Nutzer.
Über alle drei Befunde hinweg wird das Muster klar: Paperclip hat in bestimmten Pfaden ein Credential, eine Route oder eine Netzwerkposition vertraut, ohne die später zwingend erforderliche Kontrolle zuverlässig anzuwenden. Konkret: Selbstgenehmigte Credentials, fehlende Route-Checks und zu weit gefasste Trust-Annahmen für localhost.
Welche Version sollten Betreiber installieren?
Beim Abgleich der Versionen gibt es im Bericht einen möglichen Stolperpunkt: Paperclip verwendet zwei Versionstypen für denselben Tag. In der GitHub Security Release wird v2026.416.0 genannt, während in den Server- und CLI-Manifeste innerhalb dieses Tags als Version 0.3.1 erscheint.
Das wird als Erklärungsansatz dafür gesehen, warum Advisories sowohl 0.3.1 als auch 2026.416.0 referenzieren. Der Bericht hält zudem fest, dass eine DNS-Rebinding-bezogene Advisory weiterhin keinen eindeutigen Eintrag mit einer gepatchten Version nennt.
Bei einer Sichtung des getaggten Quellstands von v2026.416.0 wurde jedoch beschrieben, dass der Hostname-Guard für private local_trusted-Deployments aktiv ist. Außerdem soll derselbe Tag neue-company-Importe nur noch mit Instance-Administratorrechten erlauben und process- sowie HTTP-Adapter in einem „agent-safe“-Importpfad blockieren.
Da die Informationsstände in den Datensätzen nicht vollständig zusammenpassen, lautet die praktische Empfehlung im Bericht: Upgrade auf v2026.416.0 oder später—statt sich auf ältere Metadaten zu verlassen. Die Veröffentlichungstexte von Paperclip raten ebenfalls zu einem Upgrade, und die Analyse von Oasis betont v2026.416.0 oder höher als sichere Basis.
Aktueller Stand zur Ausnutzung in der Praxis
Zum Zeitpunkt der Prüfung (5. August 2026) gibt es laut Bericht keine Angaben eines autoritativen Fundes, die eine Ausnutzung „in the wild“ bestätigen. Dennoch wird betont: Das Fehlen eines Eintrags im Known Exploited Vulnerabilities-Katalog schließt eine Ausnutzung nicht aus.
Darüber hinaus soll Rapid7 inzwischen ein öffentliches Metasploit-Modul veröffentlicht haben, das den Angriffskettenablauf für CVE-2026-41679 automatisiert. Die CISA-Enrichment-Daten, die auch über NVD bereitgestellt werden, stufen die Ausnutzung laut Bericht als „proof-of-concept“ ein—mit entsprechendem technischen Impact.
Checkliste: So reagieren Sie auf die Paperclip KI-Sicherheitslücken
- Aktualisieren Sie auf Paperclip v2026.416.0 oder später—besonders wenn Ihre Umgebung Netzwerkzugriff oder default-Authentifizierungs-/Localhost-Logik nutzt.
- Überprüfen Sie Ihre Registrierung: Open-Registration bleibt möglich, aber die Rechtevergabe bei Importen wurde nun verschärft.
- Bewerten Sie lokale Deployments: Wenn local_trusted verwendet wird, ist die Hostname-Validierung zentral.
- Prüfen Sie API-Zugriffsregeln: Routenbezogene Checks sollten so gesetzt sein, dass cross-company oder unauthenticated Requests konsequent abgewehrt werden.
- Konfigurieren Sie Agent-Inputs mit Bedacht: Wenn Agent-Konfiguration als ausführbares Input betrachtet werden muss, sollte sie nur dort akzeptiert werden, wo Autorisierung wirklich passt.
Fazit
Die Paperclip KI-Sicherheitslücken machen deutlich, dass nicht die reine Existenz von „Befehl ausführen“ das Risiko ist, sondern die Autorisierungslücke davor: Wer importieren darf, welcher Kontext eine Konfiguration akzeptiert und welche Prüfungen vor der Ausführung greifen. Für Betreiber ist daher das Upgrade auf v2026.416.0 oder neuer der wichtigste Schritt—ergänzt durch eine genaue Prüfung der eigenen Registrierungs- und Deployment-Einstellungen.
Quelle: https://thehackernews.com/2026/08/paperclip-ai-flaws-let-attackers-run.html
