Mastodawn

@flintflump asked me for a second opinion on this questionable article by #equixly about MCP security. I don't disagree that MCPs are causing lots of security issues, but the example in the article is just not one of them.

https://equixly.com/blog/2025/03/29/mcp-server-new-security-nightmare/

The supposedly vulnerable code boils down to subprocess.call("notify-send", alert_title), where alert_title is untrusted. As long as notify-send is not vulnerable to RCE, this is completely fine: args is a list and shell is (implicitly) False.

🧵 1/3

MCP Servers: The New Security Nightmare

MCP servers are becoming a colossal remote code execution risk. Why are 2025’s newest AI tools repeating old security mistakes?

Equixly

Show thread

Konstantin Weddige

This is how it's supposed to be done!

Also, the "Practical Exploitation Example" given in the article does nothing. It just calls the tool (supposedly the "vulnerable" one from above) with the payload {"title": "test", "severity": high"} and returns the output. This simply calls notify-send with the argument "test - high". Nothing bad happens and no RCE is demonstrated.

Can I call this a #vibesploit?

🧵 2/3

Show thread

Konstantin Weddige Jan 7

Am I missing something? Please point out any vulnerabilities in the code that I have overlooked.

MCPs and LLM integrations in general are a security nightmare, and I have seen my fair share of RCEs via LLM. However, making up vulnerabilities so that you can write a marketing blog post does not make anything more secure.

🧵 3/3