Why You Should Audit MCP Servers (Even the Popular Ones)

Popularity is a signal. It is not a security guarantee. April 2026.

The most common way people evaluate MCP servers before installing them is to look at the star count on GitHub. If it has thousands of stars, it must be fine. If a big company maintains it, it must be safe. If a lot of other people use it, someone would have caught any issues by now.

I scanned the 50 most-starred MCP servers on GitHub. The data tells a different story.

Google's CLI scored in the bottom five

google-gemini/gemini-cli has over 100,000 stars. It is maintained by Google. And it scored 83 out of 100, placing it in the bottom five of all 50 servers scanned. The scanner flagged it for requesting both filesystem and network access, plus one high-severity finding.

A server by Google, with six figures of stars, and it did not score well on a basic security audit. This is not a knock on Google. The server probably needs those permissions to function. But the point is that you would not know what it actually requests unless you checked.

A 7,000-star server had eval()

browser-tools-mcp is a Chrome extension MCP server with 7,000+ stars. It scored 81, the lowest in the dataset. The scanner found an eval() call in the extension code. That is dynamic code execution in a browser extension with direct access to web pages.

Seven thousand people starred this repo. It is unclear how many reviewed the code before installing it in their browser. The eval() might be intentional and harmless. Or it might be a vector for code injection. Without an audit, you would not know.

Stars measure popularity, not security

Stars on GitHub mean one thing: somebody clicked a button. They do not mean:

• The code was reviewed for security issues
• The permissions are minimal and appropriate
• The dependencies are clean and locked
• The server does only what it claims to do
• Someone audited the supply chain

Stars correlate loosely with code quality because popular repos attract more contributors and more eyes. But "more eyes" is not the same as "a security audit." The Heartbleed bug existed in OpenSSL for two years while millions of servers used it. Popularity does not prevent vulnerabilities.

The three reasons to audit anyway

1. You are granting real access

When you add an MCP server to your agent's config, you are giving it access to your machine. Depending on the server, that means your files, your network, your environment variables, or all three. This is not hypothetical. The server runs on your machine with your user's permissions. If it has a vulnerability or does something unexpected, the impact is real.

2. Nobody else is checking for you

There is no App Store review process for MCP servers. No central authority validates them before they are published. GitHub does not scan repos for MCP-specific security issues. The npm registry does not check if a package's declared permissions match its actual behavior. If you do not audit, nobody does.

3. It takes two minutes

Running an audit on audit.pyfio.com takes about 60 to 90 seconds. Paste the GitHub URL, wait for the scan, read the report. You will know the server's score across five categories, every finding at every severity level, and whether the permissions match the stated purpose. Two minutes of checking versus unknown risk. The math is straightforward.

What "audit" actually means here

I am not talking about a six-week penetration test. I am talking about five basic checks that catch the most common issues:

1. Permissions check: Does the server request access beyond what it needs?
2. Code safety check: Are there dangerous patterns like eval(), exec(), or unsanitized inputs?
3. Supply chain check: Are dependencies locked? Are there suspicious packages or install scripts?
4. Transparency check: Is there a license? Security documentation?
5. Maintenance check: Is the project actively maintained?

You can do these manually (see the MCP Security Checklist) or use the automated scanner. Either way, the goal is the same: know what you are installing before you install it.

The cost of not auditing

In the best case, nothing happens. The server works as expected, your agent does its job, and you never think about it again.

In the worst case, a server with excessive permissions or a code vulnerability exposes your files, leaks your API keys, or allows an attacker to execute code on your machine. The blast radius depends on what the server has access to and how it is compromised.

With the EU AI Act taking effect in August 2026, there is also a compliance dimension. If you deploy MCP-based agents in the EU and one of your servers has a security incident, the question "did you audit this before deploying it?" will come up. Having an answer is better than not having one.

Start with the servers you already use

You do not need to audit the entire MCP ecosystem. Start with the servers already in your agent's config. How many are there? When did you last look at their code? Do you know what permissions they actually request?

Go to audit.pyfio.com and scan each one. It will take less time than the last meeting you sat through, and it will tell you more useful information.