Wenn du lange genug PHP geschrieben hast, trägst du eine Narbe mit dir herum: den Tag, an dem du verstanden hast, was unserialize() macht, wenn ein Angreifer den String kontrolliert. POP-Chains, Phar-Tricks, Session-Blobs, die sich in Shells verwandelten — wir haben Jahre gebraucht, um zu lernen, dass ein gespeicherter Wert immer noch Nutzereingabe ist, egal durch wie viele Schichten er auf dem Weg auf die Platte gewandert ist. Ich erzähle das, weil das KI-Agenten-Ökosystem gerade dieselbe Prüfung noch einmal ablegt, Frage für Frage, und dabei größtenteils dieselben falschen Antworten gibt wie wir damals. Das ist meine These: Die Security-Geschichte rund um Agenten-Frameworks im Jahr 2026 ist keine neue Disziplin. Es ist unsere alte, und PHP-Entwickler sind ungewöhnlich gut gerüstet, sie anzuwenden.

Der Anlass ist die Black Hat 2026. Yarden Porat und Shahar Tal von Check Point Research haben ein Jahr lang die Frameworks angegriffen, auf denen gerade alle ihre Agenten bauen — LangChain, LangGraph, CrewAI, AutoGen, Microsofts Agent Framework, Googles ADK — und sind mit elf Schwachstellen wieder herausgekommen; The Register hat es diese Woche aufgegriffen. Tals Analyse, wie sie berichtet wurde, verdient präzise Zuschreibung: Du solltest davon ausgehen, dass Agenten feindseligen Content lesen werden, und das eigentliche Versagen tritt ein, wenn dieser Content am Ende die vertrauenswürdige Maschinerie steuert — Orchestrierung, Memory, Systeminstruktionen. Er fügte hinzu, dass ein Agent nicht einmal gefährliche Tools aktiviert haben muss, um gegen dich gewendet zu werden; das falsche Dokument einzulesen kann schon reichen. Achte darauf, was dieses Argument tut: Es verschiebt den Bug aus dem Modell heraus und in den Framework-Code hinein. Und da wohnen wir.

Nimm den Fund im Microsoft Agent Framework. Agenten persistieren Checkpoints — Schnappschüsse ihres Zustands, damit ein Task nach einem Ausfall fortgesetzt werden kann. Check Point zeigte, dass eine Payload in einer Nachricht mitreisen, in diesem Checkpoint eingefroren werden und dann ausgeführt werden konnte, wenn ein anderer Nutzer die Session später fortsetzte — weil das Framework seinen eigenen gespeicherten Zustand als von Natur aus sauber behandelte. Ergebnis: Fernzugriff auf den Server, eine Bounty von $10,000, ein Fix und kein CVE, weil das Framework noch nicht allgemein verfügbar war. Jetzt mach Suchen-und-Ersetzen: Nenn den Checkpoint einen serialisierten Session-Blob, und das ist ein Fund, den jedes PHP-Security-Review rot eingekringelt hätte, bevor der Kaffee kalt wird. Wir haben zu genau diesem Versagen buchstäblich Konferenzvortrags-Folklore.

Googles ADK-Eintrag auf der Liste ist ein anderer Klassiker. Das Kit bringt einen eingebauten Coding-Assistenten fürs Entwicklungsteam mit — und in einem Standard-Deployment antwortet der dem offenen Internet, ganz ohne Authentifizierung. Von dort aus konnte ein Angreifer ihn eine Datei schreiben lassen, die automatisch läuft, sie ausführen und auf Umgebungs-Credentials und den Service-Account pivotieren, mit dem die Maschine mit dem Rest von Google Cloud spricht. Google wollte es zunächst nicht als Bug behandeln, zahlte dann $3,133.70 und lieferte einen Teilfix. Jedes PHP-Team, das ich kenne, hat einen Punkt auf seiner Deploy-Checkliste, der nur existiert, weil irgendwann mal jemand eine Debug-Toolbar, eine offen liegende .env oder einen sperrangelweit offenen Xdebug-Port auf einem Produktionshost vergessen hat. Die Lektion war nicht PHP-spezifisch. Gelernt wurde sie außerhalb unseres Hauses offenbar aber auch nicht.

Und die Black-Hat-Ladung ist kein Ausreißer. Im Juni veröffentlichte dasselbe Check-Point-Team eine Kette gegen LangGraph — eine Library mit rund 46,5 Millionen monatlichen Downloads —, die mit SQL-Injection in get_state_history() beginnt und in Remote Code Execution endet. SQL-Injection. Im Jahr 2026. Der Bug, den Prepared Statements und ein Jahrzehnt PDO-Missionierung eigentlich ausrotten sollten. Im Mai dokumentierte Microsoft selbst zwei kritische Löcher im Semantic Kernel, bei denen ein einziger Prompt reichte, um calc.exe auf der Host-Maschine aufpoppen zu lassen. Drüben im MCP-Land erlaubte eine Kette aus drei kritischen Schwachstellen in Anthropics offiziellem mcp-server-git Remote Code Execution, und Scans öffentlicher MCP-Server fördern weiter Path Traversal und Tool Poisoning zutage — Tool-Beschreibungen, die so manipuliert sind, dass sich das Modell anders verhält, als sein Betreiber es beabsichtigt hat.

Lass mich den stärksten Einwand einräumen, denn er ist real: LLMs bringen tatsächlich etwas genuin Neues mit. Es gibt kein htmlspecialchars() für natürliche Sprache. Du kannst einen Prompt nicht parametrisieren wie eine Query, und Prompt Injection ist auf der Modellebene womöglich schlicht unlösbar. Zugestanden. Aber schau dir an, wo der Schaden in jedem der obigen Fälle tatsächlich eingeschlagen ist: eine per String-Konkatenation zusammengebaute Query, ein gespeicherter Blob, der auf Vertrauensbasis ausgeführt wurde, ein Endpunkt, den niemand authentifiziert hat, ein Prozess, der mit Credentials lief, die er nie gebraucht hätte. Das Modell war der Bote; deterministischer Code hat den Schaden angerichtet. Und deterministischer Code ist Terrain, auf dem wir wissen, wie man gewinnt. Du kannst die Prosa eines Angreifers nicht sanitizen — aber du kannst dich sehr wohl weigern, etwas per exec() auszuführen, nur weil ein wiederauferstandener String höflich darum gebeten hat.

Das betrifft uns ganz konkret, denn Agenten landen gerade jetzt in PHP-Läden: MCP-Server in PHP geschrieben, Laravel-Queue-Worker, die Agenten-APIs aufrufen, Symfony-Backends, die Konversationszustand direkt neben Kundendaten persistieren. Also wende die Reflexe an, die wir schon besitzen. Alles, was ein Agent speichert und später wieder einliest, ist $_POST mit Zeitverzögerung — validiere auf dem Weg aus dem Storage heraus, nicht nur auf dem Weg hinein. Lass jedes Tool, das der Agent aufrufen kann, mit den geringsten Rechten laufen, die du einem Cronjob geben würdest, den du nicht selbst geschrieben hast. Authentifiziere Endpunkte, auch wenn sie 'nur fürs Team' sind. Und falls du Psalm einsetzt: Dessen Taint-Analyse wurde für genau diese Form von Problem gebaut — nicht vertrauenswürdigen Input bis zu einer gefährlichen Senke zu verfolgen, durch Code, der in der Mitte völlig harmlos aussieht.

Zwei Forscher, zwölf Monate, elf Schwachstellen quer durch die populärsten Agenten-Frameworks der Welt — dieses Verhältnis sagt dir, wie wenig Prüfung diese Schicht bisher hatte und wie viele tief hängende Früchte noch dranhängen. Die PHP-Community hat ihr eigenes Härtungs-Jahrzehnt durchgemacht und ist mit Instinkten herausgekommen, die es wert sind, exportiert zu werden; das ist ein Moment, um die Erwachsenen im Raum zu sein, nicht die Skeptiker in der Ecke. Was ich also wirklich von dir wissen will: Wo ziehst du in deinen eigenen Agenten-Integrationen die Vertrauensgrenze? Wenn Output oder Zustand von einem Agenten zurückkommt, den du selbst deployt hast — validierst du ihn wie ein Formular von einem Fremden, oder behandelst du ihn, ganz ehrlich, immer noch als intern?