Mein MCP Security Scanner verpasste 2026 den schlechtesten MCP RCE: Hier ist der One-Rule Fix

Vor ein paar Monaten habe ich einen statischen Analysator ausgeliefert, der MCP-Server (Model Context Protocol) nach den Schwachstellenklassen scannt, die in diesem Ökosystem immer wieder auftauchen: Befehlseinspritzung, SSRF und Pfadtraversal. Die Regel sollte der Weg sein, der alles erfasst. Diese Woche setzte ich mich mit meinen eigenen Forschungsnotizen hin und führte einen einfachen Gut-Check durch: Hätte MCP007 die vier echten Pfad-Traversal-CVEs gefangen, die in diesem Jahr gegen MCP-Server offengelegt wurden? Es hätte jeden einzelnen vermisst. Einschließlich des Schlimmsten. Realer Kontext Hier ist, was tatsächlich als CVEs im Jahr 2026 ausgeliefert wurde, alle in MCP-Servern, die alle die gleiche Ursache haben: CVE Server Sink Impact CVE-2026-40576 excel-mcp-server-Datei schreiben Path traversal CVE-2026-84201 appium-mcp-server Path traversal CVE-2026-44336 PraisonAI MCP Python schreiben RCE über Site-Pakete Injektion CVE-2026-27825 mcp-atlassian CVSS 9.1, nicht authentifiziert RCE (gekettet mit SSRF CVE-2026-27826 zu überschreiben oder fallen einen Cron-Eintrag) Vier verschiedene Maintainer, vier verschiedene Tools, genau derselbe blinde Fleck: ein Dateipfad, der aus von Anrufern gesteuerten Eingaben aufgebaut ist, die ohne Verzeichnis-Grenzprüfung geschrieben wurden. Der Bug ist der übelste: kein Auth benötigt, kein Neustart erforderlich, direkt zu einer Shell. Also öffnete ich meine eigene Regeldatei und las die Docstring laut vor: Da ist sie. Meine Regel wurde vom ersten Tag an auf Lesungen angewendet, und jeder reale Exploit in diesem Jahr geschah auf der Schreibseite. Ein Scanner, dessen gesamte Aufgabe es ist, diese Fehlerklasse zu fangen, war strukturell blind für die Hälfte davon, die tatsächlich CVSS 9+ Ergebnisse landet. Architektur: Wie MCP007 tatsächlich funktioniert Die Regeln sind absichtlich einfach: Line-Scan-Regex-Matching ohne AST, so dass sie schnell über alle Sprach-Mcpscan-Unterstützungen laufen. Jede Regel hat drei Regex-Schichten: Das Original sink regex, verbatim von : Hinweis: ist dort, aber Python ist auch das Schreibbecken (). Der Regex kümmert sich nicht um den Modus, so dass theoretisch einige Schreiben bereits durchrutschen. Aber , , , , und wurden überhaupt nicht übereinstimmen. Das ist die eigentliche Lücke, die die Form von CVE-2026-27825 durchlässt. Schritt für Schritt: die Korrektur Da und bereits tun, was benötigt wird (Erkennen eines dynamisch aufgebauten Pfades und eskalierender Schweregrad, wenn ein Literal auftaucht), ist die Korrektur additiv: ein zweites Senkenmuster, das die gleiche Erkennungspipeline wiederverwendet. 1. Schreib-Senke-Regexe neben den gelesenen hinzufügen: 2. Überprüfen Sie beide Spülenfamilien pro Zeile, nicht nur eine: Ich habe Schreib-Senke-Hits direkt auf sogar ohne ein Literal gestoßen. Ein angreifergesteuerter Zielpfad ist ein schlechterer Primitivpfad als ein angreifergesteuerter Quellpfad, da die Nutzlast normalerweise in der gleichen Anforderung entlangfährt (wie in ). 3. Beweisen Sie es gegen die reale Form. Lassen Sie dies in eine Halterung fallen und führen Sie den Scanner aus: Vor dem Patch erzeugte diese Halterung null Ergebnisse. Das ist der ganze Bug, in einem Diff. Gotchas und Edge Cases Modus Mehrdeutigkeit. Es wird technisch gelesen und geschrieben. Ich habe nicht versucht, komplexe Modus-Strings zu analysieren. Der Regex passt auch, , Modi (mit optional) als zusätzliches Signal, und doppelte Übereinstimmungen sind harmlos, weil ein Tupel in der Reihenfolge mit überprüft wird. Falsche Positive auf legitime Atom schreibt. Code, der läuft, wird jetzt korrekt markiert. Das ist immer noch ein unvalidierter Zielpfad, auch wenn es nur ein Tempfile-Suffix ist. Unterdrücke dies nicht; validiere stattdessen den Basispfad. Schweregradinflation. Die Eskalation aller Schreib-Senke-Hits auf HIGH (nicht nur solche mit einem Literal) wird zu mehr HIGH-Ergebnissen führen als zuvor. Dies ist angesichts der CVE-Daten beabsichtigt. Wenn Sie dies forken, erwarten Sie, dass Ihr Triage-Backlog wächst, was der Punkt ist. Regex Beschränkungen. Es wird immer noch keinen Pfad fangen, der drei Funktionen von der Spüle entfernt gebaut wurde. Das ist eine echte Einschränkung der gesamten Regel, nicht etwas, das dieser Patch behebt. Es lohnt sich, in Ihrer eigenen Dokumentation zu erwähnen, damit Benutzer kein blindes Vertrauen in einen sauberen Scan setzen. Umsetzbare Takeaways Wenn Sie einen Sicherheitsscanner pflegen, führen Sie ihn regelmäßig mit Ihrer eigenen Liste der letzten echten CVEs durch. Regeln driften stillschweigend abgestanden: nichts bricht, es hört leise auf, den Vulner zu fangen