[SECURITY] Status of DNS Rebinding Vulnerability Fix for csharp-sdk

[JLLeitschuh]

I found (and reported to Anthropic here) that all major MCP Server SDKs were vulnerable to browser-based DNS rebinding allowing malicious websites to talk to locally or private network connected MCP servers.

This is was in violation of the MCP specification : https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#security-warning

This resulted in a slew of CVEs assigned to every major SDK:

• GHSA-w48q-cv73-mx4w
• GHSA-9h52-p55h-vw2f
• GHSA-xw59-hvm2-8pj6
• GHSA-8jxr-pr72-r468

It's not clear to me what version of the csharp-sdk this was fixed in as no CVE was assigned. Would the project maintainers behind this project be so kind as to do create a GitHub Security Advisory and request a CVE including the fix version and credit myself?

Thanks team!

[jayaraman-venkatesan]

@JLLeitschuh thanks for pointing this out.

I did create a poc to check if origin headers are being validated in server and looks like it's not.

Again, I may be wrong, tagging maintainers -
@halter73 / @mikekistler

[JLLeitschuh]

I was told by the anthropic security team that there are new automated SDK conformance checks in place that require any tier 1 SDK to conform to.

https://modelcontextprotocol.io/docs/sdk

The origin checks are supposedly in that testkit. How is it that this library is tier one without that test having failed?

[JLLeitschuh]

Friendly heads up, this is effectively an 0-day in the SDK

[jayaraman-venkatesan]

I have my branch over here where I have added origin header validation in request- LINK

I mostly tried to model it from typescript sdk, noticed they are doing host header validations too but I kept with origin validation only as it was said so in SPEC - I can raise a PR if you think this is good.

@halter73 / @mikekistler

[jeffhandley]

Thank you for raising this, @JLLeitschuh . And thank you for sharing your POC, @jayaraman-venkatesan.

While we acknowledge that the specification states, "Servers MUST validate the 'Origin'," we do not interpret this as MCP SDKs must validate the 'Origin'.
For ASP.NET Core applications, we rely on the built-in AllowedHosts feature for DNS rebinding mitigation, and this can be achieved using Host filtering with ASP.NET Core Kestrel web server.

We had also entertained adding APIs specific to allowed origins, similar to what @jayaraman-venkatesan's proof-of-concept implements, but we decided against it. ASP.NET Core already provides mechanisms for enabling CORS with origin policies. Duplicating that into the MCP SDK could result in diverging implementations for the same capability, leading to potential pitfalls over time.

Nonetheless, we recognize that our docs, samples, and even our own tests did not adequately provide guidance and illustration for servers to adhere to the specification or implement security best practices. We are preparing a pull request that will augment our docs, samples, and tests to demonstrate both AllowedHosts and using a CORS policy to validate the Origin. We will also update the 'mcpserver' project template in Microsoft.McpServer.ProjectTemplates to exercise those features.

Thank you again for raising this and the engagement here. We will post the link to our PR here once it's up, and we'd appreciate your reviews and feedback.

[JLLeitschuh]

While we acknowledge that the specification states, "Servers MUST validate the 'Origin'," we do not interpret this as MCP SDKs must validate the 'Origin'.

That's fine, as long as it's happening somewhere in the stack.

I want to verify that a default, out-of-the-box csharp-sdk based MCP server has, traditionally been protecting against this style of attack. If that's not the case, then I'd argue that this is a vulnerability in the csharp-sdk, as the SDK is supposed to be the "standard MCP server framework" and not guarding against this vulnerability as is required in the spec, would make this SDK not spec compliant, and thus leaves end users vulnerable.

Assuming that the csharp-sdk has been vulnerable by default, I believe, personally, that it the SDK should be self-validating ensuring that the end-user application is spec-compliant. IE, the server should fail to start if the underlying ASP.NET Core isn't configured correctly. This can, of course, be opted-out of. But that way, the user is intentionally accepting risk, rather than accidentally remaining vulnerable to this without knowing it.

Thoughts?