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 mittlerer Schwere, den ein Maintainer an einem Wochenende patcht. Zusammen gelesen ist die Häufung ein Signal, und dieses Signal ist strukturell: Das KI-Agenten-Ökosystem sammelt Angriffsfläche schneller an, als es die Sicherheitskultur ansammelt, um sie 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 Voreinstellungen den Massenmarkt 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 der Sicherheitsreife von 1998 in ein Bedrohungsmodell von 2026 ausgeliefert.

TL;DR

• Cherry Studio, ein verbreiteter Desktop-Client für KI-Agenten, zog sich am 29. Juni 2026 zwei CVEs zu: einen Autorisierungsfehler im MCP-OAuth-Callback-Server (CVE-2026-13524) und eine Autorisierungsumgehung in einer Preload-API (CVE-2026-13534).¹²
• Das Muster beschränkt sich nicht auf eine 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).³⁴
• Agenten-Werkzeuge sind strukturell stärker exponiert, als Webanwendungen es je waren: Sie halten Zugangsdaten, führen Code konstruktionsbedingt aus und sitzen innerhalb Ihrer Vertrauensgrenzen (IDE, Shell, Browser) statt dahinter.
• Das Wissen, um diese Fehler zu verhindern, existiert längst. Die MCP-Spezifikation dokumentiert die Angriffsklassen Confused Deputy und OAuth-Flow im Detail; die Kultur, es auf jede schnell wachsende Integration anzuwenden, verbreitet sich noch nicht.⁵
• Das Web von 1998 reifte erst, nachdem Würmer Unsicherheit teuer gemacht hatten. Dem Agenten-Ökosystem fehlt bislang eine vergleichbare erzwingende Kraft, und dieselben Modelle, die diese Fehler heute finden, können genau jene schreiben, die 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 und Server für das Model Context Protocol ausdrücklich unterstützt. Genau um diese Art von Werkzeug geht es hier: ein Agent für Endanwender, der Ihre API-Schlüssel vermittelt, lokale Integrationen ausführt und in Ihrem Namen ins Netz greift.

Am 29. Juni 2026 veröffentlichte VulDB zwei Advisories dagegen. CVE-2026-13524 ist ein Autorisierungsfehler (CWE-285) im MCP OAuth Local Callback Server, in der Datei src/main/services/mcp/oauth/callback.ts, über die Versionen 1.9.0 bis 1.9.6 hinweg. Die Formulierung ist schlicht: „The manipulation of the argument code leads to improper authorization.“ Bewertet wird das nach CVSS 3.1 mit 5,6, also mittel.¹ CVE-2026-13534 ist eine Autorisierungsumgehung (CWE-639) in der CherryIN-Preload-API, bis einschließlich Version 1.9.7, mit einer Bewertung von 5,0.² Keiner der beiden ist eine Schlagzeile. Beide sind der stille Autorisierungsfehler, den ein Team macht, wenn es sich schnell durch ein für alle neues Terrain bewegt.

Verräterisch ist der erste. Ein OAuth-Callback in einem MCP-Client ist eine lehrbuchreife Vertrauensgrenze: der Punkt, an dem ein externer Autorisierungsserver einen Code an Ihre Maschine zurückgibt und Ihre Maschine entscheidet, ob sie ihm traut. Ihn falsch zu behandeln ist keine exotische neue Fehlerklasse. Es ist jene, der das Sicherheitsdokument der MCP-Spezifikation selbst am meisten Raum widmet.

Zwei benachbarte CVEs aus demselben Zeitfenster habe ich verworfen, denn die Häufung muss echt sein: CVE-2026-13533 betrifft agentejo Cockpit CMS, ein PHP-Content-Management-System und kein Agenten-Framework, und CVE-2026-13543 ließ sich überhaupt nicht verifizieren. Ein paar belastbare Beispiele schlagen eine aufgeblähte Liste.

Warum Agenten-Werkzeuge 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 Wirkungsradius umfasste Datenbank und Session, und ein Einbruch verschaffte dem Angreifer die Daten dieser Anwendung.

Ein Agenten-Werkzeug kehrt diese Geometrie um. Es läuft auf Ihrer Maschine oder in Ihrer IDE, hält langlebige Zugangsdaten zu Ihrer Cloud und Ihren Repositories 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 konstruktionsbedingt durchlässig.

Simon Willison benannte die Gefahr im Juni 2025 präzise mit der „lethal trifecta“: Ein Agent wird angreifbar, sobald er „access to your private data“, „exposure to untrusted content“ und „the ability to externally communicate“ so kombiniert, dass diese Daten gestohlen werden können.⁷ Jeder leistungsfähige Agent hat 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 verleitet werden, den Datenbestand einer einzigen Grenze preiszugeben. Der Agent von 2026 kommt bereits mit jeder Fähigkeit verdrahtet an, die eine Exfiltrationskette braucht, und zwischen einer bösartigen Eingabe und Ihren Zugangsdaten steht nur noch die Frage, ob das Werkzeug seine internen Vertrauensgrenzen richtig gezogen hat. Der Callback-Bug in Cherry Studio zeigt, wie es aussieht, wenn eine dieser Grenzen ein wenig falsch gezogen wurde.

Die MCP-Verstärkung

Das Model Context Protocol ist das Bindegewebe des Agenten-Stacks von 2026, und es vervielfacht die Angriffsfläche auf eine 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 nicht. Die installierte Basis an Integrationen läuft der Zahl der Menschen davon, die ihren Code lesen.

Die Referenzwerkzeuge zeigen, dass dies kein Problem von Hobbyprojekten ist. Im Juli 2025 legte JFrog CVE-2025-6514 offen, eine OS-Command-Injection in mcp-remote, einem von Claude Desktop, Cursor und Windsurf genutzten Connector, die 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 legte Tenable CVE-2025-49596 offen, eine Remote-Code-Execution-Schwachstelle mit 9,4 in Anthropics eigenem MCP Inspector, bei der eine fehlende Authentifizierungsprüfung einer bösartigen Website erlaubte, einen lokalen Port zu erreichen und per DNS-Rebinding beliebige Befehle auszuführen.⁴

Zwei der vier CVEs in diesem Text sind OAuth-Flow-Fehler in MCP-Werkzeugen: einer im Callback-Server, einer bei der Endpunkt-Ermittlung. Das ist kein Zufall. OAuth in einem Agent-Client ist eine wiederholt verpatzte Grenze, und die Spezifikation sagt das laut. 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 Zustimmung pro Client umsetzen, den OAuth-Parameter state validieren und Redirect-URIs exakt abgleichen.⁵ Das erschien ein Jahr, bevor Cherry Studio seinen Callback-Bug auslieferte. Die Lücke ist nicht das Wissen. Es ist die Distanz zwischen dem Sicherheitsanhang einer Spezifikation und der durchschnittlichen Integration, die letzten Dienstag geschrieben wurde.

Prompt Injection macht die Verstärkung qualitativ schlimmer als alles, was das alte Web zu sehen bekam. Willison prägte den Begriff im September 2022 mit dem Satz „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, zu einer Zeichenkette verkettet, die eine Engine anschließend interpretiert.⁶ Für einen Agenten sind Daten ein Vektor, nicht nur Code. Eine vergiftete Webseite, eine präparierte Datei, eine feindselige Werkzeugbeschreibung: Jedes Byte, das das Modell liest, kann eine Anweisung tragen. Die MCP-Spezifikation wird da deutlich und warnt, dass ein bösartiger Server den Client in einen Proxy für Datenabfluss verwandeln kann.⁵ Das lässt sich nicht mit Eingabe-Escaping flicken, denn die Eingabe ist natürliche Sprache und der Interpreter ist ein Modell.

Die 1998-Analogie, präzise gemacht

Die Analogie muss einen Faktencheck überstehen, sonst ist sie bloß Stimmung. Also hier die Epoche, akkurat.

PHP 3 erschien im Juni 1998 und legte eine dynamische Websprache in Millionen Hände, mit einer Voreinstellung, die heute leichtsinnig klingt: Externe Eingaben aus dem Query-String, aus Cookies oder vom Server wurden direkt in den globalen Scope registriert. register_globals war an, und eine vom Angreifer kontrollierte Variable konnte still zu einer werden, der Ihr Code vertraute. Die Korrektur dauerte vier Jahre. PHP 4.2.0, veröffentlicht im April 2002, änderte die Voreinstellung, und die Release-Ankündigung sagt es nüchtern: „External variables (from the environment, the HTTP request, cookies or the web server) are no longer registered in the global scope by default.“⁸ Die andere prägende Krücke jener Zeit, Magic Quotes, ließ addslashes laufen und täuschte damit Sicherheit vor SQL-Injection vor, ohne sie zu liefern; sie überlebte register_globals um Jahre, bevor das Projekt sie endlich abschaffte. Unsichere Voreinstellungen, eine Illusion von Sicherheit, ein Rückstand von Jahren, bis die Kultur nachzog. Das war die Anwendungsschicht des jungen Webs.

Die Kultur kam nicht von selbst. Sie wurde erzwungen. Am 19. Juli 2001 nutzte der Wurm Code Red einen Pufferüberlauf im IIS-Webserver von Microsoft aus, und nach der Zählung von CAIDA gilt: „more than 359,000 computers were infected with the Code-Red (CRv2) worm in less than 14 hours“.⁹ Am 25. Januar 2003 traf der Wurm Sapphire/Slammer einen Pufferüberlauf im Microsoft SQL Server, packte sich in 376 Byte große Pakete und „infected most of the vulnerable hosts that could be found within ten minutes“ — der bis dahin am schnellsten verbreitete Wurm der Geschichte.¹⁰ Das waren Infrastruktur-Würmer, keine PHP-Bugs, und ich werde beides nicht vermengen. Der Punkt ist die Form jenes Jahrzehnts: unsichere Voreinstellungen auf jeder Schicht, und eine Sicherheitskultur, die erst reifte, nachdem Unsicherheit spürbar und öffentlich teuer geworden war. Secure by default war eine Lektion, die die Branche in Würmern bezahlte.

Überträgt man das auf 2026, wird die Entsprechung unangenehm. Unsichere Voreinstellungen: Agent-Clients, die Callback-Codes vertrauen und Zustimmungsprüfungen überspringen. Die Illusion von Sicherheit: ein Berechtigungsdialog ü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 Voreinstellungen von 1998 und das Zielprofil von 2001 und wartet auf seine erzwingende Kraft.

Die Haltung des Betreibers

Sie können nicht warten, bis die Kultur so weit ist. Sie betreiben diese Werkzeuge jetzt, also ziehen Sie die Grenzen, die das Ökosystem noch nicht für Sie gezogen hat. Der Rahmen, den ich nutze, ist die Trifecta als operative Checkliste: Fragen Sie bei jedem Agenten, was er lesen, was er ausführen und was er hinausschleusen darf, und setzen Sie auf jedes davon einen deterministischen Wächter.

Die Spalte mit den Wächtern ist kein Wunschdenken. Sie ist deterministisch, und genau darauf kommt es an. Hooks feuern bei Lifecycle-Ereignissen mit Exit-Codes, gegen die das Modell nicht argumentieren kann, und Berechtigungsregeln greifen, bevor ein Werkzeug läuft, nicht danach. Auf dieser Schicht wird aus „der Agent sollte X nicht tun“ ein „der Agent kann X nicht tun“, und sie ist die einzige, an der sich eine Prompt-Injection-Payload nicht vorbeireden kann. Wenn Sie der Eingabe nicht trauen können und dem Modell nicht zutrauen, sich an dieser Eingabe selbst zu kontrollieren, dann erzwingen Sie es an der Grenze, die das Modell nicht kontrolliert.

Eine zweite Kontrolle liest sich wie eine Produktivitätsfunktion, ist aber eine Sicherheitsfunktion. Wenn ein Agent seine Arbeit vor der Ausführung zu einem prüfbaren Plan kompiliert, ist die Prüfung dieses Plans ein Security-Review. Ein vierzig Zeilen langes Workflow-Skript, das jedes Werkzeug benennt, das es aufrufen, und jede Datei, die es anfassen wird, ist ein Bedrohungsmodell, das Sie in einer Minute lesen. Zehntausend Live-Entscheidungen können Sie nicht prüfen; den Plan, der sie erzeugen würde, können Sie prüfen, bevor er irgendetwas verbraucht.

Und behalten Sie die Asymmetrie im Blick: Dieselbe Fähigkeit, die diese CVEs hervorbringt, findet sie auch. Ein Forscher bei Anthropic brachte mit einem Coding-Agenten und einem zehnzeiligen Skript eine 23 Jahre alte Schwachstelle im Linux-Kernel sowie 22 Firefox-CVEs ans Licht. Das Werkzeug auf Ihrem Schreibtisch ist ein Schwachstellenscanner, der auf Ihren eigenen Stack zeigt, wenn Sie ihn darauf richten. Verteidiger können die Entdeckung heute automatisieren und bauen gerade die Triage-Schicht. Das ist der eine Vorteil, den das Web von 1998 nicht hatte.

Update, 24. August: Die Aufzeichnung seit der Veröffentlichung

Dieser Beitrag argumentierte, die Junihäufung sei ein strukturelles Signal, kein Pech. Sieben Wochen Aufzeichnung seither:

Der lange Schwanz von MCP erzeugt einen stetigen CVE-Fluss. In einer Woche Mitte August zogen sich drei Community-MCP-Server CVEs zu: Code-Injection in der Python-REPL von Jij-MCP-Server (CVE-2026-19964), Befehlsausführung über Argumentmanipulation in android-mcp-server (CVE-2026-19978) und Server-Side Request Forgery in mcp-florence2 (CVE-2026-19984).¹¹¹²¹³ Alle von mittlerer Schwere — zwei aus der Ferne auslösbar, der dritte lokal auf dem Host, auf dem der Agent läuft — und alle aus den klassischen Klassen: Injection, ungefilterte Ausführung, SSRF, gelandet in Werkzeugen, die mit den Rechten eines Agenten laufen. Genau das Szenario, das der Abschnitt zur MCP-Verstärkung als strukturell beschrieb — ein langer Schwanz kleiner Integrationen, jede ein potenzielles mcp-remote — trifft nun planmäßig ein.

Es ist nicht nur der Community-Schwanz. Der Azure SRE Agent, Microsofts eigener Betriebsagent, zog sich am 7. August CVE-2026-62830 zu: fehlende Autorisierung, die eine Rechteausweitung über das Netzwerk ermöglicht, bewertet mit 9,9, kritisch.¹⁴ Das strukturelle Argument ging nie um Amateur-Maintainer; es geht darum, was Agenten-Werkzeuge sind.

Die Angriffsforschung hat die Lieferkette eingeholt. ElasticBack demonstrierte eine bedingte Backdoor, die in einem einzigen Agent-Skill-Dokument platziert wurde, und beschreibt Skills als „an emerging supply chain where a single poisoned skill can persistently compromise every agent that installs it“.¹⁵ Und die Antwort des Ökosystems auf die Verteilung, Agent Plugins 1.0, erschien mit client-verwalteten Berechtigungen und Herkunftsnachweisen und ganz ohne Signaturschicht — die Verpackungsschicht kam vor der Sicherheitsschicht, dieselbe Reihenfolge, die diesem Beitrag zufolge den gesamten Stack prägt: Erst wird die Fähigkeit ausgeliefert, die Sicherheitskultur folgt hinterher.

Die Prognose weiter unten bleibt unverändert stehen.

Die Position

Hier ist, was meiner Ansicht nach passiert, konkret genug, um falsch zu sein. Das Agenten-Ökosystem bekommt seinen Code-Red-Moment, bevor es seine Sicherheitskultur bekommt, denn in dieser Reihenfolge hat es das Web getan. Die erzwingende Kraft ist am wahrscheinlichsten eine sich selbst verbreitende Prompt-Injection-Payload, die über geteilte MCP-Server zwischen Agenten wandert, oder ein Massenabfluss von Zugangsdaten, der sich auf eine einzige beliebte, kaum geprüfte Integration zurückführen lässt. Der Bau wird billig sein, denn dieselben Modelle, die Kernel-Bugs finden, können sie schreiben, und die Warnung vor einer großen anrollenden Welle ging nie nur um Verteidigung.

Danach hört Secure by default auf, optional zu sein. MCP-Clients erscheinen mit standardmäßig aktivierten Zustimmungsdialogen, validierten Token-Audiences und Callbacks, die nicht passende Redirect-URIs abweisen — so, wie PHP irgendwann mit ausgeschaltetem register_globals erschien. Berechtigungsschichten wandern von Opt-in zu Default-Deny. Die Integrationen, die überleben, sind jene, die den Sicherheitsanhang der Spezifikation als die Spezifikation behandelt haben.

Unangenehm ist der Zeitplan. Das Web brauchte grob von 1998 bis 2005, um Secure by default zu verinnerlichen, mit Jahren zwischen den Würmern zum Nachdenken. Der Agenten-Stack verzinst sich schneller, mit einem wertvolleren Ziel auf jeder Entwicklermaschine und einer Angreifer-Toolchain, die sich mit jeder Modellgeneration verbessert. Das 1998-Problem ist real. Offen ist einzig, ob wir aus der Analogie handeln, bevor der Wurm das Ende schreibt, oder danach.

Die wichtigsten Erkenntnisse

• Führen Sie die Trifecta-Prüfung bei jedem Agenten durch. Schreiben Sie auf, was jedes Werkzeug lesen, ausführen und hinausschleusen kann, und bestätigen Sie dann für jede Zeile einen deterministischen Wächter. Eine Fähigkeit ohne Wächter ist Ihre Exposition — und die Stelle, an der die nächste Payload landet.
• Setzen Sie MCP-Server auf eine Allowlist; behandeln Sie jeden Befehlsparameter als nicht vertrauenswürdige Ausführung. Eine Integration hinzuzufügen kostet einen Klick, sie zu prüfen nicht, also begrenzen 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 Formalie.
• Machen Sie die Planungsphase zum Prüftor. Lassen Sie Agenten ihre Absicht zu einem prüfbaren Plan kompilieren und lesen Sie ihn vor der Ausführung wie ein Bedrohungsmodell. Ein Skript, das seine Werkzeuge und Dateien benennt, ist in einer Minute prüfbar; zehntausend Live-Werkzeugaufrufe sind es nicht.
• Richten Sie den Scanner zuerst auf sich selbst. Die Fähigkeit, die diese CVEs hervorbringt, findet sie auch. Lassen Sie agentengestützte Sicherheitsdurchläufe über Ihren eigenen Code und Ihre Abhängigkeiten laufen, bevor jemand anders seine über Sie laufen lässt.

Häufige Fragen

Sind MCP-Server sicher?

Nicht standardmäßig und nicht einheitlich. MCP ist ein Protokoll; seine Sicherheit hängt davon ab, wie jeder Server und jeder Client es umsetzt. Die Offenlegungen von 2025 zu mcp-remote (CVSS 9,6) und Anthropics MCP Inspector (CVSS 9,4) zeigen, dass selbst Referenzwerkzeuge kritische RCE-Schwachstellen auslieferten.³⁴ Die Spezifikation dokumentiert die wesentlichen Angriffsklassen — Confused Deputy, Token-Durchreichung, SSRF, Kompromittierung lokaler Server — und schreibt konkrete Gegenmaßnahmen vor.⁵ Behandeln Sie jeden Server als privilegierte Integration: Betreiben Sie nur solche, denen Sie trauen 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?

Von Prompt Injection spricht man, wenn ein Angreifer Anweisungen in die nicht vertrauenswürdige Eingabe schmuggelt, 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, zu einem Prompt verkettet, den das Modell anschließend interpretiert, ohne verlässlich unterscheiden zu können, welcher Teil vom Angreifer stammt.⁶ Für Agenten ist das besonders gefährlich, weil Daten zum Vektor werden, und Escaping hilft nicht, denn der Interpreter ist ein Sprachmodell.

Was ist die lethal trifecta?

Simon Willisons Bezeichnung vom Juni 2025 für die drei Fähigkeiten, die einen Agenten zusammen angreifbar machen: Zugriff auf Ihre privaten Daten, Kontakt mit nicht vertrauenswürdigen Inhalten und die Möglichkeit, nach außen zu kommunizieren.⁷ Ein Agent mit allen dreien kann durch eingeschleuste Inhalte dazu gebracht werden, Ihre Geheimnisse zu lesen und an einen Angreifer zu schicken. Die meisten leistungsfähigen Agenten haben alle drei standardmäßig, weshalb der richtige Zug darin besteht, jede Fähigkeit einzeln abzusichern, statt zu hoffen, dass das Modell standhält.

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

Beginnen Sie an der Grenze, die das Modell nicht kontrolliert. Nutzen Sie Berechtigungsregeln und Hooks, die greifen, bevor ein Werkzeug läuft, damit sich ein kompromittierter Prompt nicht in eine Aktion hineinreden kann, die Sie verboten haben. Setzen Sie Werkzeuge und MCP-Server auf eine Allowlist, verlangen Sie Zustimmung, bevor ein neuer lokaler Server ausgeführt wird, und statten Sie jede Zugangsberechtigung mit minimalen Rechten aus, damit ein gestohlenes Token einen kleinen Wirkungsradius hat. Blockieren Sie ausgehende Anfragen an private und Link-Local-IP-Bereiche, um den Exfiltrationsweg zu schließen. Prüfen Sie danach den Plan des Agenten vor großen Operationen — dort wird die Injection abgefangen, die die Lesegrenze überstanden hat.

Quellen