Die Paperclip Sicherheitslücke (CVE-2026-41679) war so kritisch, dass sie unter bestimmten Standardkonfigurationen mehr als nur einzelne Funktionen betraf: Eine fehlende Autorisierungsprüfung konnte Angreifern den Weg zu weitreichendem Zugriff eröffnen. In der Folge waren sogar Szenarien möglich, in denen Code mit den Berechtigungen des Paperclip-Servers ausgeführt wurde.
Paperclip ist eine KI-Managementplattform, mit der Organisationen KI-Agenten automatisiert und im großen Maßstab betreiben können. Dazu zählt auch das Importieren von Unternehmen aus sogenannten Portable Bundles sowie das Einspielen von YAML-Dateien, die Agenten und die auszuführenden Befehle beschreiben.
Warum die Paperclip Sicherheitslücke so gefährlich war
Oasis Security beschreibt einen Authorization Bypass, der es remote angreifenden Akteuren erlauben konnte, mithilfe der Server-Berechtigungen beliebigen Code auszuführen. Der Kernpunkt war, dass eine Autorisierungsprüfung fehlte, die eigentlich verhindern sollte, dass unbefugte Nutzer sicherheitsrelevante Schritte auslösen.
Die Schwachstelle wurde als kritisch eingestuft (CVSS 10) und betraf network-zugängliche Paperclip-Instanzen. Besonders relevant waren dabei Setups mit einem Standardmodus für authentifizierte Nutzung.
So lief der Angriff praktisch ab
Die technische Analyse zeigt, dass der Angriff ohne Einladung oder Kontrolle einer verifizierten E-Mail-Adresse starten konnte. Stattdessen war es möglich, sich selbst zu registrieren, direkt einzuloggen und anschließend in den CLI-Autorisierungsprozess einzusteigen.
Dabei wird ein Challenge-and-Approval-Mechanismus genutzt, um einen CLI-Client zu autorisieren und eine persistent genutzte API-Berechtigung zu aktivieren. Der entscheidende Fehler bestand darin, dass eine unberechtigte Sitzung diesen Ablauf durchlaufen konnte, obwohl die Autorisierung dafür eigentlich an strengere Kontrollen gebunden sein sollte.
Im Detail bedeutete das:
- Angreifer konnten ein Konto ohne E-Mail-Verifikation selbst anlegen und sich sofort anmelden.
- Die Sitzung reichte aus, um den CLI-Autorisierungsflow zu durchlaufen.
- Nach dem erfolgreichen Freigeben der CLI-Challenge erhielt der Angreifer einen Token, der board-level Zugriff ermöglichte.
- Damit konnte er anschließend Routen erreichen, die für das Importieren von Unternehmen vorgesehen sind.
Importwege: Board-Zugriff statt Adminrechte
Oasis Security hebt einen wichtigen Designunterschied hervor: Paperclip schränkte zwar das direkte Erstellen einer neuen Company auf Instanzadministratoren ein. Gleichzeitig gab es aber einen äquivalenten Importpfad, der offenbar nur board-level Zugriff überprüfte und nicht erneut die strengeren Instanz-Admin-Berechtigungen verlangte.
Diese Kombination wirkte wie ein Sicherheitsleck in zwei Stufen: Zuerst wurde die Autorisierung für den CLI-Prozess erlangt, danach reichte der resultierende Token, um über den Importmechanismus weitere Aktionen anzustoßen.
Aus YAML wurde Ausführung: Crafted Import-Definitionen
Sobald der Angreifer den Importweg nutzen konnte, spielte er eine speziell präparierte Konfiguration ein. Im Bericht wird ein manipuliertes .paperclip.yaml-Szenario beschrieben, mit dem sich ein Agent konfigurieren ließ, der über einen sogenannten Host-Level-Execution-Adapter Befehle ausführt.
Der Clou: Der definierte Adapter sollte einen Befehl ausführen lassen, der unter dem Prozesskontext des Paperclip-Servers lief. Wenn die Ausnutzung gelang, erhielt der Angreifer damit die Rechte des Service-Accounts, unter dem Paperclip betrieben wurde.
Je nach Deployment konnte das weitreichend sein. Möglich waren laut Oasis unter anderem:
- Zugriff auf Anwendungsdaten
- Rechte auf Source-Repositories
- Erreichbarkeit lokaler Credentials
- Secrets, die für Prozesse von Agenten verfügbar waren
- Zugriff auf interne Dienste, die vom Host aus erreichbar waren
Welche Änderungen behebt die Lösung
Paperclip hat die Schwachstelle behoben, indem Autorisierungsprüfungen auf zwei zentrale Stellen angewendet wurden: den import preview sowie die import execution-Abläufe. Zusätzlich wurde das Scoping von Companies enger gefasst, sodass die Rechteverteilung klarer kontrolliert wird.
Damit sollte insbesondere verhindert werden, dass ein Angreifer nach dem Erlangen eines Tokens über den CLI-Flow weiter in Importfunktionen vordringt, ohne die vorgesehenen Instanz-Admin-Rechte zu besitzen.
Weitere Schwächen: Datenleck und DNS-Rebinding
Die Analyse von Oasis ging über die Hauptlücke hinaus. Laut Bericht wurden zwei weitere Probleme identifiziert:
1) Fehlende Autorisierung in API-Routen
Eine weitere Schwachstelle betraf API-Routen, bei denen offenbar eine Autorisierungsprüfung fehlte. Das konnte zu einer Offenlegung sensibler Daten führen.
2) DNS-Rebinding auf Loopback in Entwicklermodus
Zusätzlich gab es eine Schwäche durch DNS-Rebinding auf Loopback. Im Local-Development Mode bindete Paperclip in der Regel an 127.0.0.1 und vertraute offenbar allen Requests, die an diese Adresse gerichtet waren, als kämen sie aus einer vertrauenswürdigen Software.
Wenn ein Entwickler eine Website aufrief, die durch einen Angreifer kontrolliert werden konnte, konnte JavaScript auf dieser Seite Same-Origin-Schutzmechanismen umgehen. Das Ergebnis: Zugriff auf die lokale Paperclip-API wurde möglich.
Über eine Importoperation konnte der Angreifer anschließend erreichen, dass Paperclip auf dem Rechner des Entwicklers einen Befehl ausführt.
Einordnung: Warum KI-Agenten neue Identitäten schaffen
Oasis stellt in diesem Zusammenhang eine weitergehende Sicherheitsfrage: AI agents werden zu einer neuen Klasse von Unternehmensidentitäten. Bei agentic Workflows verteilt sich der Ablauf über mehrere Schritte: Ein Nutzer delegiert eine Absicht an einen Agenten, der wiederum andere Agenten oder Tools anstößt. In jedem Schritt kann eine andere Berechtigung zum Einsatz kommen.
Das macht Angriffe schwer nachzuvollziehen. Wenn eine Aktion schließlich auf einem Zielsystem landet, zeigt der Log häufig nur das finale Credential. Dadurch verschwimmen Spuren darüber, welcher Nutzer die Intention gestartet hat, welcher Agent verantwortlich war oder welche Aufgabe ursprünglich geplant war.
Was Betreiber jetzt tun sollten
Wenn Sie Paperclip einsetzen, lohnt sich eine rasche Überprüfung Ihres Deployments. Konzentrieren Sie sich dabei besonders auf Instanzen, die aus dem Netzwerk erreichbar sind, sowie auf Konfigurationen, die dem beschriebenen Authentifizierungsmodell ähneln.
Praktisch bedeutet das: Halten Sie die Plattform auf dem neuesten Stand, prüfen Sie ob die von Oasis beschriebenen Import- und Autorisierungsbereiche bereits adressiert wurden und kontrollieren Sie, wer Zugriff auf CLI-Freigaben, Board-Token und Importfunktionen besitzt. Für Entwicklerumgebungen ist zudem wichtig, ob der Local-Development Mode abgesichert ist und ob externe Inhalte Zugriff auf lokale Services verhindern.
Fazit
Die Paperclip Sicherheitslücke zeigte, wie schnell ein fehlender Autorisierungscheck in eine Kette aus Umgehung, Token-Erzeugung und gefährlichen Importpfaden kippen kann. In bestimmten Standardkonfigurationen reichte das Setup offenbar aus, um Codeausführung mit den Rechten des Paperclip-Servers zu ermöglichen.
Mit den vorgenommenen Fixes – Autorisierungsprüfungen für Importabläufe und engeres Company-Scoping – will Paperclip genau diese Angriffskette unterbrechen. Gleichzeitig verdeutlichen die zusätzlich gemeldeten Probleme, dass auch API-Zugriffe und lokale Entwicklungsmodi in KI-gestützten Systemen besonders sorgfältig abgesichert werden müssen.
Quelle: https://www.securityweek.com/critical-paperclip-flaw-allowed-admin-access-code-execution/
