Mon scanner de sécurité MCP a manqué le pire MCP RCE de 2026: Voici la solution à une règle

L'hameçon Quelques mois plus tard, j'ai expédié , un analyseur statique qui scanne les serveurs MCP (Model Context Protocol) pour les classes de vulnérabilité qui continuent d'apparaître dans cet écosystème : injection de commande, SSRF, et traversée de chemin. La règle était censée être le chemin de passage. Cette semaine, je me suis assis avec mes propres notes de recherche et j'ai fait un simple contrôle de l'intestin : le MCP007 aurait-il pris les quatre CVE réels de trajectoire divulgués sur les serveurs MCP cette année ? Il aurait manqué chacun d'eux. Y compris le pire. Contexte réel Voici ce qui a effectivement été expédié en 2026 en tant que CVE, tous dans les serveurs MCP, tous partageant la même cause racine: CVE Server Sink Impact CVE-2026-40576 excel-mcp-server file write Path traversal CVE-2026-84201 appium-mcp-server Path traversal CVE-2026-44336 PraisonAI MCP Python écrire RCE par injection de paquets de sites CVE-2026-27825 mcp-atlassian CVSS 9.1, RCE non authentifié (enchaîné avec SSRF CVE-2026-27826 pour écraser ou laisser tomber une entrée de cron) Quatre mainteneurs différents, quatre outils différents, exactement le même point mort : un chemin de fichier construit à partir d'entrées contrôlées par l'appelant, écrit sans vérification de la limite de répertoire. Le bug est le plus nast : aucune auth nécessaire, aucun redémarrage nécessaire, directement sur un shell. J'ai donc ouvert mon propre fichier de règles et lu le docstring à haute voix: Le voilà. Ma règle était prévue pour lire dès le premier jour, et chaque exploit réel cette année s'est produit du côté de l'écriture. Un scanner dont tout le travail est d'attraper cette classe de bugs était structurellement aveugle à la moitié de celui qui est en fait l'atterrissage CVSS 9+ scores. Architecture: comment fonctionne le MCP007 Les règles dans sont simples sur le but: line-scan regex matching sans AST, donc ils courent rapidement sur n'importe quelle langue mcpscan prend en charge. Chaque règle comporte trois calques régex : Le regex original de l'évier, à partir de : Notice : est là, mais celui de Python est aussi l'évier d'écriture (). Le régex ne se soucie pas du mode, donc en théorie certains écrit déjà glisser à travers. Mais, , , , et n'étaient pas du tout assortis. C'est l'écart réel qui laisse passer la forme de CVE-2026-27825. Étape par étape : la correction Depuis et déjà faire ce qui est nécessaire (détecter un chemin construit dynamiquement et escalader la sévérité lorsqu'un repère littéral apparaît), la correction est additive : un second modèle d'évier, réutiliser le même pipeline de détection. 1. Ajouter write-sink regexes à côté des regexes lus: 2. Vérifiez les deux familles d'évier par ligne, pas seulement un: J'ai frappé write-sink directement à même sans un littéral . Un chemin de destination contrôlé par l'attaquant est un chemin de source moins primitif qu'un chemin contrôlé par l'attaquant, parce que la charge utile se déplace habituellement dans la même demande (comme vu dans ). 3. Prouvez-le contre la forme réelle. Déposez ceci dans un montage et exécutez le scanner : Avant le patch, ce montage a produit zéro résultat. C'est tout le bug, en un seul diff. L'ambiguïté du mode Gotchas et des cas de bord. est techniquement lu et écrit. Je n'ai pas essayé d'analyser les chaînes de mode complexes. Le regex correspond également , , modes (avec option ) comme signal supplémentaire , et double matches contre sont inoffensifs parce que est un tuple vérifié dans l'ordre avec . Faux positifs sur légitime atomique écrit. Le code qui court va maintenant s'afficher, correctement. C'est encore un chemin de destination non validé, même si ce n'est qu'un suffixe de tempfile. Ne supprimez pas cela ; validez plutôt le chemin de base. L'inflation de gravité. L'escalade de tous les hits d'écriture à HAUT (pas seulement ceux avec un littéral ) produira plus de HAUTes découvertes qu'auparavant. C'est intentionnel compte tenu des données du CVE. Si vous fourchez ceci, attendez-vous à ce que votre retard de triage augmente, ce qui est le point. Les limites de Regex. Il n'attrapera toujours pas un chemin construit à trois fonctions loin de l'évier. C'est une véritable limitation de toute la règle, pas quelque chose que ce patch corrige. Il est intéressant de noter dans votre propre documentation afin que les utilisateurs ne placent pas aveugle confiance dans un scan propre. Prises de décisions Si vous maintenez un scanner de sécurité, revenez périodiquement sur votre propre liste de CVE réels récents. Les règles dérivent silencieusement: rien ne se brise, il arrête simplement tranquillement d'attraper le vulner