GHSA-WVJ2-96WP-FQ3F
Vulnerability from github – Published: 2026-02-26 22:20 – Updated: 2026-02-26 22:20The Go MCP SDK used Go's standard encoding/json.Unmarshal for JSON-RPC and MCP protocol message parsing. Go's standard library performs case-insensitive matching of JSON keys to struct field tags — a field tagged json:"method" would also match "Method", "METHOD", etc. Additionally, Go's standard library folds the Unicode characters ſ (U+017F) and K (U+212A) to their ASCII equivalents s and k, meaning fields like "paramſ" would match "params". This violated the JSON-RPC 2.0 specification, which defines exact field names.
Impact:
A malicious MCP peer may have been able to send protocol messages with non-standard field casing (e.g., "Method" instead of "method") that the SDK would silently accept. This had the potential for: - Bypassing intermediary inspection: Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages. - Cross-implementation inconsistency: Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.
Fix:
Go's standard JSON unmarshaling was replaced with a case-sensitive decoder (github.com/segmentio/encoding) in commit 7b8d81c. Users are advised to update to v1.3.1 to resolve this issue.
Credits:
MCP Go SDK thanks Francesco Lacerenza (Doyensec) for reporting this issue.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/modelcontextprotocol/go-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-27896"
],
"database_specific": {
"cwe_ids": [
"CWE-178",
"CWE-436"
],
"github_reviewed": true,
"github_reviewed_at": "2026-02-26T22:20:08Z",
"nvd_published_at": "2026-02-26T01:16:25Z",
"severity": "HIGH"
},
"details": "The Go MCP SDK used Go\u0027s standard encoding/json.Unmarshal for JSON-RPC and MCP protocol message parsing. Go\u0027s standard library performs case-insensitive matching of JSON keys to struct field tags \u2014 a field tagged json:\"method\" would also match \"Method\", \"METHOD\", etc. Additionally, Go\u0027s standard library folds the Unicode characters \u017f (U+017F) and K (U+212A) to their ASCII equivalents s and k, meaning fields like \"param\u017f\" would match \"params\". This violated the JSON-RPC 2.0 specification, which defines exact field names.\n\n#### Impact:\n\nA malicious MCP peer may have been able to send protocol messages with non-standard field casing (e.g., \"Method\" instead of \"method\") that the SDK would silently accept. This had the potential for:\n - **Bypassing intermediary inspection:** Proxies or policy layers that matched on exact field names may have failed to detect or filter these messages.\n - **Cross-implementation inconsistency:** Other MCP SDKs (TypeScript, Python) use case-sensitive parsing and would reject the same messages, creating potential security-boundary confusion.\n\n#### Fix:\n\nGo\u0027s standard JSON unmarshaling was replaced with a case-sensitive decoder (github.com/segmentio/encoding) in commit 7b8d81c. Users are advised to update to v1.3.1 to resolve this issue.\n\n#### Credits:\nMCP Go SDK thanks Francesco Lacerenza (Doyensec) for reporting this issue.",
"id": "GHSA-wvj2-96wp-fq3f",
"modified": "2026-02-26T22:20:08Z",
"published": "2026-02-26T22:20:08Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/go-sdk/security/advisories/GHSA-wvj2-96wp-fq3f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27896"
},
{
"type": "WEB",
"url": "https://github.com/modelcontextprotocol/go-sdk/commit/7b8d81c264074404abdf5aa16e2cf0c2d9c64cc0"
},
{
"type": "PACKAGE",
"url": "https://github.com/modelcontextprotocol/go-sdk"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
"type": "CVSS_V4"
}
],
"summary": "MCP Go SDK Vulnerable to Improper Handling of Case Sensitivity"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.