Google, JPMorgan and the French government fixed the same MCP flaw, but five US federal servers reportedly remain unpatched and logged veterans' SSNs in error responses without redaction

Many MCP servers are designed to fetch URLs handed to them by agents. The same flaw, a failure to check where those URLs lead, has reportedly been found separately in servers run by a major cloud provider, a bank and the governments of two countries. According to The Next Web, Unite.ai and TechTimes, Google, JPMorgan Chase and the French government have each fixed it. Five US federal MCP servers, however, reportedly remain unpatched about five weeks after the flaw was reported. In at least one case, error responses containing veterans' Social Security numbers (SSNs) were reportedly logged without redaction.

This article is based on media reports. We have not been able to verify the organizations' own notices or the researcher's reports. With that caveat, the pattern in the reporting points to one conclusion: MCP security is determined not by the protocol specification but by the quality of each server's implementation.

The flaw: fetching URLs without checking where they lead

The reported flaw is a textbook case of server-side request forgery (SSRF). An MCP server receives a URL from an agent and accesses it from its own side. The affected servers did not check whether the destination was on an internal network, a cloud metadata endpoint or an approved external site. By using the agent as a stepping stone, an attacker could get requests delivered into the internal network where the server sits. The Next Web describes the technique as "pivoting", moving inward by way of the protocol.

The flaw is hard to spot because no single component is broken. Douglas McKee, who leads vulnerability intelligence at Rapid7, reportedly said:

The agent passes along a URL as instructed. The server fetches it as the specification says. The network answers the request it receives. Each part, taken on its own, works correctly. The problem is that once the parts were connected, none of them took on the job of checking the destination.

Three organizations, the same mistake, separate fixes

According to the reports, a single researcher reported the same class of flaw to each organization in turn. Google, JPMorgan Chase and the French government (The Next Web names DINUM, the government's digital agency) each reportedly fixed it after receiving the report. Three organizations of different sectors and sizes independently built in the same mistake and independently fixed it.

Syed Anas Mohiuddin, the security researcher and founder of Cognivators who reported the flaw, reportedly wrote:

In May, Mohiuddin argued that MCP's risks lie more in implementations than in the specification. The accumulation of actual reports now backs that argument. This is not one organization's slip but a trap that people writing MCP servers fall into again and again. If the flaw were in a shared component, a single upstream fix would have been enough. In this case, each builder had to fix it themselves.

Five US federal servers unpatched after about five weeks, SSNs logged unredacted

The US federal government stands in contrast. According to the reports, five federal MCP servers have not been fixed about five weeks after the flaw was reported. TechTimes' headline says US servers remain exposed six weeks after Google and JPMorgan patched the flaw. As far as we could confirm, it has not been established which agencies run the servers.

The other problem in the headline is logging. Error responses containing veterans' SSNs were reportedly recorded without redaction. SSRF is a problem at the entry point: it allows requests to reach the internal network. On top of that, personal data appeared as-is in error responses and was kept as-is in the logs. That means safeguards were also missing at the exit point, in how errors and logs were handled.

Faced with the same flaw, the two private companies and the French government fixed it, while the five US federal servers have not been fixed. The protocol is the same, so the difference cannot come from the specification. It comes from the organizations that build and operate the servers. Whether they could act on a report translated directly into a difference in security.

The specification won't protect you; the implementation must

Other recent reports on MCP security point in the same direction. The OAuth flaw in the official Python SDK, which we reported on October 3, was fixed by an SDK update. But for authentication flows that do not involve user interaction, users still had to add configuration themselves even after updating. The draft MCP Events specification, which we reported on October 4, had no rule requiring subscription permissions to be rechecked. Both the specification and the SDK leave the final security checks to implementers. This SSRF case shows, through real examples at four organizations, what happens when organizations do not carry out the checks left to them.

Those building MCP servers need at least the following safeguards: restrict the destinations of received URLs with an allowlist; reject internal addresses and metadata endpoints; recheck the destination after any redirect; and strip personal data from error responses and logs. None of this is new technology. These are long-standing basics of web security. It is also a matter of applying the idea behind harness engineering, which is to not trust an agent's output and to constrain it at the layer before it, to the tool side as well.

Many points remain unconfirmed: which federal agencies run the servers, whether fixes are planned, and whether the logged SSNs have fallen into anyone's hands. The reports do not answer these questions. Until the organizations or the researcher publish primary information, everything here should be treated as based on media reports.