We Audited Our Own MCP Server Against 2026's 313 CVE Classes

Finding 1: The API Key Lives in a URL, Not a Header

This is the one we already suspected before opening the file, and it held up. validate_gstin's optional live-lookup path builds the GSTINCheck request like this, at line 213:

const apiKey = process.env.GSTINCHECK_KEY;
if (!apiKey) {
  result.live_status = "SKIPPED — set GSTINCHECK_KEY env var for live lookup";
} else {
  try {
    const res = await fetch(`https://sheet.gstincheck.co.in/check/${apiKey}/${g}`);
    const data = await res.json();

The API key is a path segment, not an Authorization header. That is GSTINCheck's own API design — we don't control their side of this — but it means the key rides in cleartext through anything that logs the request: reverse proxies, CDN access logs, any HTTP client tracing middleware layered in front of the call later, and the request line of any TLS-terminating box between us and sheet.gstincheck.co.in. This is CWE-598 in the classic sense, use of a GET request with sensitive data in the query/path, and it's exactly the shape of finding that lands in MCP01's 18 tracked CVEs.^[1]

Two things narrow the blast radius without closing it. First, nothing in the 536 lines calls console.log anywhere — we checked every line, the key never hits our own stdout or a local log file. Second, the value substituted for g in that URL is already format-validated before this line runs (more on that below), so the injection surface via the GSTIN argument itself is closed. What's left is the key. We did not test whether a network failure's e.message leaks the constructed URL back into the tool's own response — that's worth a deliberate test with a forced DNS failure before we call this fully scoped, not something we're going to assert from a static read.

Finding 2: Do We Sit in the STDIO RCE Blast Radius?

In April 2026, security researchers disclosed roughly ten vulnerabilities rooted in unsafe defaults in how Anthropic's official MCP SDK handles the STDIO transport's configuration layer — present across the Python, TypeScript, Java, and Rust SDKs.^[2] The core problem: the mechanism that turns an MCP client's config entry — a command plus args pair — into a spawned local process doesn't actually restrict that command to legitimate MCP server binaries. Given the right conditions it will run arbitrary OS commands, through both authenticated and unauthenticated paths, plus a hardening-bypass variant and a zero-click route where prompt injection edits an agent's own MCP configuration to add a malicious server entry — triggered just by an agent browsing a compromised MCP marketplace listing.

Here's the honest scoping question: is india-stack-mcp in that blast radius? No, and yes, depending on which side of the wire you mean.

No — server.js is the thing being spawned, not the thing doing the spawning. It never parses a command field, never calls spawn or exec, and never touches a config file describing other servers. The vulnerable code path the researchers describe lives in the client-side launcher — whatever host turns a mcpServers entry into a running process. That's Claude Desktop's, Claude Code's, or Hermes's code, not ours.

Yes — because the config entry that launches india-stack-mcp in the first place is exactly the shape of thing the April flaw targets. A clean server.js buys nothing if an attacker can tamper with the command/args pair that starts it — the zero-click path runs before our code ever executes. We can audit our own 536 lines all day; we can't audit our way out of a compromised launcher config from inside the server it launches. That's a config-integrity problem sitting one layer above the code we actually control.

One more thread worth pulling on the SDK itself: package.json pins @modelcontextprotocol/sdk at ^1.10.2, a version released April 22, 2025 — a full year before the April 2026 disclosure.^[3] The caret range means npm doesn't actually install 1.10.2; checking node_modules shows the resolved version is 1.29.0, current as of today. That's almost certainly past whatever version shipped fixes for the April CVEs, but “almost certainly” isn't the same as confirmed against the SDK's own security advisories, which we haven't cross-checked version-by-version. And a loose caret floor that happens to resolve forward is not the same discipline as the exact-version pinning we argued for in the Hermes piece — where a single patch release silently changed list_directory's output format and broke a downstream parser. india-stack-mcp doesn't follow its own team's advice here.

Finding 3: Input Validation Actually Held

This is the boring finding, and boring is the goal. Two tools build outbound URLs directly from caller-supplied arguments: validate_gstin and lookup_ifsc. Both format-validate the argument with an anchored regex before it ever reaches a template string.

function validateGstinFormat(gstin) {
  const regex = /^[0-9]{2}[A-Z]{5}[0-9]{4}[A-Z]{1}[1-9A-Z]{1}Z[0-9A-Z]{1}$/;
  return regex.test(gstin.toUpperCase());
}

Fifteen characters, digits and uppercase letters only, anchored at both ends. Nothing that matches this pattern can carry a /, a ?, or a & into the GSTINCheck URL, which closes off path traversal and query-string injection via the gstin argument itself. lookup_ifsc does the same with /^[A-Z]{4}0[A-Z0-9]{6}$/ before hitting https://ifsc.razorpay.com/${code}, and get_india_holidays gets the same protection for free from its Zod schema — z.number().int().min(2024).max(2030) — before year lands in https://date.nager.at/api/v3/PublicHolidays/${year}/IN. A number bounded to a six-year integer range can't inject anything into a URL path.

Two arguments aren't format-restricted — state on get_india_holidays and category on get_gst_rates — but neither reaches a URL, a shell command, or a database query anywhere in the file. state gets echoed straight into result.state_context for display; category only ever gets compared against a static in-memory array with .includes(). The exposure there, if there is one, is an agent echoing back whatever the calling model already handed it — a much lower bar than the third-party data problem below, since it's the caller's own input coming back to the caller.

Finding 4: The Data We Never Touch After It Leaves gstincheck.co.in and Razorpay

This is the finding we didn't expect walking in, and it's the one worth taking seriously. validate_gstin's live-lookup branch takes these fields straight from GSTINCheck's JSON response and drops them into the tool's return value with zero transformation:

result.live_status = data.data?.sts || "Unknown";
result.legal_name = data.data?.lgnm;
result.trade_name = data.data?.tradeNam;
result.registration_date = data.data?.rgdt;
result.principal_address = data.data?.pradr?.addr;

lookup_ifsc does the identical thing with Razorpay's IFSC database — BANK, BRANCH, ADDRESS, CITY, DISTRICT, STATE, CONTACT all pass through JSON.stringify(result, null, 2) unmodified. We grepped the whole 536 lines for anything resembling sanitization, escaping, or character stripping. There isn't one. Not a single function in this file touches a string field for safety before it goes into a tool response.

Here's why that matters more than it looks: trade_name is applicant-supplied free text at GST registration time, not a government-curated value like the holiday names Nager.Date returns. We did not test what character set GSTN's own registration portal permits in that field — that's out of scope for a server-side code audit — but we can say with certainty that nothing downstream of GSTN, not GSTINCheck's passthrough and not validate_gstin, re-validates or strips it before it lands in an agent's context window as a trusted-looking JSON field. That's the textbook shape of MCP06, prompt injection via contextual payloads — only 7 of the tracker's 313 CVEs, and now we understand why the count is that low. It doesn't crash anything. It doesn't 500. It just sits there as a business name until whatever's reading the tool output decides how much to trust it.

One mitigating factor worth stating plainly: everything in this server returns as { type: "text", text: JSON.stringify(...) }, never rendered markdown or HTML. That closes off an XSS-style rendering exploit against any UI that might display this output — the risk here is specifically an LLM context-injection channel, not a browser one.

The Scorecard

What Changes Next

Two of these four are real, live, and worth fixing rather than filing away. The credential-in-URL problem is bounded by GSTINCheck's own API shape — the fix on our side is confirming error paths never echo the constructed URL back to the caller, and treating any logging layer added in front of this fetch call as a secret-exposure risk by default. The tool-output sanitization gap is entirely ours to close: a basic allow-list pass on legal_name, trade_name, principal_address, and the Razorpay bank/branch fields before they leave the tool, or at minimum wrapping third-party string fields in an explicit “untrusted external data” marker so whatever reads this tool's output downstream knows not to treat a trade name as an instruction. The SDK version pin moves from a caret range to an exact version, which is the same discipline we already argued for in the Hermes reference and didn't apply to our own server until this audit forced the comparison.

None of this required guessing at what 2026's MCP CVE classes look like in the abstract — the OWASP MCP Top 10 breakdown on the tracker gave us the categories, and reading our own 536 lines against each one gave us the actual answer for this server, not a generic checklist answer. If you're running your own GST/IFSC tooling and want to poke at the same data these tools surface, the GSTIN Validator, IFSC Code Finder, and GST Rate Finder are the same lookups as standalone browser tools, and the JSON Formatter is the fastest way to eyeball a raw API response before deciding whether to trust a field in it.

Related WOWHOW guides: the Hermes Tool Gateway reference this server is wired into, the MCP 2026-07-28 auth RC breakdown for the authorization side of this same threat model, and the Least-Privilege MCP Governance Layer for the scope-and-allowlist controls that catch exactly the kind of unsanitized-output problem Finding 4 describes. The MCP Server Pack ships the version-pinning and circuit-breaker patterns referenced above already applied, included in Pro Vault.

Sources

1. MCP CVE Project — 313 indexed CVEs, OWASP MCP Top 10 breakdown
2. Anthropic MCP Design Vulnerability Exposes AI Agents to STDIO Command Execution — The Hacker News, April 2026
3. @modelcontextprotocol/sdk — npm registry, version history