Quavon Development
AI Security / Coding Agents5 Min. Lesezeit

Plugin4Shell umging die Plugin-Prüfung von vier Coding-Agenten

AIR Security fand denselben Plugin-Pinning-Fehler in Claude Code, Codex, GitHub Copilot und Gemini CLI. Manipulierter Plugin-Code konnte die vorgesehene Versionsprüfung umgehen; automatische Updates machten den Pfad bei einigen Agenten ohne weitere Benutzeraktion erreichbar.

Redaktion von Quavon DevelopmentVeröffentlicht
Die kurze Antwort

Plugin4Shell ist eine von AIR Security veröffentlichte Supply-Chain-Schwachstelle in Claude Code, OpenAI Codex, GitHub Copilot und Gemini CLI. Die Agenten legten Plugins zwar auf geprüfte Git-Versionen fest, verifizierten nach Angaben der Forscher aber nicht zuverlässig, dass der tatsächlich geladene Code diesem Stand entsprach. Anthropic und OpenAI haben Korrekturen ausgeliefert; für Copilot war bei Veröffentlichung kein vollständiger Client-Fix genannt, und die abgekündigte Gemini CLI soll nicht mehr gepatcht werden.

AIR Security hat eine gemeinsame Supply-Chain-Schwachstelle in Claude Code, OpenAI Codex, GitHub Copilot und Gemini CLI veröffentlicht. Die betroffenen Agenten sollten installierte Plugins auf eine zuvor geprüfte Git-Version festlegen. Nach Angaben der Forscher prüften sie jedoch nicht zuverlässig, ob der anschließend ausgecheckte Inhalt tatsächlich dieser festgelegten Version entsprach.

Damit konnte aus einem bereits vertrauenswürdigen Plugin später anderer Code werden, ohne dass die vorgesehene Pinning-Grenze das verhinderte. Bei Agenten mit automatischen Plugin-Updates konnte die Aktualisierung außerdem ohne erneute Benutzeraktion erfolgen.

AIR nennt die Schwachstelle Plugin4Shell. Anthropic hat Claude Code nach der koordinierten Meldung in Version 2.1.179 korrigiert. OpenAI bestätigte laut AIR die Korrektur in Codex 0.146.0. Für GitHub Copilot war zum Zeitpunkt der Veröffentlichung kein vollständiger Fix genannt. Google teilte den Forschern nach deren Darstellung mit, dass die inzwischen abgekündigte Gemini CLI nicht mehr korrigiert werde.

Es gibt bislang keinen von AIR genannten Nachweis, dass Plugin4Shell außerhalb der Forschung aktiv ausgenutzt wurde.

Das Pinning existierte, aber die letzte Prüfung fehlte

Plugin-Marktplätze können Erweiterungen nach einer Prüfung an eine konkrete Git-Version binden. Die Idee ist einfach: Ein später verändertes Repository soll nicht dazu führen, dass ein Agent unbemerkt anderen Code installiert als den zuvor freigegebenen.

AIR fand bei vier unabhängig entwickelten Coding-Agenten denselben grundsätzlichen Fehler. Der Client forderte die festgelegte Git-Version an, verifizierte anschließend aber nicht ausreichend, dass der tatsächlich ausgecheckte Inhalt genau dieser Version entsprach.

Damit lag die Schwachstelle nicht im Sprachmodell. Auch Prompt Injection spielte für den beschriebenen Angriff keine Rolle. Betroffen war der Software-Lieferweg um den Agenten herum.

Das ist für Coding-Agenten besonders relevant, weil Plugins nicht in einer isolierten Informationsschicht enden. Sie können im Kontext des Agenten laufen. Je nach Installation gehören dazu Quellcode, lokale Dateien und die Berechtigungen, die der Agent für seine Entwicklungsarbeit erhalten hat.

Die tatsächliche Reichweite hängt deshalb vom jeweiligen Setup ab. Ein Agent mit stark eingeschränktem Dateisystem- und Netzwerkzugriff begrenzt auch die Folgen eines kompromittierten Plugins. Ein Agent, der mit weitreichenden Entwicklerrechten läuft, vergrößert sie.

Automatische Updates machten aus dem Fehler einen Zero-Click-Pfad

AIR unterscheidet zwischen der Schwachstelle im Pinning und dem Mechanismus, der daraus einen Angriff ohne weitere Interaktion machen kann.

Claude Code und Codex aktualisierten installierte Plugins nach Angaben der Forscher standardmäßig im Hintergrund. War ein Plugin bereits installiert und sein Repository später kompromittiert oder vom Angreifer kontrolliert, konnte ein Update deshalb automatisch verarbeitet werden.

Der Benutzer musste das manipulierte Plugin nicht neu auswählen oder einer neuen Installation zustimmen. Genau diese Kombination aus fehlerhafter Versionsprüfung und automatischer Aktualisierung beschreibt AIR als Zero-Click-RCE-Pfad.

The Register und Help Net Security haben den technischen Kern der Veröffentlichung unabhängig aufgegriffen. Beide beschreiben ebenfalls, dass die Agenten den vorgesehenen Git-Pin nicht zuverlässig gegen den tatsächlich geladenen Stand prüften.

Vier Hersteller bauten dieselbe Vertrauensannahme ein

Interessant ist weniger, dass ein einzelner Coding-Agent einen Fehler im Plugin-Manager hatte. AIR demonstrierte funktionierende Proofs of Concept gegen vier verschiedene Agenten.

Das deutet auf eine gemeinsame Architekturannahme hin: Wenn der Marktplatz eine Erweiterung geprüft und eine Version festgelegt hat, wird die Git-Auflösung auf dem Client als ausreichender Beweis behandelt.

Eine belastbarere Grenze braucht zwei getrennte Schritte. Der Marktplatz entscheidet, welcher unveränderliche Stand freigegeben ist. Der ausführende Client muss anschließend selbst feststellen, dass genau dieser Stand vorliegt, bevor er Code daraus lädt.

Diese zweite Prüfung ist besonders wichtig, weil der Marktplatz den finalen Checkout auf dem Entwicklerrechner nicht kontrolliert. AIR weist deshalb darauf hin, dass die Korrektur im Agenten selbst erfolgen muss.

Die Hersteller reagierten unterschiedlich

AIR meldete den Fehler im Juni 2026 koordiniert an Anthropic, OpenAI, Microsoft und Google.

Anthropic bestätigte nach Angaben der Forscher am 17. Juni eine Korrektur in Claude Code 2.1.179. Für Codex wurde Version 0.146.0 am 12. August als korrigiert verifiziert.

Bei Copilot ist die Lage weniger eindeutig. GitHub erklärte gegenüber The Register, dass GitHub selbst bestimmte mehrdeutige Git-Referenzen nicht zulasse. AIR hält das nicht für eine vollständige Lösung, weil Copilot-Pluginquellen nicht zwingend auf GitHub gehostet werden müssen. Zum Zeitpunkt der öffentlichen Offenlegung nannte AIR keinen von Microsoft ausgelieferten Client-Fix.

Google teilte AIR laut deren Veröffentlichung mit, Gemini CLI sei abgekündigt und werde für diesen Fehler nicht mehr gepatcht. Nutzer würden auf Antigravity verwiesen, dessen Plugin-System diesen konkreten Pinning-Pfad nicht verwende.

Diese Angaben zu den Herstellerreaktionen stammen teilweise aus AIRs Disclosure-Timeline. Sie sind deshalb als Angaben der meldenden Security-Firma zu lesen, nicht als unabhängig gemessene Patch-Abdeckung aller Installationen.

Agent-Security endet nicht am Modell

Plugin4Shell ist ein brauchbares Gegenbeispiel zu einer zu engen Definition von AI-Security. Kein Modell musste getäuscht werden. Die Schwachstelle entstand in klassischer Software rund um den Agenten: Git-Auflösung, Plugin-Verteilung und automatische Updates.

Der Unterschied zu einem gewöhnlichen Plugin-Fehler liegt in der Berechtigungsumgebung. Coding-Agenten werden gerade deshalb eingesetzt, weil sie Dateien lesen, Code verändern und Werkzeuge ausführen dürfen. Ein Plugin läuft damit potenziell an einer Stelle, an der bereits viele dieser Fähigkeiten zusammengeführt sind.

Für die Sicherheitsarchitektur folgt daraus eine konkrete Trennung: Die Vertrauenswürdigkeit eines Plugins und die Berechtigungen des Agenten sind zwei verschiedene Kontrollen. Selbst korrekt geprüfte Erweiterungen sollten nicht automatisch alle Rechte erben, die ein Entwickler seinem Agenten für andere Aufgaben gegeben hat.

AIR veröffentlicht keine Evidenz für eine aktive Ausnutzung von Plugin4Shell in realen Angriffen. Der belegte Befund ist enger und technisch ausreichend interessant: Vier große Coding-Agenten implementierten eine Sicherheitsgrenze, ohne am Ende zu verifizieren, dass der ausgeführte Plugin-Code tatsächlich dem geprüften Stand entsprach.

Starten wir durch

Sollen wir uns das ansehen?

Erzählen Sie uns, was entstehen soll. Sie bekommen eine ehrliche Einschätzung zu Umfang, Zeitrahmen und Risiken — und eine klare Antwort, ob wir das richtige Team dafür sind.

Antwort in der Regel innerhalb von 24 Stunden