SHA-Pinning ist keine Verifikation: Plugin4Shell und die erste Supply-Chain-RCE in KI-Agenten

925 Plugin-Skills wurden bereits von ihren ursprünglichen Maintainern gekapert, und diese Skills erreichen 134.000 Agenten. Am 17. September 2026 hat AIR Security Plugin4Shell offengelegt — die erste Supply-Chain-Schwachstelle des KI-Agenten-Ökosystems: eine Zero-Click-Remote-Code-Execution (RCE), die Claude Code, OpenAI Codex, GitHub Copilot und Google Gemini CLI betrifft, alle über dieselbe fehlende Prüfung. Der Mechanismus ist eine einzige Git-Assertion, die jeder betroffene Agent überspringt: Der Agent checkt den vom Marketplace gepinnten Commit-SHA aus, verifiziert aber nie, dass der Working Tree tatsächlich auf diesem Commit gelandet ist. Ein Angreifer, der ein Plugin-Repository kontrolliert, benennt einen Branch nach dem gepinnten 40-Zeichen-SHA, macht ihn zum Repository-Default, und der Agent installiert Angreifer-kontrollierten Code, während er eine saubere Installation am gepinnten Commit meldet (Cyber Security News; Help Net Security).

Das ist für jedes Team relevant, das Coding-Agenten gegen Produktionssysteme betreibt — denn der Pin war die Kontrolle. Organisationen, die über einen Community-Marketplace hinausgehen — Plugin-Code reviewen, Installationen an einen geprüften Commit pinnen — haben sich auf SHA-Pinning als Absicherung verlassen, und Plugin4Shell hebt es stillschweigend auf: Die Review geht durch, der Pin wird geschrieben, und anderer Code läuft (AIR). Dieser Artikel behandelt die vier Dinge, die ein Head of Engineering braucht, bevor das nächste Plugin-Auto-Update auslöst: den Mechanismus in einem Git-Befehl, den fünfstufigen Angriff von der benignen Adoption bis zur Hintergrund-RCE, das Vendor-Response-Scoreboard (zwei gepatcht, einer ungepatcht, einer veraltet-ungepatcht) und die Verifikationsposten, die die Lücke für jedes gepinnte Artefakt schließen, das Ihre Agenten installieren — Plugins, MCP-Server und Skills.

Zentrale Erkenntnisse

• Eine Zero-Click-RCE traf alle vier großen Coding-Agenten — Claude Code, Codex, GitHub Copilot und Gemini CLI — über eine einzige fehlende Git-Assertion — AIR hat Plugin4Shell am 17. September 2026 offengelegt: Agenten checken den vom Marketplace gepinnten Commit-SHA aus, prüfen aber nie, ob der Checkout zu ihm aufgelöst hat (AIR).
• 925 Skills wurden bereits von ihren Maintainern gekapert und erreichen 134.000 Agenten — AIRs SkillJacking-Forschung; Plugin4Shell besiegt genau den SHA-Pinning-Mechanismus, der zur Eindämmung solcher Repository-Übernahmen gebaut wurde (AIR).
• Git bevorzugt einen Branch, der wie ein Hash benannt ist, vor dem Hash selbst — ein Branch, der den gepinnten 40-Zeichen-SHA als Namen trägt und als Repository-Default gesetzt ist, leitet git checkout <sha> auf Angreifer-Code um; die Gemini-CLI-Variante verschattet stattdessen FETCH_HEAD (Cyber Security News).
• Das Vendor-Scoreboard steht bei 2 gepatcht, 1 ungepatcht, 1 veraltet-ungepatcht — Anthropic hat Claude Code in 2.1.179 gefixt und OpenAI Codex in 0.146.0; Microsoft hat keinen Copilot-Fix ausgeliefert, und Google hat Gemini CLI ungepatcht als veraltet eingestuft, sodass jede bestehende Installation weiter exponiert bleibt (Help Net Security).
• Eine einzige Assertion schließt beide Varianten: den aufgelösten HEAD nach dem Checkout gegen den gepinnten SHA verifizieren — test "$(git rev-parse HEAD)" = "<pinned-sha>" || abort — und sie muss im Agenten laufen, denn kein Marketplace kann einen Pin durchsetzen, den er nicht selbst auflöst (AIR).

Das Diagramm unten komprimiert die Offenlegung in eine Minute: die fünfstufige Angriffskette, das Vendor-Scoreboard nach drei Tagen und die Assertion, die die Lücke schließt.

Der Mechanismus: eine Assertion, vier Agenten

SHA-Pinning ist das Marketplace-Sicherheitsmodell, wie es entworfen wurde. Ein Reviewer prüft ein Plugin an einem Commit, der Marketplace zeichnet den SHA dieses Commits auf, und der Agent soll für immer genau diesen Code installieren. Der Fehler liegt im letzten Schritt. Jeder betroffene Agent führt ungefähr diese Sequenz aus (AIR):

git clone  ./
git checkout aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   # der gepinnte SHA

und fragt nie, ob der Checkout tatsächlich auf dem gepinnten Commit gelandet ist. Diese Auslassung ist ausnutzbar, weil git Namen vor Objekten auflöst: Wenn ein Name zugleich eine gültige Ref und ein Commit-Hash ist, bevorzugt git die Ref und gibt nur eine refname is ambiguous-Warnung aus. Der Angreifer — der das Upstream-Repository bereits kontrolliert — erstellt einen Branch, dessen Name exakt der gepinnte 40-Zeichen-Hex-SHA ist, und setzt ihn als Repository-Default. Ein schlichtes git clone holt diesen Branch als lokale Ref, git checkout <sha> löst zum Branch auf, und der Working Tree ist nun Angreifer-kontrolliert, während der Agent eine erfolgreiche Installation am gepinnten SHA meldet (Cyber Security News).

Zwei Bedingungen machen den Trick möglich. Erstens blockiert nichts universell einen Branch, der wie ein Hash benannt ist: Gits eigenes check-ref-format akzeptiert 40-Zeichen-Hex-Namen, und während GitHub sie rundheraus ablehnt, erlauben Bitbucket und selbst gehostete Git-Server sie — und Anthropic selbst führt Bitbucket und selbst gehostetes Git als gültige Marketplace-Backends auf (AIR). Zweitens muss der Branch der Repository-Default sein; ein nicht-Default-Branch kommt nur als Remote-Tracking-Ref an, und der Checkout fällt auf den echten Commit zurück.

Gemini CLI versagt anders. Seine Installationssequenz holt den gepinnten Commit und checkt dann FETCH_HEAD aus:

git clone --depth 1  ./
git fetch origin 41d0bc0a4aeb2fbf797dacea39e876d98c95024b
git checkout FETCH_HEAD

Wenn der Default-Branch des Repositorys selbst FETCH_HEAD heißt, löst der Checkout zu diesem Branch auf und verwirft stillschweigend den gefetchten Commit (AIR). Anderer Befehl, gleiche Ursache: Der Agent vertraut dem Namen, den er angefordert hat, statt den Commit zu verifizieren, den er erhalten hat.

Der Angriff, von Anfang bis Ende: fünf Schritte von der Adoption zur RCE

Keiner der beiden Angriffspfade erfordert die Kontrolle über den Marketplace. AIR hat beide demonstriert:

1. Einpflanzen. Der Angreifer veröffentlicht ein genuin benignes Plugin, gepinnt auf Commit aaa…aaa. Es besteht die Review.
2. Adoption. Nutzer installieren es. Jede Installation ist auf den geprüften Commit gepinnt.
3. Neu pinnen. Der Angreifer liefert ein routinemäßiges, weiterhin benignes Update; der Marketplace zieht den Pin auf bbb…bbb.
4. Rug-Pull. Der Angreifer erstellt einen Branch namens bbb…bbb, setzt ihn als Repository-Default und lässt ihn auf bösartigen Code zeigen. Der gepinnte Commit selbst kann unberührt bleiben.
5. Auto-Update zur RCE. Der geänderte Pin löst das Hintergrund-Auto-Update jedes Agenten aus — Standardverhalten in Claude Code und Codex — der Checkout löst den neuen Pin zum Branch auf, und der Code läuft ohne Klick, ohne Prompt und ohne Neuinstallation (AIR).

Der alternative Pfad ist schneller: das Repository eines legitimen Maintainers übernehmen und den Einpflanz-Schritt komplett überspringen. AIRs Schwestarforschung quantifiziert, wie verbreitet das bereits ist — 925 Skills wurden von ihren ursprünglichen Maintainern gekapert und erreichen 134.000 Agenten (AIR). Es ist der dritte Akt einer Serie: The Story of Skills zeigte eine bösartige Skill, die 26.000 Agenten erreichte, und MCPJacking fand 155 entführbare MCP-Server im offiziellen Marketplace über abgelaufene Domains, die die Forscher registrierten, um auf jedem Agent, der ihnen vertraute, Remote-Prompt-Ausführung zu erlangen (AIR). Plugin4Shell ist das Grenzversagen des Mechanismus, den die Industrie gebaut hat, um genau das zu enthalten. Der Blast Radius ist auch größer als der Agent: Plugins und Add-ons erben die Berechtigungen des Entwicklers, der den Agenten ausführt — lokaler Quellcode, Cloud-Credentials, SSH-Keys, interne Repositories und Produktionssysteme (Cyber Security News).

Das Vendor-Scoreboard: zwei gepatcht, einer ungepatcht, einer veraltet-ungepatcht

Die Disclosure-Timeline zeigt, dass koordinierte Offenlegung funktionierte — und wo sie endete:

Wann	Was
Mai 2026	AIR findet die Schwachstelle, mit funktionierendem PoC gegen alle vier Agenten
Juni 2026	Koordinierte Offenlegung an alle vier Anbieter
17. Juni 2026	Anthropic bestätigt den Fix in Claude Code 2.1.179
4. August 2026	Google bestätigt, dass kein Fix kommt — Gemini CLI ist veraltet; Nutzer werden zu Antigravity migrieren gebeten
12. August 2026	OpenAI's Codex 0.146.0 als gefixt verifiziert
17. September 2026	Öffentliche Offenlegung

Zum Stand 18.–19. September ist das Scoreboard unverändert: Anthropic gepatcht, OpenAI gepatcht, Microsoft hat keinen Copilot-Fix ausgeliefert, und Google hat Gemini CLI ungepatcht als veraltet eingestuft — das heißt, jede bestehende Gemini-CLI-Installation bleibt auf unbestimmte Zeit exponiert (Help Net Security). GitHub's Antwort — SHA-förmige Branch- und Tag-Namen auf seiner Plattform zu verbieten — schließt die Lücke nicht, denn Marketplaces können auf Bitbucket oder selbst gehosteten Git-Servern laufen, wo solche Namen weiter legal sind (Cyber Security News).

AIRs Zusammenfassung ist die ehrliche: „The fix has to ship in the agent, and updating is the only complete mitigation where one exists" (AIR). Der strukturelle Grund ist für Beschaffungsgespräche eine erneute Erwähnung wert: Der Pin löst im Agenten auf, also kann ein Marketplace die Garantie, die er bewirbt, nicht durchsetzen. Vendor-seitiges Scannen von Marketplace-Uploads (Anthropic hat Skill/Plugin Scanning am 6. August 2026 ausgeliefert) senkt die Wahrscheinlichkeit, dass ein bösartiges Plugin in den Marketplace gelangt, aber es kann die Agent-seitige Checkout-Verifikation nicht ersetzen — der Austausch passiert nach der Review, zum Auflösungszeitpunkt (MCP Security Hardening Checklist). Das ist zugleich das Governance-Exponat: vier Anbieter, ein gemeinsamer Designfehler und eine dreitägige asymmetrische Antwort, die eine kaufende Organisation als die Sicherheits-Patch-Cadence eines Anbieters im Kleinformat lesen kann.

Verifikation nach dem Checkout: die Kontrolle, die verallgemeinert

AIRs Einzeiler schließt beide Varianten (AIR):

test "$(git rev-parse HEAD)" = "" || abort

Die Details tragen die Lektion. git rev-parse HEAD löst auf, was der Working Tree tatsächlich enthält — nicht den Namen, der angefordert wurde. Genau dieser Unterschied ist das, was die Gemini-FETCH_HEAD-Variante durchschlüpft. Und die Prüfung muss im Agenten laufen, weil der Pin auf dem Client aufgelöst wird. Ein Marketplace, der nach dem Checkout verifizieren würde, würde nur seinen eigenen Datensatz verifizieren; der Agent ist die Komponente, die bei Abweichung abbrechen muss.

Dieses Muster — nach der Auflösung verifizieren, nicht davor — verallgemeinert auf jede gepinnte-Artefakt-Kontrolle in einem Agenten-Stack. Eine gepinnte MCP-Server-Version, ein gepinntes Skill, gepinnte Modellgewichte, ein gepinnter Container-Digest: jedes ist eine Behauptung, die ein Installateur zu erfüllen hat und deren Auflösung niemand verifiziert. Dieselbe fehlende Assertion lebt überall dort, wo der Checkout passiert. Vier Posten für diese Woche:

1. Agenten mit Fix aktualisieren. Claude Code auf 2.1.179 oder höher; Codex auf 0.146.0 oder höher. Copilot und Gemini CLI haben keinen Fix — beschränke, was diese Agenten erreichen können (Dateisystem, Credentials, Netzwerk-Egress), bis einer kommt, oder folge dem Migrationspfad des Anbieters.
2. Jedes gepinnte Artefakt inventarisieren. Plugins, Skills, MCP-Server-Versionen, interne Installer. Für jedes bestätigen, ob ein Codepfad die Resolved-HEAD-Assertion überspringt — das schließt interne Tools ein, die dein Team geschrieben hat, nicht nur Vendor-Agenten.
3. Plugin-Repositories auf Übernahme-Signale auditieren. Unerwartete Branch-Änderungen, Default-Branch-Verschiebungen, Eigentümerwechsel. Die 925 gekaperten Skills wurden vor dieser Offenlegung genommen; Repository-Übernahme ist der Einstiegsschritt und operiert bereits im großen Maßstab (Cyber Security News).
4. Plugin-Auto-Update als Supply-Chain-Lieferkanal behandeln, nicht als Bequemlichkeit. Marketplaces und Repositories, aus denen Agenten ziehen dürfen, auf eine Allowlist setzen; Re-Pins hinter erneute Review stellen, wo die Agent-Konfiguration es erlaubt. Die Zero-Click-Eigenschaft kommt vom Auto-Update — entferne das „Null" und der Angriff braucht wieder eine Nutzeraktion.

Zwei benachbarte CVEs und die anhaltende Exposition

Dieselbe Woche brachte zwei MCP-Server-CVEs hervor, die Plugin4Shells Thema teilen — Vertrauen in eine Komponente gesetzt, die ihren Aufrufer nie verifiziert hat. CVE-2026-54618 betrifft Obsidian Web MCP vor 0.2.0: Der OAuth-Authorization-Endpoint stellte Codes an jeden Aufrufer aus, ohne den Nutzer zu authentifizieren, und gewährte einem unauthentifizierten Remote-Angreifer vollständigen Lese-, Schreib-, Such-, Verschiebe- und Löschzugriff auf den gesamten Vault, gefixt in 0.2.0 (Rapid7; GitHub advisory GHSA-hwhg-mrjc-8g43). CVE-2026-54446 ist ein fehlende-Authentifizierung-Flaw (CWE-306) in NetLicensing-MCP (Practical DevSecOps). Sie kommen auf Ökosystem-Basiszahlen obendrauf, die sich seit Monaten nicht bewegt haben: 97M+ monatliche MCP-Downloads, 82 % der gesampelten Server anfällig für Path Traversal, und nur 8,5 % nutzen OAuth (Practical DevSecOps).

Das Muster über alle drei Offenlegungen ist in jeder Schicht des Agenten-Stacks dasselbe: ein Vertrauensmechanismus — ein Pin, ein OAuth-Flow, ein Server-Endpoint —, der seine Prüfung zur falschen Zeit ausführt oder gar nicht. Plugin4Shell ist einfach das erste, das von einem Produkt ins gesamte Ökosystem übersprang.

Weiterführende Lektüre

• MCP Security Hardening Checklist: 1,467 Exposed Servers and the Controls That Close Them — die 12-Kontrollen-Baseline, in die diese Schwachstelle einsortiert: Plugin4Shell gehört in die Supply-Chain-Ebene (Kontrollen 5–7), neben dem Skill/Plugin-Scanning-Update
• Shadow AI Agents: 17,800 Add-Ons, 6.7 Million Installations, and the Runtime Control Gap — das Inventar und die Runtime-Kontrolllücke, die darüber entscheiden, ob ein gekapertes Add-on bemerkt wird
• The First MCP CVE on the KEV List Hit Its Federal Deadline: LiteLLM and the Default-Key Vault — der MCP-CVE, der den föderalen Remediation-Termin erreichte, und die sechs Gateway-Verifikationsposten, die ihn schließen

---

Ein mittelständischer Industriedistributor betreibt Claude Code für interne Tools und einen Beschaffungsagenten, der gegen NetSuite und zwei Lieferantenkataloge quotet. Das Team inventarisiert jedes gepinnte Artefakt auf beiden Flächen, aktualisiert Claude Code auf 2.1.179, deaktiviert das Hintergrund-Auto-Update für Plugins und fügt die Resolved-HEAD-Assertion seinem internen MCP-Modul-Installer hinzu. Plugin-Quellen wandern auf eine Allowlist aus zwei geprüften Repositories, und der Audit-Trail zeichnet jeden Re-Pin mit seinem Diff auf. Der nächste Marketplace-Vorfall wird ein Versionsupdate und eine Review — kein Incident Response.

Baue mit klarem Scope an. Eine Woche Discovery. Du bekommst ein Systeminventar, einen Workflow-Plan und einen festen Scope — ob du mit uns baust oder nicht.