[security] Remote MCP headers templates read arbitrary process.env — the stdio allowlist from #208 is not applied on the HTTP path #215

Activity

1. uos1231234 commented on Oct 1, 2026

   

   uos1231234

   on Oct 1, 2026

   Author

   More actions

   I tried to break this report and could not falsify the core claim. Three things in it are wrong or too weak, and one materially understates the exposure. Correcting all four.

   1. Correction: the allowlist has 12 entries, not 11

   DEFAULT_INHERITED_ENV_VARS on win32 is 12 entries (SDK stdio.js:8-22): APPDATA, HOMEDRIVE, HOMEPATH, LOCALAPPDATA, PATH, PROCESSOR_ARCHITECTURE, SYSTEMDRIVE, SYSTEMROOT, TEMP, USERNAME, USERPROFILE, PROGRAMFILES. The substantive point — none of them are credential names — is unaffected.

   2. Correction: this is a documented, tested feature, not a leftover from #208

   I framed the asymmetry as "#208 tightened stdio and forgot the header path". The mechanics were right, the characterization was not. The interpolation is an intentional Claude-compat feature, documented in the code:

   mcp.ts:466-475 — "A plugin's .mcp.json may write headers and interpolate the environment ("Bearer ${API_KEY:-}"), which is Claude's format."

   and covered by the repository's own end-to-end test:

   mcp-startup.test.ts:241-305 — "carries Claude plugin headers, including environment interpolation", asserting expect(seen).toContain("from-env") against a real HTTP server.

   docs/step-unified-config-and-mcp.md §1.5 also lists bearer_token_env_var / http_headers / env_http_headers as intended env-driven header features. PR #208 = merge ec1cd22, whose stat touches only mcp-environment.ts, mcp.test.ts and plugins.ts — not mcp.ts.

   The accurate framing is therefore: the HTTP header path has no allowlist of its own, while #208 established one for stdio, and the two paths were never aligned. That is a real gap, but it is a missing-allowlist gap rather than an accidental omission, and the fix should be scoped that way — tightening the shared rule, not removing the feature.

   3. The exposure is larger than I reported: ${} is not required

   There are two additional template-free paths in the same file, both reading process.env directly with no allowlist. I missed them, which makes my report an undercount:

   • env_http_headers — accepted at mcp.ts:513-518, expanded at mcp.ts:621-628 via process.env[envName]?.trim(). A manifest can write {"X-Plain":"AWS_SECRET_ACCESS_KEY"} and needs no $ syntax at all.
   • bearer_token_env_var — mcp.ts:629-634 turns any variable name directly into Authorization: Bearer $VAR.

   plugins.ts:310 copies mcpServers with structuredClone and no per-server field validation, and readPluginManifestAtPath (plugins.ts:350-382) also auto-adopts a sibling .mcp.json, so all three are reachable from a plain manifest.

   4. Closing the gap in my reproduction: wire-level evidence

   My report only exercised expandHeaderTemplate as a pure function, which was the weakest part. An independent pass built the full unmocked chain — real addMarketplaceSource → real installMarketplacePlugin → real discoverStepMcpServers → real StreamableHTTPClientTransport → a local node:http server capturing the bytes:

   x-aws:       CANARY-AWS-LEAK-0001
   x-gh:        CANARY-GH-LEAK-0002
   x-oai:       CANARY-OAI-LEAK-0003
   x-unrelated: CANARY-UNRELATED-LEAK-0004
   x-plain:     CANARY-PLAIN-LEAK-0005      (via env_http_headers, no ${} needed)
   

   The path from http_headers to the wire is a straight line with no branch: mcp.ts:553 resolveHttpHeaders → :554-555 requestInit: { headers } → SDK streamableHttp.js:58-77 _commonHeaders() merges them into the Headers used on GET/SSE, POST and DELETE.

   One property worth stating precisely, because it is not a mitigation: an unset variable causes the header to be omitted entirely (the literal template never reaches the server), so only variables that are actually set can be exfiltrated. That is not a mitigation — the variables worth stealing are exactly the ones that are set.

   Threat model, stated explicitly

   This requires the user to install a plugin (or have one preinstalled via #214) and the URL is chosen by the plugin author, so it is not an unauthenticated remote issue. The property that makes it worth fixing anyway: a plugin that declares only a remote server executes no local code, so the user sees no local execution signal, while their environment is still exfiltrated. That is a different trust decision from "a stdio plugin can run arbitrary code anyway".
2. uos1231234

   closed this as completedon Oct 2, 2026
3. uos1231234 commented on Oct 10, 2026

   

   uos1231234

   on Oct 10, 2026

   Author

   More actions

   Closing rationale, recorded so this doesn't need re-investigating.

   SECURITY.md covers this report in two places:

   • :70-71 — "...prompt injection, or a malicious trusted extension/skill are not
     security vulnerabilities under this model."
   • :74-77 — "...malicious contents written to a trusted StepCode configuration file
     cause StepCode to ... send credentials to an attacker-controlled endpoint ...
     is out of scope."

   The reported path is a plugin manifest naming an environment variable and sending it
   to the endpoint that same plugin declared, so both clauses apply. SECURITY.md is
   unchanged since this was filed.

   The mechanism is still present on main (3d70bae): env_http_headers
   (mcp.ts:650) and bearer_token_env_var (mcp.ts:655) read process.env with no
   allowlist, and the HTTP path never received the allowlist #208 added for stdio. I
   filed that as an implementation-consistency gap rather than a vulnerability, since
   both fields are documented and a user setting one for their own server is not a
   boundary crossing.

   Correction

   One claim above has the wrong field name. The report says http_headers supports
   ${VAR:-fallback} interpolation. It does not — bda152e made http_headers a
   verbatim literal, with a regression test asserting exactly that. Interpolation lives
   on the plugin headers alias, which reaches expandHeaderTemplate (mcp.ts:441,
   no allowlist) before landing in http_headers. The mechanism is real; the field I
   named for it was not the right one.

   No action requested.