Kritische RCE-Schwachstelle in Serena, einem beliebten MCP-Coding-Agenten

Serena, einer der meistgenutzten KI-Coding-Agenten, führte fremden Code aus, sobald ein Projekt geöffnet wurde. Die Threat Research Group von GitLab hat eine kritische Server-Side Template Injection gefunden (GHSA-pp25-4cg4-qcr9, CVE ausstehend), die beliebigen Code im Serena-Prozess ausführt. Wer serena-agent 1.6.1 oder älter einsetzt, sollte umgehend auf 1.7.0 aktualisieren.

Ausnutzen lässt sich das, indem eine Angreiferseite eine bösartige Datei .serena/project.yml in einem selbst kontrollierten Repository versteckt und jemanden dazu bringt, dieses Repository über den Serena-MCP-Server (Model Context Protocol) zu öffnen. Die Lücke umgeht trusted_project_path_patterns, also genau die Kontrolle, die Serena eingebaut hat, um Code-Ausführung aus nicht vertrauenswürdigen Repositorys zu verhindern. Wir haben den Fund am 1. August 2026 vertraulich gemeldet, acht Tage später lag der Fix vor.

Das ist ein frühes Beispiel für eine Risikoklasse, die sich ausbreiten wird, während MCP-Server fester im Software-Lebenszyklus verankert werden.

MCP-Server – eine Angriffsfläche der anderen Art

Die meisten Entwicklungswerkzeuge greifen nur eng umgrenzt auf eine Codebasis zu: Ein Linter liest Dateien, ein Formatter schreibt sie, ein Test-Runner führt ein bestimmtes Harness aus. MCP-Server dagegen geben einem großen Sprachmodell (LLM) eine Allzweckschnittstelle zur Umgebung der entwickelnden Person, mit Dateisystemzugriff, Shell-Ausführung, Language-Server-Abfragen und mitunter Netzwerkzugang. Dieselbe Reichweite, die sie nützlich macht, wiegt schwer, sobald der Serverprozess kompromittiert ist.

CI/CD-Pipelines laufen in isolierten Umgebungen mit eng gefassten Zugangsdaten. MCP-Server laufen auf dem Rechner der entwickelnden Person, in deren Benutzerkontext, mit Zugriff auf alles, was diese Person erreicht: SSH-Schlüssel, Zugangsdaten für Cloud-Anbieter, .env-Dateien, Browser-Sitzungen und interne Netzwerkressourcen. Wer den Serverprozess kompromittiert, kompromittiert die gesamte lokale Umgebung.

Entwicklungsteams richten diese Server ständig auf Repositorys, die sie nicht selbst geschrieben haben: beim Prüfen einer neuen Open-Source-Bibliothek, beim Triagieren eines Fehlerberichts oder beim Review eines fremden Branches. Verarbeitet der Server irgendetwas aus diesem Repository, bevor es jemand angesehen hat, öffnet sich ein Zeitfenster für Angriffe. Serena benennt diese Bedrohung ausdrücklich und liefert ein Vertrauensmodell mit, das Code-Ausführung aus nicht vertrauenswürdigen Repositorys verhindern soll. Dieses Vertrauensmodell hatte eine Lücke.

Wie die Schwachstelle funktioniert

Was Serena ist

Serena beschreibt sich selbst als "die IDE für deinen Agenten". Das Werkzeug verbindet Claude, Cursor, Copilot und andere KI-Assistenzen über MCP mit einer lokalen Codebasis und bietet semantische Code-Navigation, Refactoring und Bearbeitungswerkzeuge, die über das hinausgehen, was ein reines Dateisystem einem LLM liefert. Betrieben wird es als lokaler MCP-Server, auf den die Assistenz gerichtet wird:

      serena start-mcp-server --project /path/to/repo

    

Weil Serena auf beliebigen lokalen Repositorys mit den vollen Betriebssystemrechten der Nutzenden arbeitet, bringt es eine Vertrauensprüfung mit. trusted_project_path_patterns legt fest, welche Projektpfade als vertrauenswürdig gelten, und nur vertrauenswürdige Projekte dürfen privilegierte Funktionen nutzen wie activation_command, das beim Öffnen eines Projekts einen Shell-Befehl ausführt. Die beabsichtigte Zusicherung: Ein nicht vertrauenswürdiges Repository zu öffnen, ist ungefährlich.

Die Senke: eine Template-Engine ohne Sandbox

Serena erlaubt jedem Projekt, eigene Modes zu definieren, also benannte Konfigurationen mit einem Feld prompt, das bei aktivem Projekt in den System-Prompt des LLM eingefügt wird. Serena rendert diese Prompts als Jinja2-Templates, und genau dieses Rendern ist das Problem. In src/interprompt/jinja_template.py:

      # line 22
self._env = jinja2.Environment()

    

jinja2.Environment() ist eine schlichte Umgebung ohne Sandbox. Sie stellt eingebaute Globals bereit, deren Attribute sich über Pythons Objektgraphen bis zu os und subprocess verketten lassen. Die Techniken, um von diesem Ausgangspunkt zu beliebiger Code-Ausführung zu gelangen, sind gut dokumentiert und erfordern kein Spezialwissen. Jinja2 liefert genau dafür eine SandboxedEnvironment mit, die hier aber nicht verwendet wurde.

Der Transportweg: Projektkonfiguration als nicht vertrauenswürdige Eingabe

Die Datei .serena/project.yml eines Projekts unterstützt ein Feld added_modes, das zusätzliche Modes auflistet, die beim Öffnen des Projekts aktiviert werden. Serenas Mode-Loader behandelt jeden Namen, der einen Pfadtrenner enthält oder auf .yml endet, als direkt zu ladenden Dateipfad:

      # context_mode.py, lines 29-30
def looks_like_yaml_path(s: str) -> bool:
    return os.sep in s or (os.altsep and os.altsep in s) or s.lower().endswith((".yml", ".yaml"))

# context_mode.py, lines 130-135
@classmethod
def load(cls, name_or_path: str | Path) -> Self:
    if isinstance(name_or_path, Path) or looks_like_yaml_path(str(name_or_path)):
        return cls.from_yaml(name_or_path)
    ...

    

Ein pfadartiger Eintrag in added_modes bringt Serena dazu, diese Datei aus dem Repository zu laden, ihr Feld prompt unverändert zu lesen und an den Renderer ohne Sandbox zu übergeben. yaml.safe_load wird korrekt eingesetzt und blockiert Deserialisierungs-Gadgets in YAML, spielt für eine schlichte Zeichenkette im Feld prompt aber keine Rolle. Der YAML-Parser sieht harmlosen Text. Die Injection geschieht später, wenn diese Zeichenkette als Jinja2-Template kompiliert wird.

Die Umgehung der Vertrauensprüfung

is_trusted(), Serenas Mechanismus gegen Code-Ausführung aus nicht vertrauenswürdigen Projekten, sichert zwei Funktionen ab: activation_command, den beim Öffnen ausgeführten Shell-Befehl, und ls_specific_settings, projektbezogene Werkzeugüberschreibungen. Der Pfad über Mode-Laden und Prompt-Rendering wird nie gegen is_trusted() geprüft. Die Liste added_modes aus der .serena/project.yml eines Projekts wird ohne Validierung verarbeitet, und der Mode-Loader wendet weder eine Allowlist noch eine Vertrauensprüfung an, bevor er die Datei lädt und das Feld prompt an die Template-Engine übergibt.

Die Umgehung haben wir empirisch bestätigt. Wir haben denselben End-to-End-Test mit leerem trusted_project_path_patterns gefahren, sodass kein Projekt als vertrauenswürdig gilt, also strenger als jede Standardkonfiguration. Zweierlei geschah:

Die Funktion, deren einziger Zweck das Ausführen eines Shell-Befehls ist, wird blockiert. Die Template Injection erreicht dasselbe Ergebnis über einen anderen Weg und läuft ungehindert. Damit handelt es sich um ein Versagen des Schutzmechanismus (CWE-693). Das Vertrauensmodell existiert, um Code-Ausführung aus einem nicht vertrauenswürdigen Repository zu verhindern, und dieser Pfad hebelt es aus, während es aussieht, als werde nur ein Projekt geladen.

Die vollständige Aufrufkette

      .serena/project.yml  (attacker-controlled, ships with the repo)
  added_modes: ["./path/to/attacker-mode.yml"]
        |
        v
SerenaAgentMode.load()            context_mode.py:130-135
  from_yaml(name_or_path)
  prompt = <attacker-controlled string>
        |
        v
SerenaAgent._update_active_modes()    agent.py:1063
        |
        v
create_system_prompt()                agent.py:996
  _format_prompt(mode.prompt)
  JinjaTemplate(prompt).render()      arbitrary code execution

    

Der Code läuft nebenbei, wenn ein Projekt ganz normal geöffnet wird, und zwar bevor Serena die erste Anfrage an das LLM bedient.

Verbreitung

Serenas Reichweite im Entwicklungsökosystem ist beträchtlich. Das Repository zählt 27,8k Sterne und 1,8k Forks, und das Paket serena-agent verzeichnet auf PyPI rund 136.000 Downloads pro Monat. Es lässt sich mit Claude Code, Cursor, VS Code, JetBrains-IDEs, Claude Desktop und OpenWebUI einbinden und deckt damit die gängigen Umgebungen für KI-gestützte Entwicklung ab.

Ein realistischer Angriff braucht weder Infrastruktur noch Social Engineering über das Repository hinaus. Jemand veröffentlicht eine Bibliothek, ein Beispielprojekt, eine CTF-Aufgabe oder ein scheinbar nützliches Werkzeug. Eine entwickelnde Person klont es, öffnet es mit Serena, und der Code läuft. Angesichts dessen, was ein Entwicklungsrechner alles erreicht, zahlt sich der Angriff sofort aus. Wo Serena in einem CI/CD-Aufbau eingereichte Repositorys automatisch verarbeitet, braucht es überhaupt keine menschliche Beteiligung.

Warum neue Werkzeuge alte Fehler erben

Keines der Muster hinter diesem Fehler ist Serena-spezifisch.

Von Nutzenden gelieferte Daten flossen ohne Sandbox in eine Template-Engine. Template Injection gehört zu den ältesten Schwachstellenklassen der Web-Sicherheit, und die meisten Template-Engines liefern dagegen eine Sandbox oder einen eingeschränkten Modus mit. In einem jungen Ökosystem greifen Entwicklungsteams beim Bau konfigurationsgetriebener Templating-Funktionen oft standardmäßig zur schlichten Variante. Dieses Muster wird in weiteren MCP-Werkzeugen auftauchen.

Projektkonfigurationsdateien wurden als vertrauenswürdige Eingabe behandelt. Die Konfigurationsdateien eines Repositorys stammen von dessen Eigentümerschaft. In jedem Bedrohungsmodell, in dem das Repository nicht vertrauenswürdig sein kann, sind diese Dateien von der Angreiferseite kontrollierte Eingaben. Diese Unterscheidung übersieht man leicht, wenn man ein Werkzeug baut und sich die Konfigurationsdateien wie ein Teil davon anfühlen.

Die Vertrauensprüfung deckte einige Codepfade ab, andere nicht. Serenas Vertrauensmodell war richtig entworfen: Die Prüfung existiert, sie ist umgesetzt, und die abgedeckten Funktionen sind klar benannt. Die Lücke war ein Codepfad, der hinzukam, ohne unter dieselbe Prüfung gestellt zu werden. Damit ein Vertrauensmodell lückenlos bleibt, während die Codebasis wächst, muss jeder neue Pfad geprüft werden, der projektgelieferte Eingaben verarbeitet, nicht nur die offensichtlich privilegierten.

Was daraus folgt

Wer Serena einsetzt

Umgehend auf serena-agent 1.7.0 aktualisieren. Der Fix stellt die Template-Engine auf jinja2.sandbox.SandboxedEnvironment um und schließt damit den Injection-Pfad. Unter Version 1.6.1 und älter gilt: keine Repositorys aus nicht vertrauenswürdigen Quellen öffnen.

Wer MCP-Server oder KI-Coding-Werkzeuge baut

Diese Praktiken gelten für jedes Werkzeug, das ein Projektverzeichnis für ein LLM ausliest.

• Projektkonfigurationsdateien als Eingabe einer möglicherweise feindseligen Eigentümerschaft behandeln. Sie wie einen HTTP-Request-Body validieren: Struktur prüfen und alles zurückweisen, was vom Schema abweicht.
• Jede Stelle kartieren, an der aus einer Zeichenkette Code oder ein Befehl wird: Template-Rendering, Subprozessaufrufe, Plugin-Laden, dynamische Importe. Für jede davon wissen, ob Projekteingaben sie erreichen und was das verhindert.
• Die Vertrauensprüfung über jeden Pfad legen, nicht über eine einzelne Funktion. Es bei jeder neuen Funktion prüfen, die Projekteingaben liest.
• Vor der Auslieferung gegen ein feindseliges Repository testen. Die aggressivste Konfiguration bauen, die geht, sicherstellen, dass beim Öffnen nichts läuft, und das automatisieren.

Wer ein Security-Team leitet

MCP-Server bilden eine neue lokale Angriffsfläche und laufen dabei im vollen Benutzerkontext der Entwicklungsteams. Sie gehören deshalb wie jedes andere privilegierte Werkzeug auf diesen Rechnern behandelt. Der erste Schritt ist herauszufinden, welche MCP-Server in der eigenen Umgebung laufen und wo. Im großen Maßstab verlangt das womöglich eigene Werkzeuge und Richtlinien. Danach gilt für Updates von MCP-Servern dieselbe Sorgfalt wie überall sonst: Eine Schwachstelle in einem MCP-Server ist eine Schwachstelle auf jedem Rechner, der ihn ausführt. Bei der Bewertung neuer MCP-Werkzeuge lohnt die Frage nach dem Vertrauensmodell des Anbieters und danach, wie er es gegen nicht vertrauenswürdige Projekteingaben testet.

Zeitleiste der Offenlegung

Wir danken den Serena-Maintainern für die zügige und kooperative Bearbeitung der Meldung.

Wie GitLab unterstützen kann

Der GitLab Duo Security Agent kann dabei helfen, die eigene Codebasis auf dieselben Muster zu prüfen. Fragen wie "Rendert dieses Projekt von Nutzenden kontrollierte Zeichenketten über eine Template-Engine?" oder "Gibt es in diesem Repository Konfigurationsdateien, die in einen Ausführungskontext gelangen?" sind ein praktischer Anfang.

Ausblick

Das MCP-Ökosystem steht ungefähr dort, wo das npm-Ökosystem vor einem Jahrzehnt stand: schnell wachsend, die Verbreitung eilt der sicherheitstechnischen Prüfung voraus, und Vertrauensannahmen bleiben unausgesprochen. Der Serena-Fund ist gewöhnlich, und genau das ist der Punkt. Es ist die Art von Problem, die auftritt, wann immer eine neue Technik schneller reift als die Sicherheitsmuster um sie herum, und MCP reift schnell. Wir rechnen mit mehr davon, je selbstverständlicher MCP-Server zur Infrastruktur der Entwicklung werden.

Die Threat Research Group von GitLab wird KI-Entwicklungswerkzeuge weiter untersuchen und Funde teilen, sobald sie verantwortungsvoll offengelegt sind. Wir ermutigen Forschende, MCP-Server mit derselben Gründlichkeit zu prüfen, mit der die Sicherheits-Community seit Langem Browser-Erweiterungen, IDE-Plugins und CI/CD-Integrationen betrachtet: Werkzeuge, die mit erheblichen Rechten auf Entwicklungsrechnern laufen und Daten aus Quellen verarbeiten, die sie nicht vollständig kontrollieren.