Plugin4Shell: SHA-Pinning schützt nicht

Wer Plugins für seinen Coding-Agenten aus einem Marktplatz installiert, verlässt sich auf eine einfache Zusage: Der Marktplatz pinnt das Plugin auf einen konkreten Commit-Hash, und genau dieser geprüfte Stand landet auf dem Rechner. Die Sicherheitsfirma AIR Security hat am 17.09.2026 gezeigt, dass diese Zusage bei allen vier großen Agenten nicht hielt.

Die Lücke heißt Plugin4Shell. Sie erlaubt Remote Code Execution ohne jeden Klick: Niemand muss etwas bestätigen, neu installieren oder auch nur ein Fenster öffnen. Es reicht, dass ein Plugin aus einem Marktplatz installiert ist, dem man vertraut.

Was das Pinning versprechen sollte

Ein Plugin-Marktplatz prüft ein Plugin und schreibt danach in sein Manifest, welcher Commit gilt. Ein Commit-Hash ist inhaltsadressiert, er lässt sich nicht nachträglich umschreiben. Aus diesem Grund gilt Pinning als solide Absicherung: Der Repo-Besitzer kann hinterher pushen, was er will, der Agent holt weiter den geprüften Stand.

In dieser Logik steckt der Fehler nicht. Er sitzt eine Ebene tiefer: Die Agenten holen den gepinnten Commit, prüfen aber nie nach, ob der Checkout tatsächlich dort gelandet ist. AIR formuliert es so: "The agent checks out the exact commit the marketplace pinned but never verifies it landed there, so an attacker who controls the plugin's repo makes the checkout resolve to malicious code while the pin still looks honored."

Wie der Bypass funktioniert

Der Trick nutzt eine Eigenheit von Git aus. Ein 40-stelliger Hexadezimalstring kann ein Commit-Objekt bezeichnen, er kann aber auch schlicht ein Branchname sein. Wenn beides existiert, gewinnt beim Checkout die Referenz, nicht das Objekt.

flowchart TB
  A["Marktplatz pinnt<br/>Commit-Hash"] --> B{"Was findet Git<br/>beim Checkout?"}
  B -->|"nur das Commit-Objekt"| C["geprüfter Code läuft"]
  B -->|"zusätzlich ein Branch<br/>mit dem Hash als Namen"| D["Referenz schlägt Objekt"]
  D --> E["Schadcode läuft"]
  E --> F["Agent meldet trotzdem<br/>den erwarteten SHA"]
  class C ok
  class E danger
  class F danger
  classDef ok fill:#14532D,stroke:#22C55E,color:#86EFAC
  classDef danger fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5

Bei Claude Code, Codex und Copilot legt der Angreifer dafür einen Branch an, dessen Name der 40-stellige Hash ist, und macht ihn zum Default-Branch. Bei der Gemini CLI läuft es etwas anders: Dort wird der gepinnte Commit zwar geholt, aber git checkout FETCH_HEAD kann sich auf einen gleichnamigen Branch auflösen statt auf den geholten Stand.

Beides setzt voraus, dass die Forge solche Branchnamen überhaupt zulässt. Bitbucket tut das, selbst gehostete Git-Server in der Regel auch. Gefunden haben die Lücke Or Nevo, Dor Granat und Niv Hoffman von AIR Security, bereits im Mai 2026 mit funktionierendem Proof of Concept.

Wer gepatcht hat und wer nicht

Für Claude Code heißt das in der Praxis Entwarnung: Die gepatchte Version ist über drei Monate alt, aktuell steht die 2.1.278. Wer normal aktualisiert, ist längst darüber hinweg. Interessant bleibt trotzdem, wie der Fix ausgeliefert wurde. Im öffentlichen Changelog zu 2.1.179 steht kein Wort von einer Sicherheitslücke, dort finden sich neun Bugfixes zu Scrolling, Spinner und Plugin-Ladezeiten. Ein Advisory hat zum Stand der Berichterstattung keiner der vier Anbieter veröffentlicht, eine CVE-Nummer ist ebenfalls nicht vergeben.

Unangenehmer sieht es bei Copilot aus. The Register verweist darauf, dass fast 90 Prozent der Fortune-500-Unternehmen Copilot einsetzen. Ein GitHub-Sprecher hält dagegen, das Problem stelle sich dort gar nicht: "GitHub does not allow users to create branch or tag names that resemble commit SHAs." Das deckt sich mit dem Befund von AIR, dass GitHub 40-stellige Hex-Branchnamen blockt. Nur schützt das eben nur Plugins, die auf GitHub liegen. Für Bitbucket-Repos und selbst gehostete Server gilt es nicht, und die Forscher widersprechen der Darstellung entsprechend.

Was das für den eigenen Stack heißt

Ein bekannter Ausnutzungsfall ist nicht dokumentiert, und heise hält ausdrücklich fest, dass keiner bekannt ist. Die Mechanik bleibt trotzdem lehrreich, weil sie ein Muster zeigt, das nicht nur Plugins betrifft.

Der Pin war nie falsch. Der Agent hat den richtigen Hash angefragt, ihn korrekt ins Log geschrieben und die Installation als erfolgreich gemeldet. Verifiziert hat er nur nicht, was danach im Arbeitsverzeichnis lag. Wer selbst Automatisierung baut, die Code nach Hash auscheckt, kennt die Gegenmaßnahme: nach dem Checkout git rev-parse HEAD gegen den erwarteten Hash prüfen, statt der Ausgabe des Clone-Befehls zu glauben.

Für den Alltag im Team bleiben drei Punkte:

• Agenten aktuell halten ist eine Sicherheitsmaßnahme, kein Komfortthema. Das gilt gerade, weil man einem Changelog wie dem zu 2.1.179 nicht ansieht, dass eine kritische Lücke mit drinsteckt.
• Plugins aus Marktplätzen sind Abhängigkeiten wie jede andere. Sie laufen mit den Rechten des Agenten, und der hat meist Repo-Zugriff, Shell und Netz. Wir haben das bei SkillCloak und bei gefälschten JetBrains-Plugins schon von anderer Seite gesehen.
• Copilot-Nutzer sollten den Status im Auge behalten. Solange Microsoft nichts ausliefert, ist die Herkunft installierter Plugins die einzige Stellschraube, die im eigenen Haus liegt.

Wie man Coding-Agenten so aufsetzt, dass ein kompromittiertes Plugin nicht gleich den ganzen Rechner mitnimmt, steht in Coding-Agenten im Team sicher betreiben.