lorenzopasquali.dev

MCP got two advisories in one week and neither is a code bug

· 3 min read · also in Portuguese

A few days after I wrote here about integrating LLMs via MCP into an on-premise MES, two MCP security issues landed three days apart. I read both advisories in full, and what struck me wasn't the severity: it was that neither one is a code bug.

Sep 28: the official Python SDK hands your credentials to the wrong server

The advisory is GHSA-qx49-fqc8-xw99, CVSS 7.5 (High), no CVE assigned.

The problem: the client wasn't validating the issuer in the OAuth flow. A malicious MCP server (or a legitimate one that got compromised) could manipulate the issuer metadata, or simply provide none at all, and thereby point the client at a token endpoint of its choosing. The result is your credential being handed to an attacker's authorization server, with the same permissions you granted the app.

And note that upgrading isn't the end of it: the advisory explicitly says that for unattended providers you need to pass issuer= to bind the credential to the correct authorization server. If there was prior exposure, rotate credentials and revoke tokens.

Sep 30: next dev exposes your project to any site open in the browser

Two days later, Next.js's September security release shipped seven fixes. One of them is CVE-2026-94486: the Next.js development server exposes an MCP endpoint that does not verify which website a request originates from.

Which means any malicious site you visit while next dev is running can read the project's location on disk, source code snippets from error reports, the route inventory, and development logs.

It only affects next dev: production doesn't serve that endpoint. Which is no comfort at all, because next dev is precisely the process running on the same machine where you have fifty tabs open.

What the two have in common

Neither is a parsing failure, a memory bug, or an implementation mistake. Both are the same class of error in different places: MCP assumed good faith at a trust boundary.

In the SDK, the assumption was "the server will tell me the truth about who the OAuth issuer is." In Next.js, it was "whoever talks to my dev endpoint is my editor." In both cases the fix isn't a logic patch, it's stopping trusting the other side.

That matters because it's structural. MCP is a protocol whose entire value is plugging third-party things into your development environment, which is the place with the highest credential density in your professional life. Every server you add is a new trust boundary, and none of them arrives with a security review attached.

What I'd check today

In my case the MES MCP server is mine, it runs on-premise, and the SDK's OAuth flow barely touches me. But that only inverts the question, it doesn't remove it:

  1. Python SDK version: >= 1.30.0 or >= 2.2.0. That's one command.
  2. Explicit issuer= on any unattended provider.
  3. How many third-party MCP servers are configured in your Claude Code, Cursor or editor, and which of them you've read the code for.
  4. Whether next dev runs on the same machine as your general-purpose browser (it does).
  5. Exactly which credentials a third-party MCP server can reach if it wants to. Not what it uses, what it reaches.

My verdict

Both patches are trivial to apply and you should apply them today. But if the reading stops there, next week brings the third advisory in the same family.

Items 3 and 5 on that list are the real work, and they're the only ones no npm update solves. I've been plugging MCP into industrial systems and writing about it, and until last week I hadn't sat down to list what each third-party server in my editor can reach. I listed them. Recommended.

← All posts