Exécution critique de code à distance dans Serena, un agent de codage MCP très répandu

Serena, l'un des agents d'IA pour le code les plus utilisés, exécutait du code fourni par un attaquant dès qu'un développeur ouvrait un projet. Le Threat Research Group de GitLab a découvert une injection de template côté serveur critique (GHSA-pp25-4cg4-qcr9, CVE en attente) qui exécute du code arbitraire dans le processus Serena. Toute personne utilisant serena-agent 1.6.1 ou une version antérieure doit le mettre à jour vers la version 1.7.0 immédiatement.

Un acteur malveillant peut exploiter cette vulnérabilité en dissimulant un fichier .serena/project.yml malveillant dans un dépôt qu'il contrôle, puis en incitant un développeur à l'ouvrir via le serveur Model Context Protocol (MCP) de Serena. La faille contourne trusted_project_path_patterns, le mécanisme que Serena a spécifiquement conçu pour empêcher les dépôts non fiables d'exécuter du code. Nous avons signalé cette vulnérabilité de manière confidentielle le 1er août 2026, et les chargés de maintenance ont publié un correctif huit jours plus tard.

Il s'agit d'un exemple précoce d'une catégorie de risques qui est vouée à se répandre à mesure que les serveurs MCP s'intégreront dans le cycle de développement logiciel.

Les serveurs MCP, une surface d'attaque à part entière

La plupart des outils de développement interagissent avec un code source de manière ciblée : un linter lit des fichiers, un formateur les modifie, et un outil de test exécute un harnais spécifique. Les serveurs MCP, en revanche, fournissent à un grand modèle de langage (LLM) une interface polyvalente vers l'environnement du développeur, qui couvre l'accès au système de fichiers, l'exécution de commandes shell, les requêtes vers le serveur de langage, et parfois le réseau. Leur utilité tient précisément à cette portée, et toute compromission du processus serveur devient un incident majeur.

Les pipelines CI/CD s'exécutent dans des environnements isolés avec des identifiants à portée limitée. Les serveurs MCP, eux, tournent sur la machine du développeur, dans son propre contexte utilisateur, avec accès à tout ce que le développeur peut atteindre : clés SSH, identifiants de fournisseurs cloud, fichiers .env, sessions de navigateur et ressources réseau internes. Compromettre le processus serveur signifie compromettre l'intégralité de l'environnement local du développeur.

Les développeurs pointent régulièrement ces serveurs vers des dépôts qu'ils n'ont pas écrits pour évaluer une nouvelle bibliothèque open source, analyser un rapport de bogue ou examiner la branche d'un contributeur. Si le serveur traite des éléments de ce dépôt avant que le développeur ne les inspecte, l'attaquant dispose d'une fenêtre d'opportunité. Serena ne cache rien de cette menace et intègre un modèle de confiance pour empêcher les dépôts non fiables d'exécuter du code, mais ce modèle présentait une lacune.

Fonctionnement de la vulnérabilité

Présentation de Serena

Serena se décrit comme « l'IDE pour votre agent ». Il connecte Claude, Cursor, Copilot et d'autres assistants d'IA à un code source local via MCP, en fournissant des outils de navigation sémantique du code, de refactorisation et de modification qui vont au-delà de ce qu'un système de fichiers brut offre à un LLM. Les équipes de développement l'exécutent comme un serveur MCP local et y pointent leur assistant :

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

    

Étant donné que Serena opère sur des dépôts locaux arbitraires avec les privilèges complets de l'utilisateur sur le système d'exploitation, il intègre une porte de confiance. trusted_project_path_patterns contrôle quels chemins de projet sont considérés comme fiables, et seuls les projets fiables peuvent utiliser des fonctionnalités privilégiées telles qu'activation_command, qui exécute une commande shell à l'ouverture du projet. La porte de confiance vise à garantir l'ouverture d'un dépôt non fiable sans danger.

Le puits : un moteur de template non isolé

Serena permet à chaque projet de définir des modes personnalisés, soit des configurations nommées avec un champ prompt injecté dans le prompt système du LLM lorsque le projet est actif. Serena rend ces prompts sous forme de templates Jinja2, et c'est ce rendu qui pose problème. Dans src/interprompt/jinja_template.py :

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

    

jinja2.Environment() est un environnement simple, non isolé. Il expose des variables globales intégrées dont les attributs remontent à travers le graphe d'objets Python jusqu'à os et subprocess. Les techniques permettant d'atteindre une exécution de code arbitraire depuis ce point de départ sont bien documentées et ne requièrent aucune connaissance spécialisée. Jinja2 fournit SandboxedEnvironment précisément pour cette raison, mais il n'a pas été utilisé ici.

Le vecteur de livraison : la configuration de projet comme entrée non fiable

Le fichier .serena/project.yml d'un projet prend en charge un champ added_modes, qui liste les modes supplémentaires à activer à l'ouverture du projet. Le chargeur de modes de Serena traite tout nom contenant un séparateur de chemin ou se terminant par .yml comme un chemin vers un fichier à charger directement :

      # 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)
    ...

    

Une entrée ressemblant à un chemin dans added_modes amène Serena à charger ce fichier depuis le dépôt, à lire son champ prompt tel quel, puis à le transmettre au moteur de rendu non isolé. yaml.safe_load est utilisé correctement et bloque les gadgets de désérialisation YAML, mais cela n'a aucune incidence sur une chaîne de caractères ordinaire dans le champ prompt. L'analyseur YAML voit un texte inoffensif. L'injection se produit plus tard, lorsque cette chaîne est compilée comme template Jinja2.

Le contournement de la porte de confiance

is_trusted(), le mécanisme de Serena pour empêcher les projets non fiables d'exécuter du code, soumet deux fonctionnalités à une porte de confiance : activation_command, la commande shell exécutée à l'ouverture du projet, et ls_specific_settings, les remplacements d'outils propres au projet. Le chemin de chargement des modes et de rendu des prompts n'est jamais vérifié par is_trusted(). La liste added_modes du fichier .serena/project.yml d'un projet est traitée sans validation, et le chargeur de modes n'applique ni liste d'autorisation ni vérification de confiance avant de charger le fichier et de transmettre le champ prompt au moteur de template.

Nous avons confirmé ce contournement de manière empirique. Nous avons exécuté le même test de bout en bout avec trusted_project_path_patterns défini comme vide, de sorte qu'aucun projet ne soit considéré comme fiable (une configuration plus stricte que tout paramètre par défaut). Nous avons observé deux résultats :

La fonctionnalité dont le seul but est d'exécuter une commande shell est bloquée. L'injection de template atteint le même résultat par un chemin différent et s'exécute librement. Il s'agit d'un échec du mécanisme de protection (CWE-693). Le modèle de confiance existe pour empêcher un dépôt non fiable d'exécuter du code, et ce chemin le contourne tout en ressemblant à un chargement de projet ordinaire.

La chaîne d'appel complète

      .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

    

Le code s'exécute comme effet secondaire du processus ordinaire d'ouverture de projet, avant que Serena ne serve sa première requête au LLM.

Exposition

Serena est très présent dans l'écosystème des développeurs. Le dépôt compte 27 800 étoiles GitHub et 1 800 duplications, et le paquet serena-agent enregistre environ 136 000 téléchargements par mois sur PyPI. Il s'intègre avec Claude Code, Cursor, VS Code, les IDE JetBrains, Claude Desktop et OpenWebUI, et couvre ainsi l'ensemble des environnements de développement assisté par IA couramment utilisés.

Une attaque réaliste ne nécessite aucune infrastructure ni ingénierie sociale au-delà du dépôt lui-même. Un attaquant publie une bibliothèque, un exemple de projet, un défi CTF ou un outil en apparence utile. Un développeur le clone, l'ouvre avec Serena, et le code s'exécute. Compte tenu de tout ce qu'une machine de développeur peut atteindre, le gain pour l'attaquant est immédiat. Dans un environnement CI/CD où Serena traite automatiquement des dépôts soumis, aucune interaction humaine n'est requise.

Pourquoi les nouveaux outils héritent d'anciens bogues

Aucun des schémas à l'origine de ce bogue n'est propre à Serena.

Des données fournies par l'utilisateur ont été transmises à un moteur de template sans isolation. L'injection de template est l'une des catégories de vulnérabilités les plus anciennes en sécurité web, et la plupart des moteurs de template proposent un environnement isolé ou restreint pour y remédier. Dans un jeune écosystème, les développeurs qui créent des fonctionnalités de template piloté par la configuration ont souvent recours à la variante simple par défaut. Ce schéma se reproduira dans d'autres outils MCP.

Les fichiers de configuration du projet ont été traités comme des entrées fiables. Les fichiers de configuration d'un dépôt sont rédigés par le propriétaire de ce dépôt. Dans tout modèle de menace où le dépôt peut être non fiable, ces fichiers constituent des entrées contrôlées par l'attaquant. Cette distinction est facile à négliger lorsqu'on développe un outil et que les fichiers de configuration semblent faire partie de l'outil lui-même.

Les portes de confiance couvraient certains chemins de code, mais pas d'autres. Le modèle de confiance de Serena était conçu correctement : la porte existe, elle est implémentée, et les fonctionnalités qu'elle couvre sont clairement identifiées. La lacune concernait un chemin de code ayant été ajouté sans avoir été soumis à la même porte. Maintenir une couverture de confiance complète à mesure qu'un code source évolue exige un examen délibéré de chaque nouveau chemin traitant des entrées fournies par le projet, et pas seulement des chemins manifestement privilégiés.

Ce que cela signifie pour vous

Si vous utilisez Serena

Mettez à jour Serena vers serena-agent 1.7.0 immédiatement. Le correctif remplace le moteur de template par jinja2.sandbox.SandboxedEnvironment, ce qui ferme le chemin d'injection. Sur les versions 1.6.1 et antérieures, évitez d'ouvrir des dépôts provenant de sources non fiables.

Si vous développez des serveurs MCP ou des outils de codage alimentés par l'IA

Les bonnes pratiques ci-dessous s'appliquent à tout outil qui lit un répertoire de projet pour un LLM.

• Traitez les fichiers de configuration de projet comme des entrées provenant d'un propriétaire de dépôt potentiellement hostile. Validez-les comme un corps de requête HTTP : vérifiez la structure et rejetez tout ce qui ne correspond pas au schéma attendu.
• Identifiez chaque endroit où une chaîne de caractères devient du code ou une commande : rendu de template, appels de sous-processus, chargement de plug-ins, imports dynamiques. Pour chacun, déterminez si une entrée de projet peut l'atteindre et ce qui l'en empêche.
• Assurez-vous que votre porte de confiance couvre tous les chemins, et non une seule fonctionnalité. Réexaminez-la chaque fois que vous ajoutez une fonctionnalité qui lit des données d'entrée de projet.
• Testez votre outil face à un dépôt hostile avant de le publier. Construisez la configuration la plus agressive possible, confirmez qu'aucun code ne s'exécute à l'ouverture et automatisez ce test.

Si vous dirigez une équipe de sécurité

Les serveurs MCP constituent une nouvelle catégorie de surface d'attaque locale qui s'exécute avec le contexte utilisateur complet de vos développeurs ; traitez-les comme tout autre outil privilégié sur ces machines. Commencez par identifier quels serveurs MCP s'exécutent dans votre environnement et où. À grande échelle, cela peut nécessiter des outils et des politiques dédiés. Appliquez ensuite aux mises à jour des serveurs MCP le même niveau de vigilance que vous appliquez ailleurs : une vulnérabilité dans un serveur MCP est une vulnérabilité sur chaque machine qui l'exécute. Lorsque vous évaluez de nouveaux outils MCP, interrogez le fournisseur sur son modèle de confiance et sur la manière dont il le teste face à des entrées de projet non fiables.

Calendrier de divulgation

Nous remercions les chargés de maintenance de Serena pour leur traitement rapide de ce rapport et pour leur collaboration.

Comment GitLab peut vous aider

L'agent Security Analyst de GitLab Duo peut vous aider à auditer votre code source pour détecter les mêmes schémas. Des questions telles que « ce projet rend-il des chaînes contrôlées par l'utilisateur via un moteur de template ? » ou « existe-t-il des fichiers de configuration dans ce dépôt qui sont transmis à un contexte d'exécution ? » constituent un point de départ concret.

Perspectives

L'écosystème MCP se trouve aujourd'hui à peu près là où se trouvait l'écosystème npm il y a dix ans : en croissance rapide, avec une adoption qui dépasse la vigilance en matière de sécurité, et des hypothèses de confiance implicites. La découverte concernant Serena est ordinaire : il s'agit justement du type de problème qui apparaît chaque fois qu'une nouvelle technologie mûrit plus vite que les pratiques de sécurité qui l'entourent, et le MCP mûrit rapidement. Nous nous attendons à voir davantage de cas similaires à mesure que les serveurs MCP deviendront une infrastructure standard pour les développeurs.

Le Threat Research Group de GitLab continuera d'évaluer les outils de développement d'IA et de partager ses découvertes au fur et à mesure de leur divulgation responsable. Nous encourageons les chercheurs à appliquer aux serveurs MCP le même niveau de vigilance que la communauté de sécurité applique depuis longtemps aux extensions de navigateur, aux plug-ins d'IDE et aux intégrations CI/CD : des outils qui s'exécutent avec des privilèges significatifs sur les machines des équipes de développement et traitent des données provenant de sources qu'ils ne contrôlent pas entièrement.