If you pay attention to the world of AI, you’ll have noticed that Model Context Protocol (MCP) is a very popular topic right now. The Model Context Protocol is an open standard that enables developers to build secure, two-way connections between their data sources and AI-powered tools. The architecture is straightforward: developers can either expose their data through MCP servers or build AI applications (MCP clients) that connect to these servers.
Because MCP is so popular it seemed like a great topic to do some security research with. I decided to review the top 161 MCP servers currently listed on the Docker hub, generate SBOMs for each container then run a vulnerability scan to see what the current state of that software is.
The list of the MCP server I used can be found on Docker Hub at https://hub.docker.com/mcp. The tools I am using are explained further down.
Explore SBOM use-cases for almost any department of the enterprise and learn how to unlock enterprise value to make the most of your software supply chain.
Step by step vulnerability analysis of 161 MCP servers
As a first step I pulled all the container images then I used our OSS Syft scanner to generate SBOMs for each image. When Syft scans a container it catalogs all the packages and files contained in a container image. Those SBOMs were then scanned with our OSS vulnerability scanner Grype . All scan results, SBOMs and vulnerabilities were put into Elasticsearch. I enjoy using Elasticsearch as it makes it very easy to make graphs of the data and understand what’s happening.
Keep in mind, these results are the output of Syft and Grype; if there is a bug in one of them, or they cannot detect a certain package type, that will cause a hole in the data. These results shouldn’t be treated as 100% accurate, but we can derive observations, trends, and patterns based on this data set.
How bad is it? TL;DR: It’s pretty bad.
In 161 containers, Grype found exactly 9000 vulnerabilities. The number is certainly larger now. Vulnerabilities are a point in time snapshot, it was 9000 when the scan was run in early September 2025. As time moves forward, more vulnerabilities will be uncovered. CVE is adding around 4000 new vulnerabilities per month, some of which will affect a subset of the software in these MCP containers.
Let’s start with the top 10 containers by vulnerability count.
We should dig deeper into the top image as there’s more happening than the raw numbers would suggest. What if we look at the number of vulnerabilities based on the type of package for that image?
This image is based on Debian 12 specifically, which isn’t particularly old. If we take a closer look, we see 429 Debian packages installed, 51 python modules, and 13 unpackaged binaries. 429 packages is quite a lot. The default Debian base container image contains 78 packages, 429 is a lot of new packages being added!
Before publishing, I did contact Clickhouse and they have updated their container image, it’s in way better shape now. I applaud their quick updates!
What’s the make up of a MCP container?
Rather than dwell on this one container, let’s zoom out and look at all the data first. That will allow us to better explain what’s happening with Debian and why we see these results.
Let’s look at the list of all Linux distributions in use in these MCP containers:
| Image | Count |
|---|---|
| Alpine | 97 |
| Debian | 61 |
| Ubuntu | 1 |
| Wolfi | 1 |
The observant will now say that only adds up to 160! The mcp/docker image has no distro. There are also no RPM based container images in the top MCP servers (this might only be interesting to me as I spent many years at RedHat).
Each image has various packages installed, in this instance from the Linux distributions deb and apk. It also includes packages used by the various languages in use such as Python and NPM. What does the number of packages spread across all the images look like?
| Package Types | Count |
|---|---|
| go-module | 3405 |
| python | 3304 |
| apk | 2178 |
| binary | 837 |
| java-archive | 208 |
| dotnet | 98 |
| nix | 22 |
| lua-rocks | 2 |
Anybody watching the world of package ecosystems would probably expect this distribution above; NPM is a widely used language with a lot of packages. Debian is used by many images and doesn’t focus on minimal packages like Alpine, and Go and Python are commonly used languages.
Analysis of vulnerabilities in a debian image
Now if we shift our focus back to vulnerabilities, what does the distribution of vulnerabilities by package look like?
As seen above, the Debian packages account for the vast majority of vulnerabilities in these container images.
On a side note: I want to take a moment to explain something important about the Debian results. We should not be using this data to make a claim Debian is insecure. Debian is a very well maintained distribution with a great security team. They have a huge number of packages they have to keep track of. Debian puts a ton of effort into fixing the security vulnerabilities that truly matter. When a small team of volunteers have limited time, we of course want them working on things that matter, not wasting time on low severity vulnerability noise.
If we look at the distribution of vulnerabilities affecting the Debian packages we are getting a clearer picture:
The vast majority are “Negligible” Debian vulnerabilities. These are vulnerabilities the Debian security team after careful analysis has decided are lower than low and will be de-prioritized compared to other vulnerabilities.
I scanned the latest Debian container and these are the results: 0 critical, 0 high, 1 medium, 5 low, 40 negligible. That’s very impressive, and it’s also a great reason to keep your software up to date. Also keep in mind that many of these MCP Debian images haven’t been updated in a long time. It’s hardly Debian’s fault when the author of a container builds it then never updates the Debian packages.
But how bad is it overall?
On the topic of vulnerability severities, what does that graph look like across all packages in all the containers?
This graph looks a bit like that Debian distribution, but here we are seeing 263 critical vulnerabilities. That’s 263 critical vulnerabilities in 161 container images which seems like a lot. If we break this down into the packages affected by critical vulnerabilities this is what we get.
| Ecosystem | Count |
|---|---|
| Debian | 93 |
| Go | 92 |
| NPM | 42 |
| Alpine | 19 |
| Python | 15 |
| Binary | 2 |
While we know there are a lot of outdated Debian packages, it’s clear most of the other ecosystems have problems as well. We haven’t done enough research to say if these critical findings could be exploited, but even if not, it’s bad optics. It’s common for an organization to have a policy of no critical vulnerabilities in any software they deploy, it doesn’t matter if it’s exploitable or not.
Deep dive into 36,000 NPM packages
If we recall the table of all package types at the beginning of this post, there were more than 36,000 NPM packages installed in these 161 container images. Since NPM is significantly more than all the other ecosystems combined, we should investigate a bit further. What are the most installed NPM packages?
It is impressive that minipass has almost 700 installs in 161 containers, unless you are an NPM developer, then these packages won’t surprise you. They are widely used across NPM both for MCP and non-MCP software.
As a note to myself, a future research project should be looking for NPM packages that have been removed for having malware, or could be typosquatted or slopsquatted.
When working with these types of data sets, I am always interested to look at the size of files in the images.
If we look at the graph, there are a huge number of small files but also always outliers that are much larger than one would expect. One datapoint even nears 600 Megabytes. That’s a pretty big file, and my initial thought was that it could be some sort of LLM model or training content. In the clickhouse container there is a shared library in a python package that’s nearly 600 Megabytes in size. It’s a binary library in a file named _chdb.cpython-313-x86_64-linux-gnu.so. chdb is an in-memory database with data needed by the MCP server, so yeah, it’s AI content.
The other outliers around 100 MB are clickhouse and vizro containers with the pyarrow library, about 66 MB. And the aws-terraform container with a 120MB package called playwright.
It’s likely these large files aren’t mistakes but are indeed used by the container images. There’s nothing wrong with large containers. But it’s always interesting to look for outlier data to ensure mistakes haven’t been made somewhere along the way. We want to make sure we don’t accidentally include some sensitive files, or extra packages, or even debug data that nobody needs.
Conclusion…if you want to call them that
This post has a lot of data for us to think about, it’s probably overwhelming at a first glance. I don’t suggest that this should be treated as some sort of deep security analysis of MCP, it’s meant to be a brief overview of some interesting findings while digging into data. My goal is to start conversations and hopefully see more deeper research into these MCP images. If you think I did something wrong, or want to ask different questions, nothing would make me happier to be proven wrong, or inspire further research.
For now, these are the conclusions I have drawn. All of these images would benefit from some common vulnerability handling best practices:
- Keeping software updated is a great first step. Regular updates are hard, but also table stakes for anyone building software in the modern age.
- Minimizing attack surfaces should also be used when possible. There are small container images to build on top of. Make sure you prune out unused dependencies on a regular basis. Only use the dependencies and libraries that are needed.
- And most importantly is to keep an inventory of what you’re shipping, then using that inventory to make informed decisions.
Software doesn’t age like a fine wine, more like milk. It’s important we keep track of what we’re shipping. When you produce software, it’s never a “one and done” sort of situation. It needs constant care and feeding. Understand what our threat model and risk profiles are, and most importantly, keep things updated.
Learn about the role that SBOMs for the security of your organization in this white paper.
