SW-MCP-005: Spec version older than 2026-07-28
Last updated 7 November 2026
| Fact | Value |
|---|---|
| Severity | Low |
| Checks | MCP server |
| Malicious indicator | No |
| OWASP Agentic Top 10 | ASI04 |
| OWASP MCP Top 10 | None mapped |
| NIST SP 800-53 | SR-3 (provisional mapping to SP 800-53 base controls) |
| First shipped in | Scanner 0.1.0 |
What it detects
The scanner reads the protocol version in this order. It takes the highest date in supportedVersions of the server/discover answer, and when there is none it takes the version that the initialize handshake negotiated. Only values that are real calendar dates in the form YYYY-MM-DD count. The rule fires when that version sorts before 2026-07-28.
It also fires, with the evidence no protocol version negotiated, when no version can be read and the server answered initialize but not server/discover. A probe with neither answer has no version to judge and is left alone. A version newer than the baseline never matches.
Why it matters
The protocol version tells a client which behaviours it can rely on. A server that stops at an older version does not offer the discovery request or the per-request metadata that the 2026-07-28 specification describes, so clients built for the new version meet gaps. Because the finding says only that an update is due, it is low. The scanner maps this rule to OWASP ASI04, Agentic Supply Chain Vulnerabilities, and to NIST SP 800-53 control SR-3, Supply Chain Controls and Processes.
Example
This recorded probe shows a server whose server/discover answer lists only the version 2025-11-25:
probe.json
{
"endpoint": "https://mcp.example.invalid/mcp",
"reachable": true,
"discover": {
"supportedVersions": [
"2025-11-25"
]
}
}A server check judges what a probe recorded, not files. The recorded probe above is read the way the scanner's README describes under Evaluating an MCP server probe.
How to fix
Update the MCP server library to a release that supports 2026-07-28 and list that date in supportedVersions. The migration checklist shows the changes that come with it, including the discovery request and the metadata a client sends with each call. Run the scan again afterwards: the checklist is built again from the new probe.
If it is a false positive
The version comes from what the server reports, so a server that supports the new version but lists it incompletely is reported wrongly. Fix the list. If the server is a third-party service you cannot change, accept the finding with a note that names the vendor and the version it says it will support.
If the finding is not a problem in your case, accept it with a note: in the dashboard a manager or owner can accept a finding and the note is kept with it; with the scanner on its own, add it to the baseline file with a reason and an expiry date.