[HN Gopher] MCP-Scanner - Scan MCP Servers for vulnerabilities
___________________________________________________________________
MCP-Scanner - Scan MCP Servers for vulnerabilities
Author : hsanthan
Score : 164 points
Date : 2025-10-27 17:18 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| cyberax wrote:
| The MCP landscape is a huge frothing septic tank. Go on, try to
| create a simple MCP server that is protected by a password and
| connect it to ChatGPT or Claude. Or even the one that uses your
| local SSO system for authentication.
|
| I tried and failed after about 3 days of dealing with AI-slop-
| generated nonsense that has _never_ been worked. The MCP spec was
| created probably by brainless AI agents, so it defines two
| authentication methods: no authentication whatsoever, and OAuth
| that requires bleeding-edge features (dynamic client
| registration) not implemented by Google or Microsoft.
|
| The easiest way for that right now is to ask users to download a
| random NodeJS package that runs locally on their machines with
| minimal confinement.
| zingababba wrote:
| Lol yeah, lots going on that will hopefully make it better
| though.
|
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://aaronparecki.com/2025/05/12/27/enterprise-ready-mcp
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://www.okta.com/newsroom/press-releases/okta-introduces...
| https://github.com/modelcontextprotocol/ext-auth/blob/main/s...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| https://github.com/modelcontextprotocol/modelcontextprotocol...
| fasbiner wrote:
| Had an almost identical experience. Even if you don't need
| anything with auth, no one has yet made an mcp that wasn't
| ultimately worse or the same as a cli but with a lot more song
| and dance. Security is also a bit of a joke when half the time
| it's installing docker and phoning home. I wanted to like mcp
| and vend out remote mcp but this spec is not ready.
| morkalork wrote:
| I'm still confused as to how mcp is better that say a Fastapi
| endpoint and it's generated swagger docs?
| mbreese wrote:
| In the cases I've tried building/integrating they are the
| same thing...
|
| I think the only difference is the statefulness of the
| request. HTTP is stateless, but MCP has state? Is this
| right?
|
| I haven't seen many use cases for how to use the state
| effectively, but I thought that was the main difference
| over a plain REST API.
| eric-burel wrote:
| My understanding is that it can upgrade to an SSE
| connection so a persistent stream. Also for interprocess
| communication you usually prefer a persistent connection.
| All that to reduce communication overheads. The rationale
| also is that an AI agent may trigger more fine-grained
| calls than a normal program or a UI, as it needs to
| collect information to observe the situation and decide
| next move (lot more get requests than usual for
| instance).
| fasbiner wrote:
| Using SSE was far too inconvenient in theory despite that
| being how nearly all of the MCP that gained traction was
| working, so instead the spec was switched to being better
| in theory but very inconvenient in practice:
|
| https://blog.fka.dev/blog/2025-06-06-why-mcp-deprecated-
| sse-...
|
| There are a million "why don't you _just_ X?"
| hypothetical responses to all the real issues people have
| with streamable http as implemented in the spec, but you
| can't argue your way into a level of ecosystem support
| that doesn't exist. The exact same screwup with oAuth
| too, so we can see who is running the show and how they
| think.
|
| It's hard to tell if there is some material business plan
| Anthropic has with these changes or if the people in
| charge of defining the spec are just kind of out of
| touch, have non-technical bosses, and have managed to
| politically disincentivize other engineers from pointing
| out basic realities.
| jhugo wrote:
| This seems like the solution getting ahead of the
| problem. A series of API requests over HTTP can easily
| use a persistent connection and will practically default
| to that with modern client and server implementations. A
| claim that a more complex approach is needed for
| efficiency should be accompanied by evidence that the
| simple approach was problematic.
|
| MCP can use SSE to support notifications (since the
| protocol embeds a lot of state, you need to be able to
| tell the client that the state has changed), elicitation
| (the MCP server asking the user to provide some
| additional information to complete a tool call) and will
| likely use it to support long-running tool calls.
|
| Many of these features have unfortunately been specified
| in the protocol before clear needs for them have been
| described in detail, and before other alternative
| approaches to solving the same problems were considered.
| eric-burel wrote:
| I can't agree more, downloading OpenAPI doc for an API
| and parse it is more than enough to implement the core of
| MCP. But sadly the buzzword completely took of and for
| instance all participants to my trainings will ask for
| MCP, systematically.
| data-ottawa wrote:
| I use it basically as a cache, I create local artifacts
| that are fast to filter/query and easily paginate on the
| client (which is to say in the MCP server).
| dboreham wrote:
| MCP doesn't serve any technical purpose. It exists for
| business reasons.
| jonfw wrote:
| MCP provides a convenient packaging for tools, and
| generally workflows, for LLM clients.
|
| You can debate all day whether bringing your own tools is
| a good thing vs giving the LLM a generic shell tool and
| an API doc and letting it run curls. I like tools because
| it brings reproducibility.
|
| MCP is really just a json RPC spec. json RPC can take
| place over a variety of transports and under a variety of
| auth mechanisms- MCP doesn't need to spec a transport or
| auth mechanism.
|
| I totally agree with everybody that most MCP clients are
| half assed and remote MCP is not well supported, but
| that's a business problem
|
| Every LLM tool today either runs locally (cursor, zed,
| IDEs, etc.) so can run MCP servers as local processses w/
| no auth, or is run by an LLM provider where
| interoperability is not a business priority. So the
| remote MCP story has not been fleshed out
| bootsmann wrote:
| "Ok, how do we do customer auth" has become my go-to question
| to kill MCP projects. There is no working solution which makes
| any kind of enterprise exploration into the space pointless.
| mbreese wrote:
| Serious question, as I'm starting to go through this process
| myself -
|
| Is it possible for the customer to provide their own bearer
| tokens (generated however) that the LLM can pass along to the
| MCP server? This was the closest to a workable security I've
| looked at. I don't know if that is all that well supported by
| Chat GUI/web clients (user supplied tokens), but should be
| possible when calling an LLM through an API style call, right
| (if you add additional pass thru headers)?
| eric-burel wrote:
| The LLM doesn't intervene much actually, it just tells what
| tool to call. It's your MCP implementation that does the
| heavy lifting. So yeah you can always shove a key somewhere
| in your app context and pass it to the tool call. But I
| think the point of other comments is that the MCP protocol
| is kinda clueless about how to standardize that within the
| protocol itself.
| arscan wrote:
| I think an important thing to note is the MCP client is a
| distinct thing from the 'LLM' architecturally, though
| many LLM providers also have MCP client implementations
| (via their chat ui or desktop / cli implementations).
|
| In general, I'd say it's not a good idea to pass bearer
| tokens to the LLM provider and keep that to the MCP
| client. But your client has to be interoperable with the
| MCP server at the auth level, which is flakey at the
| moment across the ecosystem of generic MCP clients and
| servers as noted.
| cyberax wrote:
| > but should be possible when calling an LLM through an API
| style call, right (if you add additional pass thru headers
|
| Nope. I assumed as much and even implemented the bearer
| token authentication in the MCP server that I wanted to
| expose.
|
| Then I tried to connect it to ChatGPT, and it turns out to
| NOT be supported at all. Your options are either no
| authentication whatsoever or OAuth with dynamic client
| registration. Claude at least allows the static OAuth
| registration (you supply client_id and client_secret).
| maxwellg wrote:
| The initial remote MCP specification was pretty painful, but
| the June spec and the upcoming November spec are much more
| workable - MCP auth is (mostly) just OAuth now. MCP Clients
| are OAuth clients and can be granted access tokens and
| managed just like any other 3rd party app integration.
|
| I'd love to hear more about the specific issues you're
| running into with the new version of the spec. (disclaimer -
| I work at an auth company! email in bio if you wanna chat)
| cyberax wrote:
| Basically, I'm trying to just create a protected MCP server
| that works with ChatGPT. That's it. Nothing fancy.
|
| So far, I was not able to do it. And there are no examples
| that I can find. It's also all complicated by the total
| lack of logs from ChatGPT detailing the errors.
|
| I'll probably get there eventually and publish a blog...
| brabel wrote:
| ChatGPT provides a new Apps SDK that makes things easier.
| The MCP server does need a proper Authorization Server to
| do OAuth, including DCR and OIDC metadata support, but
| those are the best way to do what they are trying to do.
| Anything else I have considered would be much worse
| security and discovery wise.
| dorkypunk wrote:
| I'm still laughing on how the error handling for tools is done,
| it's just a boolean field IsError.
|
| https://modelcontextprotocol.io/specification/2025-06-18/ser...
| embedding-shape wrote:
| There is a difference between protocol error and tool usage
| error, makes sense you want the model to see the tool usage
| error, so they can correct.
|
| I'm guessing it has a the same shape as a normal message +
| IsError so on the handling side you don't really have to do
| anything special to handle it, just proceed as normal and
| send the results to the LLM so it can correct if needed.
| throwaway314155 wrote:
| MCP works best for tool calling that doesn't require auth (so
| tools that are trusted on your own machine). The whole pitch
| that you should be using it for business facing tools and
| things that require auth is a terrible idea.
|
| Even if you're doing local only - MCP tools can mostly be
| covered by simply asking Claude Code (or whatever) to use the
| bash equivalent.
| cyberax wrote:
| > MCP works best for tool calling that doesn't require auth
| (so tools that are trusted on your own machine).
|
| In other words, downloading random crap that runs unconfined
| and requires a shitty app like Claude Desktop.
|
| BTW, Claude Desktop is ALSO an example of AI slop. It barely
| works, constantly just closing chats, taking 10 seconds to
| switch between conversations, etc.
|
| In my case, I wanted to connect our CRM with ChatGPT and ask
| it to organize our customer notes. And also make this
| available as a service to users, so they won't have to be AI
| experts with subscriptions to Claude.
| tsouth wrote:
| The MCP & DCR OAuth ecosystem was immature at the start, but
| has really evolved and become robust. E.g., WorkOS has some
| really robust OAuth that can act as a standalone proxy for MCP
| connecting to any existing auth infrastructure.
|
| Metadata and resource indicators are solving the rest of the
| problems that came with the change to OAuth spec.
| jngiam1 wrote:
| It's really messy now. ChatGPT in particular makes it really
| hard; it turns out that Custom GPTs with actions can do pretty
| well, if you bridge MCP tools into actions; but setting any of
| these up is a pita.
|
| The LLMs are also really bad at generating correct code for
| OAuth logic - there are too many conditions there, and the DCR
| dance is fairly complicated to get right.
|
| Shameless plug: we're building a MCP gateway that takes in any
| MCP server and we do the heavy lifting to make it compatible
| with any client on the other end (Claude, ChatGPT - even with
| custom actions); as a nice bonus it gives you SSO/logs as well.
| https://mintmcp.com if you're interested.
| oezi wrote:
| Why just a gateway? Why not a serverless way to host tools?
| jngiam1 wrote:
| +1 many tools can be run stateless / have state in a
| external db, and we have ways to support running that
| efficiently as well.
| cyberax wrote:
| It looks great, but it's yet another service. I believe that
| the infrastructure must be as simple as possible.
|
| Have you considered adding a stand-alone service? Perhaps
| using the AGPL+commercial license.
| jngiam1 wrote:
| We do have self-hosted options, and are still thinking
| through OSS strategies. If you've suggestions on that
| angle, would love to learn / read more.
| oezi wrote:
| So where can we host simple single file MCP tools with the ease
| of a lambda?
| whattheheckheck wrote:
| Aws has agentcore
| rdegges wrote:
| At Snyk, we've been working on this for a while. Here's our
| flagship open source project consolidating a lot of the MCP risk
| factors we've discovered over the last year or so into actionable
| info: https://github.com/invariantlabs-ai/mcp-scan
| embedding-shape wrote:
| Would you want to share how/why it's different from the
| submission, since you're making a comment here?
| rdegges wrote:
| I believe one of the main differences is that our scanner
| looks for toxic flows between mcp endpoints regarding how
| they interact with one another. Unless I'm missing something,
| the Cisco tool does not support this.
|
| Our research lab discovered this novel threat back in July:
| https://invariantlabs.ai/blog/toxic-flow-analysis and built
| the tooling around it. This is an extremely common type of
| issue that many people don't realize (basically, when you are
| using multiple MCP servers that individually are safe, but
| together can cause issues).
| spiritplumber wrote:
| Missed opportunity to call it TRON.
| ALAN It's called Tron. It's a security
| program itself, actually. Monitors all
| the contacts between our system and
| other systems... If it finds anything
| going on that's not scheduled, it shuts
| it down. I sent you a memo on it.
| DILLINGER Mmm. Part of the Master
| Control Program?
| ALAN No, it'll run independently.
| It can watchdog the MCP as well.
| DILLINGER Ah. Sounds good. Well, we
| should have you running again in a
| couple of days, I hope.
| tsouth wrote:
| I have seen a bunch of demos of this, often building on top of
| open standards like the SAFE-MCP MITRE ATT&CK analysis
| https://github.com/SAFE-MCP/safe-mcp
|
| In general, the only way to make sure MCPs are safe is to limit
| which connections are made in an enterprise setting
| electric_muse wrote:
| Agreed. Only provide the servers and tools needed for that job.
|
| It would be silly to provide every employee access to GitHub,
| regardless of whether they need it. It's just distracting and
| unnecessary risk. Yet people are over-provisioning MCPs like
| you would install apps on a phone.
|
| Principle of least access applies here just as it does anywhere
| else.
| spiritplumber wrote:
| Missed opportunity to call it TRON.
| Ryan07 wrote:
| Nice to see a scanner for MCP servers. Curious about audit depth:
| config checks only or live exploit tests and what reporting
| formats it supports?
| luma wrote:
| Was trying to remember where I had heard this org's name:
| https://news.ycombinator.com/item?id=42690473
|
| This org has gone to some dubious lengths to make a name for
| themselves, including submitting backdoored packages to public
| npm repos which would exfiltrate your data and send to a Synk-
| controlled C&C. This included the environment, which would be
| sending them your username along with any envvars like
| git/aws/etc auth tokens.
|
| This might give them some credibility in this space, maybe they
| stand a decent chance of scanning MCPs for backdoors based on
| their own experience in placing malicious code on other people's
| systems.
| raesene9 wrote:
| Was this comment meant to be in reply to
| https://news.ycombinator.com/item?id=45726223 ?
| AbstractH24 wrote:
| I love how we now have a class of AI tools that try to catch
| issues created by other AI tools.
| kgwxd wrote:
| Is this to scan your own MCP servers? Does using someone else's
| MCP server put you at risk?
|
| I didn't even know want an MCP server was until I noticed the
| annoying category in VSCode Extensions panel today. Only able to
| get rid of it by turning off a broad AI related flag in settings
| (fine by me, wish I knew it was there earlier). An hour later,
| I'm seeing this.
___________________________________________________________________
(page generated 2025-10-28 23:02 UTC)