Der Agent-Stack hat ein 1998-Problem

In der letzten Juniwoche 2026 traf eine kleine Häufung von CVEs die Werkzeuge für KI-Agenten, zwei davon im selben Desktop-Agent-Client, beide Autorisierungsfehler, einer davon direkt in einem MCP-OAuth-Callback. Für sich genommen ist jeder einzelne ein Bug mittleren Schweregrads, den ein Maintainer an einem Wochenende patcht. Zusammen gelesen ist die Häufung ein Signal, und das Signal ist struktureller Natur: Das KI-Agenten-Ökosystem sammelt Angriffsfläche schneller an, als es die Sicherheitskultur ansammelt, um sich zu verteidigen. Das ist kein moralisches Versagen eines einzelnen Projekts. Es ist genau der Zustand, in dem sich das Web um 1998 befand, als eine Sprache mit unsicheren Standardeinstellungen den Mainstream erreichte, Zugangsdaten überall herumlagen und die installierte Basis schneller wuchs, als irgendjemand sie härten konnte. Die Werkzeuge, die Ihre Schlüssel verwahren und Ihre Shell ausführen, werden mit dem Sicherheitsreifegrad von 1998 in ein Bedrohungsmodell von 2026 ausgeliefert. {.answer-block}

TL;DR

• Cherry Studio, ein beliebter Desktop-Client für KI-Agenten, handelte sich am 29. Juni 2026 zwei CVEs ein: einen Fehler bei der Autorisierung in seinem MCP-OAuth-Callback-Server (CVE-2026-13524) und eine Umgehung der Autorisierung in einer Preload-API (CVE-2026-13534).¹²
• Das Muster beschränkt sich nicht auf eine einzelne App. Die MCP-Referenzwerkzeuge selbst lieferten 2025 kritische Schwachstellen für Remote-Code-Execution aus: mcp-remote mit CVSS 9,6 (CVE-2025-6514) und Anthropics MCP Inspector mit CVSS 9,4 (CVE-2025-49596).³⁴
• Agent-Tools sind strukturell stärker exponiert, als es Webanwendungen je waren: Sie verwahren Zugangsdaten, führen Code von Haus aus aus und sitzen innerhalb Ihrer Vertrauensgrenzen (IDE, Shell, Browser) statt dahinter.
• Das Wissen, um diese Fehler zu verhindern, existiert bereits. Die MCP-Spezifikation dokumentiert die Angriffsklassen Confused Deputy und OAuth-Flow im Detail; die Kultur, es bei jeder schnelllebigen Integration anzuwenden, verbreitet sich noch nicht.⁵
• Das Web von 1998 reifte erst, nachdem Würmer Unsicherheit teuer machten. Das Agenten-Ökosystem hat noch keine entsprechende erzwingende Kraft, und dieselben Modelle, die diese Fehler heute finden, können denjenigen schreiben, der genau dazu wird.

Die Häufung, konkret

Cherry Studio ist ein plattformübergreifender Desktop-Client, der sich selbst als „AI productivity studio with smart chat, autonomous agents, and 300+ assistants” vermarktet, mit ausdrücklicher Unterstützung für Model-Context-Protocol-Server. Es ist genau die Art von Werkzeug, um die es in diesem Essay geht: ein endnutzerorientierter Agent, der Ihre API-Schlüssel vermittelt, lokale Integrationen ausführt und in Ihrem Namen ins Netzwerk hinausgreift.

Am 29. Juni 2026 veröffentlichte VulDB zwei Advisories dagegen. CVE-2026-13524 ist ein Fehler bei der Autorisierung (CWE-285) im MCP OAuth Local Callback Server, in src/main/services/mcp/oauth/callback.ts, über die Versionen 1.9.0 bis 1.9.6 hinweg. Die Beschreibung ist unmissverständlich: „Die Manipulation des Arguments code führt zu unzureichender Autorisierung.” Er wird nach CVSS 3.1 mit 5,6 bewertet, mittel.¹ CVE-2026-13534 ist eine Umgehung der Autorisierung (CWE-639) in der CherryIN-Preload-API, bis Version 1.9.7, mit einer Bewertung von 5,0.² Keiner ist eine Schlagzeile. Beide sind der stille Autorisierungsfehler, den ein Team macht, wenn es sich schnell über eine für alle neue Fläche bewegt.

Der erste ist das verräterische Zeichen. Ein OAuth-Callback in einem MCP-Client ist eine Vertrauensgrenze wie aus dem Lehrbuch: der Punkt, an dem ein externer Autorisierungsserver einen Code an Ihre Maschine zurückgibt und Ihre Maschine entscheidet, ob sie ihm vertraut. Ihn falsch zu handhaben ist keine exotische neue Fehlerklasse. Es ist genau jene, der das eigene Sicherheitsdokument der MCP-Spezifikation die meiste Tinte widmet.

Ich habe zwei benachbarte CVEs aus demselben Zeitfenster verworfen, weil die Häufung echt sein muss: CVE-2026-13533 betrifft agentejo Cockpit CMS, ein PHP-Content-Management-System statt eines Agenten-Frameworks, und CVE-2026-13543 ließ sich überhaupt nicht verifizieren. Ein paar solide Beispiele schlagen eine aufgeblähte Liste.

Warum Agent-Tools strukturell schlechter dastehen

Eine klassische Webanwendung um 1998 war unsicher, aber sie lebte hinter einer Grenze. Sie lief auf einem Server, in dem Sie nicht saßen, ihr Schadensradius war die Datenbank und die Sitzung, und ein Einbruch verschaffte dem Angreifer die Daten der Anwendung.

Ein Agent-Tool kehrt diese Geometrie um. Es läuft auf Ihrer Maschine oder in Ihrer IDE, verwahrt langlebige Zugangsdaten zu Ihrer Cloud und Ihren Repos und führt Code als Kernfunktion aus, nicht als Exploit. Es gibt keine Grenze, hinter der man sitzen könnte, denn das Werkzeug ist die Grenze, und sie ist von Natur aus durchlässig.

Simon Willison benannte die Gefahr im Juni 2025 präzise mit der „lethal trifecta” (der tödlichen Dreiheit): Ein Agent wird ausnutzbar, wenn er den „Zugriff auf Ihre privaten Daten”, den „Kontakt mit nicht vertrauenswürdigen Inhalten” und die „Fähigkeit zur externen Kommunikation” so vereint, dass diese Daten gestohlen werden können.⁷ Jeder leistungsfähige Agent besitzt standardmäßig alle drei, denn Ihre Geheimnisse zu lesen, von Angreifern beeinflusste Inhalte aufzunehmen und ausgehende Anfragen zu stellen sind seine Funktionen, nicht seine Fehler. Die Trifecta ist kein Randfall. Sie ist die Grundkonfiguration.

Das ist der strukturelle Unterschied. Die Webanwendung von 1998 musste dazu gebracht werden, die Daten hinter einer einzigen Grenze preiszugeben. Der Agent von 2026 kommt bereits mit jeder Fähigkeit verdrahtet, die eine Exfiltrationskette benötigt, und das Einzige, was zwischen einer bösartigen Eingabe und Ihren Zugangsdaten steht, ist die Frage, ob das Werkzeug seine internen Vertrauensgrenzen richtig gezogen hat. Der Callback-Bug von Cherry Studio ist das, was man sieht, wenn eine dieser Grenzen ein wenig falsch gezogen wird.

Die MCP-Verstärkung

Model Context Protocol ist das Bindegewebe des Agent-Stacks von 2026, und es vervielfacht die Angriffsfläche auf eine ganz bestimmte Weise: Jeder MCP-Server ist eine neue privilegierte Integration, meist schnell geschrieben, die das Modell aufrufen kann. Eine hinzuzufügen ist reibungslos. Eine zu prüfen ist es nicht. Die installierte Basis an Integrationen überholt die Zahl der Menschen, die deren Code lesen.

Die Referenzwerkzeuge zeigen, dass dies kein Problem von Hobbyprojekten ist. Im Juli 2025 machte JFrog CVE-2025-6514 öffentlich, eine OS-Command-Injection in mcp-remote, einem Connector, der von Claude Desktop, Cursor und Windsurf verwendet wird und den ein bösartiger Server mit einer präparierten authorization_endpoint-URL während des OAuth-Flows auslöst: kritisch, CVSS 9,6.³ Im selben Monat machte Tenable CVE-2025-49596 öffentlich, eine Schwachstelle für Remote-Code-Execution mit dem Wert 9,4 in Anthropics eigenem MCP Inspector, bei der eine fehlende Authentifizierungsprüfung es einer bösartigen Website erlaubte, einen lokalen Port zu erreichen und über DNS-Rebinding beliebige Befehle auszuführen.⁴

Zwei der vier CVEs in diesem Essay sind OAuth-Flow-Fehler in MCP-Werkzeugen: einer im Callback-Server, einer in der Endpoint-Discovery. Das ist kein Zufall. OAuth in einem Agent-Client ist eine immer wieder verpatzte Grenze, und die Spezifikation sagt es laut und deutlich. Das MCP-Dokument zu Security-Best-Practices vom 18. Juni 2025 widmet seinen längsten Abschnitt dem „Confused-Deputy-Problem” und schreibt vor, dass Proxy-Server eine Einwilligung pro Client umsetzen, den OAuth-Parameter state validieren und Redirect-URIs exakt abgleichen.⁵ Das wurde ein Jahr veröffentlicht, bevor Cherry Studio seinen Callback-Bug auslieferte. Die Lücke ist nicht das Wissen. Es ist der Abstand zwischen dem Sicherheitsanhang einer Spezifikation und der durchschnittlichen Integration, die letzten Dienstag geschrieben wurde.

Prompt Injection macht die Verstärkung qualitativ schlimmer als alles, womit das alte Web konfrontiert war. Willison prägte den Begriff im September 2022, als er schrieb: „I propose that the obvious name for this should be prompt injection”, in Analogie zur SQL-Injection: vertrauenswürdige Anweisungen und nicht vertrauenswürdige Eingaben, verkettet zu einer einzigen Zeichenkette, die eine Engine anschließend interpretiert.⁶ Für einen Agenten sind Daten ein Vektor, nicht nur Code. Eine vergiftete Webseite, eine mit einer Falle versehene Datei, eine feindselige Tool-Beschreibung: Jedes Byte, das das Modell liest, kann eine Anweisung tragen. Die MCP-Spezifikation ist dabei unverblümt und warnt, dass ein bösartiger Server den Client in einen Proxy für Datenexfiltration verwandeln kann.⁵ Das lässt sich nicht durch Escaping der Eingaben beheben, denn die Eingabe ist natürliche Sprache und der Interpreter ist ein Modell.

Die 1998-Analogie, präzise gemacht

Die Analogie muss den Faktencheck überstehen, sonst ist sie nur eine Stimmung, also hier die Ära, korrekt dargestellt.

PHP 3 erschien im Juni 1998 und legte Millionen Menschen eine dynamische Websprache in die Hände, mit einer Standardeinstellung, die heute waghalsig anmutet: Externe Eingaben, aus dem Query-String, aus Cookies oder vom Server, wurden direkt in den globalen Scope registriert. register_globals war eingeschaltet, und eine Variable, die ein Angreifer kontrollierte, konnte klammheimlich zu einer werden, der Ihr Code vertraute. Die Behebung dauerte vier Jahre. PHP 4.2.0, veröffentlicht im April 2002, änderte die Standardeinstellung, und die Release-Ankündigung stellt es nüchtern fest: „Externe Variablen (aus der Umgebung, der HTTP-Anfrage, aus Cookies oder dem Webserver) werden standardmäßig nicht mehr im globalen Scope registriert.”⁸ Die andere epochenprägende Krücke, magic quotes, führte addslashes aus, um Schutz vor SQL-Injection vorzutäuschen, ohne die Substanz, und überlebte register_globals um Jahre, bevor das Projekt sie schließlich abschaffte. Unsichere Standardeinstellungen, eine Illusion von Sicherheit, ein mehrjähriger Rückstand, bevor die Kultur aufholte. Das war die Anwendungsschicht des jungen Webs.

Die Kultur kam nicht von allein. Sie wurde erzwungen. Am 19. Juli 2001 nutzte der Wurm Code Red einen Buffer Overflow in Microsofts IIS-Webserver aus, und nach der Zählung von CAIDA wurden „mehr als 359.000 Computer in weniger als 14 Stunden mit dem Wurm Code-Red (CRv2) infiziert”.⁹ Am 25. Januar 2003 traf der Wurm Sapphire/Slammer einen Buffer Overflow in Microsoft SQL Server, packte sich in 376-Byte-Pakete und „infizierte die meisten der auffindbaren verwundbaren Hosts innerhalb von zehn Minuten” — der sich bis dahin am schnellsten verbreitende Wurm der Geschichte.¹⁰ Das waren Infrastruktur-Würmer, keine PHP-Bugs, und ich werde sie nicht vermengen. Der Punkt ist die Gestalt des Jahrzehnts: unsichere Standardeinstellungen auf jeder Schicht und eine Sicherheitskultur, die erst reifte, nachdem Unsicherheit spürbar und öffentlich teuer wurde. Secure-by-default war eine Lektion, die die Branche mit Würmern bezahlte.

Überträgt man das auf 2026, ist die Entsprechung unbequem. Unsichere Standardeinstellungen: Agent-Clients, die Callback-Codes vertrauen und Einwilligungsprüfungen überspringen. Die Illusion von Sicherheit: eine Berechtigungsabfrage über einem Token mit dem Scope admin:*. Die explodierende installierte Basis: ein MCP-Server für alles, mit einem Klick hinzugefügt, von niemandem geprüft. Was dem Ökosystem noch fehlt, ist der Wurm. Es hat die Standardeinstellungen von 1998 und das Zielprofil von 2001, und es wartet auf seine erzwingende Kraft.

Die Haltung des Betreibers

Sie können nicht auf die Kultur warten. Sie betreiben diese Werkzeuge jetzt, also ziehen Sie die Grenzen, die das Ökosystem noch nicht für Sie gezogen hat. Der Rahmen, den ich verwende, ist die Trifecta als operative Checkliste: Fragen Sie bei jedem Agenten, was er lesen darf, was er ausführen darf und was er exfiltrieren darf, und setzen Sie auf jedes eine deterministische Schutzvorrichtung.

Die Spalte mit den Schutzvorrichtungen ist nicht bloß ein Wunsch. Sie ist deterministisch, und die Determiniertheit ist der springende Punkt. Hooks werden bei Lebenszyklus-Ereignissen ausgelöst, mit Exit-Codes, gegen die das Modell nicht argumentieren kann, und Berechtigungsregeln greifen, bevor ein Tool läuft, nicht danach. Das ist die Schicht, auf der aus „der Agent sollte X nicht tun” ein „der Agent kann X nicht tun” wird, und es ist die einzige Schicht, an der sich ein Prompt-Injection-Payload nicht vorbeireden kann. Wenn Sie der Eingabe nicht vertrauen können und Sie dem Modell nicht zutrauen können, sich bei der Eingabe selbst zu kontrollieren, setzen Sie es an der Grenze durch, die das Modell nicht kontrolliert.

Eine zweite Kontrolle wirkt wie eine Funktion für die Produktivität, ist aber in Wahrheit eine für die Sicherheit. Wenn ein Agent seine Arbeit vor der Ausführung zu einem überprüfbaren Plan zusammenstellt, ist die Überprüfung dieses Plans eine Sicherheitsüberprüfung. Ein vierzigzeiliges Workflow-Skript, das jedes Tool nennt, das es aufrufen wird, und jede Datei, die es anfassen wird, ist ein Bedrohungsmodell, das Sie in einer Minute lesen. Sie können nicht zehntausend Live-Entscheidungen prüfen; Sie können den Plan prüfen, der sie erzeugen würde, bevor er irgendetwas ausgibt.

Und behalten Sie die Asymmetrie im Blick: Dieselbe Fähigkeit, die diese CVEs erzeugt, findet sie auch. Ein Forscher von Anthropic nutzte einen Coding-Agenten und ein zehnzeiliges Skript, um eine 23 Jahre alte Schwachstelle im Linux-Kernel und 22 Firefox-CVEs zutage zu fördern. Das Werkzeug auf Ihrem Schreibtisch ist ein Schwachstellen-Scanner, der auf Ihren eigenen Stack gerichtet ist, wenn Sie ihn darauf richten. Verteidiger können die Entdeckung heute automatisieren und bauen gerade die Triage-Schicht auf. Das ist der eine Vorteil, den das Web von 1998 nicht hatte.

Die Position

Hier ist, was meiner Meinung nach passiert, konkret genug, um falsch zu sein. Das Agenten-Ökosystem bekommt seinen Code-Red-Moment, bevor es seine Sicherheitskultur bekommt, denn genau in dieser Reihenfolge tat es das Web. Die erzwingende Kraft ist höchstwahrscheinlich ein sich selbst verbreitendes Prompt-Injection-Payload, das sich über gemeinsam genutzte MCP-Server zwischen Agenten bewegt, oder ein massenhaftes Ereignis der Zugangsdaten-Exfiltration, das sich auf eine einzige beliebte, unzureichend geprüfte Integration zurückführen lässt. Es wird billig zu bauen sein, denn dieselben Modelle, die Kernel-Bugs finden, können es schreiben, und die Warnung vor „einer großen heranrollenden Welle” bezog sich nie nur auf die Verteidigung.

Nachdem sie eingeschlagen ist, hört Secure-by-default auf, optional zu sein. MCP-Clients werden mit standardmäßig aktivierten Einwilligungsdialogen ausgeliefert, mit validierten Token-Audiences, mit Callbacks, die nicht übereinstimmende Redirect-URIs ablehnen, so wie PHP schließlich mit ausgeschaltetem register_globals ausgeliefert wurde. Berechtigungsschichten wechseln von Opt-in zu Default-Deny. Die Integrationen, die überleben, sind jene, die den Sicherheitsanhang der Spezifikation als die Spezifikation behandelt haben.

Der unbequeme Teil ist der Zeitverlauf. Das Web brauchte etwa von 1998 bis 2005, um Secure-by-default zu verinnerlichen, mit Jahren zwischen den Würmern zum Nachdenken. Der Agent-Stack potenziert sich schneller, mit einem wertvolleren Ziel auf der Maschine jedes Entwicklers und einer Angreifer-Toolchain, die sich mit jeder Modellgeneration verbessert. Das 1998-Problem ist real. Die einzige offene Frage ist, ob wir aus der Analogie handeln, bevor der Wurm das Ende schreibt, oder danach.

Wichtigste Erkenntnisse

• Führen Sie das Trifecta-Audit bei jedem Agenten durch. Schreiben Sie auf, was jedes Tool lesen, ausführen und exfiltrieren kann, und bestätigen Sie dann für jede Zeile eine deterministische Schutzvorrichtung. Eine Fähigkeit ohne Schutzvorrichtung ist Ihre Exposition — und die Stelle, an der das nächste Payload einschlägt.
• Führen Sie eine Allowlist für MCP-Server; behandeln Sie jeden Befehlsparameter als nicht vertrauenswürdige Ausführung. Eine Integration hinzuzufügen ist ein Klick, sie zu prüfen ist es nicht, also beschränken Sie die Registrierung auf eine geprüfte Liste. Zwei der vier CVEs hier waren OAuth-Flow-Bugs in MCP-Clients: Der Handshake ist eine Grenze, keine Formalität.
• Machen Sie die Planungsphase zum Prüf-Gate. Lassen Sie Agenten ihre Absicht zu einem überprüfbaren Plan zusammenstellen und lesen Sie ihn vor der Ausführung wie ein Bedrohungsmodell. Ein Skript, das seine Tools und Dateien benennt, ist in einer Minute prüfbar; zehntausend Live-Tool-Aufrufe sind es nicht.
• Richten Sie den Scanner zuerst auf sich selbst. Die Fähigkeit, die diese CVEs erzeugt, findet sie auch. Führen Sie agentengestützte Sicherheits-Sweeps über Ihren eigenen Code und Ihre Abhängigkeiten durch, bevor jemand anderes seine über Sie laufen lässt.

FAQ

Sind MCP-Server sicher?

Nicht standardmäßig und nicht einheitlich. MCP ist ein Protokoll; seine Sicherheit hängt davon ab, wie jeder Server und Client es umsetzt. Die Offenlegungen von 2025 gegen mcp-remote (CVSS 9,6) und Anthropics MCP Inspector (CVSS 9,4) zeigen, dass selbst Referenzwerkzeuge kritische RCE-Schwachstellen auslieferten.³⁴ Die Spezifikation dokumentiert die wichtigsten Angriffsklassen — Confused Deputy, Token-Passthrough, SSRF, Kompromittierung lokaler Server — und schreibt konkrete Gegenmaßnahmen vor.⁵ Behandeln Sie jeden Server als privilegierte Integration: Betreiben Sie nur solche, denen Sie vertrauen oder die Sie geprüft haben, setzen Sie sie ausdrücklich auf eine Allowlist und gehen Sie davon aus, dass jeder Server, mit dem Sie sich verbinden, Ihren Agenten beeinflussen kann.

Was ist Prompt Injection?

Prompt Injection liegt vor, wenn ein Angreifer Anweisungen in die nicht vertrauenswürdige Eingabe einschleust, die ein KI-System liest, und das Modell ihnen folgt, als kämen sie von Ihnen. Simon Willison prägte den Begriff im September 2022 in Analogie zur SQL-Injection: vertrauenswürdige Anweisungen und nicht vertrauenswürdige Eingaben, verkettet zu einem einzigen Prompt, den das Modell anschließend interpretiert, ohne verlässliche Möglichkeit, zu erkennen, welcher Teil vom Angreifer stammte.⁶ Für Agenten ist sie besonders gefährlich, weil Daten zu einem Vektor werden, und Escaping kann das nicht beheben, weil der Interpreter ein Sprachmodell ist.

Was ist die lethal trifecta?

Simon Willisons Bezeichnung aus dem Juni 2025 für die drei Fähigkeiten, die einen Agenten gemeinsam ausnutzbar machen: Zugriff auf Ihre privaten Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und die Fähigkeit, nach außen zu kommunizieren.⁷ Ein Agent mit allen dreien kann durch eingeschleuste Inhalte dazu manipuliert werden, Ihre Geheimnisse zu lesen und sie an einen Angreifer zu schicken. Die meisten leistungsfähigen Agenten besitzen standardmäßig alle drei, weshalb der richtige Zug ist, jede Fähigkeit abzusichern, statt zu hoffen, dass das Modell widersteht.

Wie sichere ich einen Agenten ab, der auf meiner Maschine läuft?

Beginnen Sie mit der Grenze, die das Modell nicht kontrolliert. Verwenden Sie Berechtigungsregeln und Hooks, die greifen, bevor ein Tool läuft, damit ein kompromittierter Prompt sich nicht in eine Aktion hineinreden kann, die Sie verboten haben. Setzen Sie Tools und MCP-Server auf eine Allowlist, verlangen Sie eine Einwilligung, bevor ein neuer lokaler Server ausgeführt wird, und begrenzen Sie jede Zugangsberechtigung nach dem Least-Privilege-Prinzip, damit ein gestohlenes Token einen kleinen Schadensradius hat. Blockieren Sie ausgehende Anfragen an private und Link-Local-IP-Bereiche, um den Exfiltrationspfad zu schließen. Überprüfen Sie dann den Plan des Agenten vor großen Operationen — dort wird eine Injection abgefangen, die die Lesegrenze überlebt hat.

Quellen