My MCP Security Scanner Missed 2026's Worst MCP RCE: Here Is the One-Rule Fix

The hook A few months back I shipped , a static analyzer that scans MCP (Model Context Protocol) servers for the vulnerability classes that keep showing up in this ecosystem: command injection, SSRF, and path traversal. Rule was supposed to be the path traversal catch-all. This week I sat down with my own research notes and ran a simple gut-check: would MCP007 have caught the four real path-traversal CVEs disclosed against MCP servers this year? It would have missed every single one. Including the worst one. Real-world context Here is what actually shipped as CVEs in 2026, all in MCP servers, all sharing the same root cause: 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 write RCE via site-packages injection CVE-2026-27825 mcp-atlassian CVSS 9.1, unauthenticated RCE (chained with SSRF CVE-2026-27826 to overwrite or drop a cron entry) Four different maintainers, four different tools, the exact same blind spot: a file path built from caller-controlled input, written without a directory-boundary check. The bug in is the nastiest: no auth needed, no restart needed, straight to a shell. So I opened my own rule file and read the docstring out loud: There it is. My rule was scoped to reads from day one, and every real-world exploit this year happened on the write side. A scanner whose entire job is catching this bug class was structurally blind to the half of it that is actually landing CVSS 9+ scores. Architecture: how MCP007 actually works The rules in are simple on purpose: line-scan regex matching without an AST, so they run fast across any language mcpscan supports. Each rule has three regex layers: The original sink regex, verbatim from : Notice: is in there, but Python's is also the write sink (). The regex does not care about mode, so in theory some writes already slip through. But , , , , and were not matched at all. That is the actual gap that let the shape of CVE-2026-27825 through. Step-by-step: the fix Since and already do what is needed (detecting a dynamically-built path and escalating severity when a literal shows up), the fix is additive: a second sink pattern, reusing the same detection pipeline. 1. Add write-sink regexes next to the read ones: 2. Check both sink families per line, not just one: I bumped write-sink hits straight to even without a literal . An attacker-controlled destination path is a worse primitive than an attacker-controlled source path, because the payload usually rides along in the same request (as seen in ). 3. Prove it against the real shape. Drop this into a fixture and run the scanner: Before the patch, that fixture produced zero findings. That is the whole bug, in one diff. Gotchas and edge cases mode ambiguity. is technically read and write. I did not try to parse complex mode strings. The regex also matches , , modes (with optional ) as an additional signal, and duplicate matches against are harmless because is a tuple checked in order with . False positives on legitimate atomic writes. Code that runs will now flag, correctly. That is still an unvalidated destination path even if it is only a tempfile suffix. Do not suppress this; validate the base path instead. Severity inflation. Escalating all write-sink hits to HIGH (not just ones with a literal ) will produce more HIGH findings than before. That is intentional given the CVE data. If you fork this, expect your triage backlog to grow, which is the point. Regex limitations. It still will not catch a path built three functions away from the sink. That is a real limitation of the entire rule, not something this patch fixes. It is worth noting in your own documentation so users do not place blind trust in a clean scan. Actionable takeaways If you maintain a security scanner, periodically re-run it against your own list of recent real CVEs. Rules drift stale silently: nothing breaks, it just quietly stops catching the vulner