A tiny fix next to a wide exposure says a lot about MCP server security in 2026. The costly failures are usually small omissions. This guide draws on this year’s research, a few public incidents, and the current MCP specification. Any MCP server for AI agents inherits these habits. The guide tries to separate the ones worth changing from the noise.

What Research Found About Servers

Many Servers Have No Authentication

Two academic papers examined real MCP servers this year. One team confirmed 7,973 live remote servers through internet scans in May. Of those, 3,233 exposed their tools with no authentication at all. That works out to 40.55 percent. A second study in August audited 414 servers with test requests and found that most of them lacked OAuth.

Some caution is fair here. Public scans pick up plenty of hobby projects and test servers. Your enterprise server probably isn’t one of them. The August paper also lists its own limits. A single researcher ran it. Nobody measured its error rate against a labeled test set. Still, the figures show what the default looks like. The MCP specification makes authorization optional, and many authors never opened that chapter. Internal servers invite the same shortcut since “internal” feels safe.

What the Researchers Recommend

The August paper closes with three requests aimed at the wider ecosystem. SDKs should turn on OAuth 2.1 by default for HTTP transport. Registries should display each server’s authentication posture. Hosting platforms should warn before a shell-capable tool goes public. None of that is in your control. Your own defaults remain yours to set.

The nginx-ui Flaw: One Endpoint Without Authentication

nginx-ui is a web interface for managing nginx. Its MCP feature used two endpoints.

  • The first, /mcp, set up the connection and carried both authentication and an IP allowlist.
  • The second, /mcp_message, processed every tool call. It shipped without the authentication check. Twelve tools were reachable through it.
  • Seven could change the server by injecting configuration, reloading nginx, or intercepting traffic. One unauthenticated request was enough.
  • The maintainers released version 2.3.4 a day after disclosure.

Look at where the check lived. It protected the endpoint people think about, the one that starts a session. The endpoint that runs the tools got forgotten. One plausible reason is that middleware gets applied to a group of routes, and a new handler lands outside the group. Any MCP server with more than one route can fail the same way. A route-by-route test takes minutes. Call each endpoint with no token at all and write down which ones answer.

MCP Authentication and Authorization Mistakes That Repeat

Open Client Registration

Dynamic client registration lets an MCP client introduce itself to a server and receive credentials on the spot. That suits a protocol where nobody knows in advance which clients will connect. It also lets anyone register, including a client that lists an attacker’s address as its redirect. The May paper tested 119 OAuth servers that allowed open registration. Every one had at least one flaw. In 114 of them, a registration could be tied to a malicious redirect address.

Consent screens didn’t rescue many of those servers either. The paper found consent-page bypasses on most of them. The specification now prefers Client ID Metadata Documents and treats dynamic registration as deprecated. If you still run open registration, the paper’s fixes are modest. An allowlist of redirect patterns removes the worst cases. PKCE needs to be enforced on the server, with the plain method rejected. Most tested servers let clients skip it. A consent page that prints the exact redirect address gives users a fair chance to say no.

Audience Checks and Token Passthrough

A signature proves who issued a token. It doesn’t prove who the token was for. Servers that stop at the signature will accept a valid token from the wrong service. The specification calls for audience validation. Clients help by sending a resource parameter that names the server they want. Test it with a token issued for another service. Anything but a 401 is a finding.

Passthrough is the neighboring shortcut. A server forwards the user’s own token to a downstream API and saves some code. The downstream logs then name the user as the caller. Nobody can tell an agent from a person. The specification forbids that shortcut outright. Use the server’s own credentials downstream.

Scope Creep and Step-Up

OWASP’s MCP Top 10, still in beta, lists scope creep as its second risk. Most teams will recognize the pattern. A server starts with narrow permissions. Then somebody adds one scope to unblock a demo and never removes it. Good MCP authorization shrinks the damage when a token leaks, and step-up is the specification’s answer. A tool that needs more power gets a 403 with an insufficient_scope error that names the missing scope. The client then asks the user for that one addition. Wildcard scopes such as admin defeat the idea. So does listing every scope in scopes_supported, which invites clients to request all of them.

Launch Commands and the stdio Debate

In April 2026, OX Security reported that the stdio transport in the official MCP SDKs lets configuration turn directly into a command run on the host. OX counted more than 150 million downloads in the affected supply chain. It also says it asked Anthropic to change the design at the protocol level. According to OX, Anthropic called the behavior expected and said input sanitizing belongs to developers.

Reasonable people can disagree about whose job this is. A transport that launches a configured command does what its documentation says. A product that lets a user type that configuration into a web form hands every user the power to run commands. Both views arrive at the same rule. Input from outside should never reach a launch command. A short allowlist of approved commands works better. Sandboxing the process limits the damage. The client should also display the full command before running it.

Local Servers and Origin Checks

A developer tool showed the risk in 2025. Oligo disclosed CVE-2025-49596 in MCP Inspector, which developers use to test servers. Its proxy listened on port 6277 with no authentication by default. A malicious web page could talk to it from inside the developer’s own browser. One request could start a process on the developer’s machine. Version 0.14.1 added a session token, Origin checks, and Host header verification.

The Streamable HTTP rules ask for the same protections. A server must validate the Origin header and return 403 for an invalid one. It should bind to 127.0.0.1 instead of every interface. Browser-based clients need their origins on an allowlist, which requires a deliberate decision. You can test the Origin rule in a minute with a curl request that carries an invented Origin value. Anything but 403 means the check is missing. How many of your internal tools would pass?

Outbound Requests and SSRF

OAuth discovery sends servers to addresses that other people supply. Metadata links, authorization server lists, and token endpoints all arrive from outside. An attacker can aim one at 169.254.169.254, where a cloud host exposes its own credentials. The August paper found this kind of flaw by watching the clock. Requests aimed at a metadata address took 11.9 seconds, against a 0.3 second baseline. That delay suggested the server had tried to connect.

Teams usually respond with a pattern that blocks addresses starting with 10, 192.168, or 127. Then someone writes the same address in hex, or as an IPv4-mapped IPv6 value, and it passes. The specification points to an egress proxy such as Smokescreen and to pinning the DNS result between the check and the request. That approach has a cost. A proxy adds a hop to every outbound call and one more service to run. It also gives you a single place to fix the next bypass.

Headers and Handles Without Sessions

The July 2026 revision removed protocol-level sessions and added Mcp-Method and Mcp-Name headers to every Streamable HTTP request. Gateways like the headers because they can rate-limit a payment tool without parsing any JSON. Trouble starts when the gateway trusts the header while the server trusts the body. A server that reads the body must reject any mismatch with HTTP 400 and error code -32020.

Servers that need continuity now hand out handles that the model passes back as tool arguments. A handle is only a reference. Holding one proves nothing about who holds it. Store state under the verified user ID plus the handle. That user ID comes from the validated token.

Testing the Refusals

Most teams test what their tools do. Far fewer test what their tools refuse, yet secure MCP servers are defined by refusals. A refusal that returns an empty success is worse than an error, because an agent reads silence as finished work. Teams starting MCP Server Development can add these cases before the first tool ships. They also make AI agent security something you can measure. Run them in the build pipeline so a regression fails the build.

  • A token issued for another audience gets a 401.
  • A call to every tool endpoint without a token gets a 401.
  • A forged Origin gets a 403.
  • A metadata link pointing at a private address is blocked.
  • A header that disagrees with its body gets a 400.

Ownership and Governance

Several OWASP items are organizational. MCP08 covers missing audit logs. MCP09 covers shadow servers that run outside any governance. Every MCP server integration adds routes, clients, and tokens that someone has to own. A developer can stand up an MCP server in an afternoon. Nobody in security may ever hear about it. That raises a plain question for your next review. Do you know how many MCP servers exist in your company today?

Questions like these belong to leadership as much as engineering. Which agents may touch which data, who approves a new tool, and how incident reviews run are policy decisions. Written answers form the core of AI governance and security. Enterprise AI security programs also find them far easier to write before a launch than after an incident.

Conclusion

Most of this year’s MCP server security trouble came from missing basics. One route skipped a check. Registration stayed open to everyone. A launch command accepted outside input. None of it needed a clever attack on a model. The research has a useful side effect. It gives you a short list to test this week. Call every endpoint without a token. Send a token meant for another service. Fake an Origin header on one request. Point a metadata link at a private address. Record each response and fix the oldest failure first. Treat the answers as a baseline to compare against after each release. Which of those four would your server fail today?

Want an outside team to run those checks? Talk to the Mobisoft Infotech team.