Skip to content
T threat.cafe

· Constance Ibe-Whitmore (editorial persona) · Agent artifact supply chain · on threat.cafe

October 31 is a supply-chain event: what to do about Smithery URLs left in your MCP configs

Any MCP configuration that points at run.tools or server.smithery.ai is in scope from 31 October 2026, when Smithery says its proxy and managed identity service stop working. The shutdown itself is orderly and not malicious; the exposure is what stays behind: a remote endpoint that nobody maintains for you, sitting in configs that agents still read. Operators should find every Smithery reference, replace it with the publisher's own endpoint after verifying ownership, and delete the rest.

Who is in scope, and from when

The scope covers any developer, team or managed service whose MCP client configuration references a Smithery-run URL or launches a server through the Smithery CLI. The effective date is 31 October 2026, as set out in Smithery's shutdown notice. The guidance in this post applies on and after that date; nothing in it expires when the services go dark.

Three groups are in scope, in descending order of exposure.

  • Teams that used Smithery's managed identity for their own users. Smithery's notice asks these teams to have a replacement in place before 31 October. Credentials and connection flows built on that service stop working.
  • Individual developers with Smithery URLs in client configs. Entries in Claude Code, Claude Desktop, Cursor, VS Code, Codex or OpenCode configs stop resolving to a working service.
  • Organisations that distribute configs. Templates, dotfile repositories and onboarding scripts copy stale entries to new machines long after the original user has moved on.

Out of scope: configs that list a server by its publisher's own domain, and teams that only browsed the smithery.ai registry. The registry continues, so a link to a registry page is a documentation matter rather than a live connection.

What Smithery has stated

Smithery's position, as a vendor statement, is set out in its notice signed by cofounder Anirudh Kamath ("Smithery (now part of Arcade)"). The notice says: "On October 31, 2026, we're shutting down Smithery's connection management services." According to the same notice, the following stop working on that date:

  • server URLs on run.tools and server.smithery.ai
  • the Smithery API, Connect and Toolbox
  • accounts and API keys
  • the CLI and SDKs, whose current versions will be marked deprecated

Smithery states that smithery.ai remains "a public (non-proxied) MCP registry", described as "now powered by Arcade.dev". For a curated set of verified servers, the registry page shows the vendor's direct MCP URL. Smithery advises individual users to switch to each vendor's official MCP URL, and paid users are being refunded for charges since 5 August.

The notice follows an earlier change. In a January 2026 post, Smithery stopped new free-plan hosting deployments and kept existing free-plan servers live until 1 March 2026.

Smithery's notice does not address the future of its domains, and this post makes no claim that any Smithery domain will change hands; the concern is general and applies to any stale endpoint.

Why a dead endpoint remains an exposure

A remote MCP entry is a standing instruction to an agent: when these tools are needed, connect to this address. The instruction stays in force until someone deletes it, although most of the time a dead entry produces an error and nothing more.

The risk lies in what happens if an address ever answers again under different control. The Hacker News reports that Pillar Security found a flaw in OpenCode on Windows and WSL. OpenCode passed a sign-in URL supplied by a remote MCP server to a helper that built a shell command without escaping it, so a malicious server could run commands with the developer's privileges once the developer started sign-in. Pillar reported the flaw privately on 29 August and disclosed it on 19 October 2026, and versions 1.0.137 to 1.18.32 are affected; 1.18.33, released 28 September, fixes it. No CVE was requested, so scanners will not flag affected builds.

The write-up states the point directly: the attacker's server "need not be hostile from the start. One that is later taken over, or a domain that changes hands, could carry the same address."

Sign-in flows deserve particular attention. A connection that breaks on 31 October invites a developer to re-authenticate, and re-authentication is exactly the step that reached the OpenCode flaw. The threat.cafe reading, set out in our post "Approved last month, malicious today: a re-verification cadence", is that a remote endpoint's verdict depends on who controls it now.

Obligations: must, should, may

The threat.cafe Stale Endpoint Obligations Matrix below separates what operators must do from what is prudent and what is optional. These are operational obligations derived from the facts above; none is a legal requirement or a Smithery instruction unless marked as such.

Operators must remove or replace every live reference to run.tools, server.smithery.ai and the Smithery CLI. Each must be deleted, not commented out, because a commented entry is one edit from being re-enabled. Operators must revoke Smithery API keys and any credentials shared with proxied servers. Operators running OpenCode on Windows or WSL must be on 1.18.33 or later, checked by version since no advisory exists.

Operators should verify each replacement endpoint against the publisher's own documentation or repository before use. A registry page is a useful lead, but verification belongs to the publisher's domain, so operators should record the publisher, domain, verifier and date for every remote endpoint, and set a re-verification date. Distributed templates and dotfiles should be cleaned in the same change.

Operators may keep documentation links to registry pages, since the registry continues. Operators may choose Arcade or another provider for managed connections; Smithery's notice offers help choosing one. Operators may remove a server entirely when no publisher-run endpoint exists.

THREAT.CAFE STALE ENDPOINT OBLIGATIONS MATRIX (Smithery, from 31 Oct 2026)

MUST    Remove/replace run.tools, server.smithery.ai, @smithery/ CLI entries
MUST    Delete entries; do not comment them out
MUST    Revoke Smithery API keys and shared credentials
MUST    OpenCode on Windows/WSL >= 1.18.33 (no CVE; check version directly)
SHOULD  Verify replacement against the publisher's own docs or repo
SHOULD  Record publisher + domain + verifier + date; set re-verify date
SHOULD  Clean templates, dotfiles, onboarding scripts in the same change
MAY     Keep registry links in documentation (registry continues)
MAY     Choose any managed-connection provider
MAY     Remove a server outright when no publisher endpoint exists

Vendor statement (Smithery): URLs, API, accounts, CLI and SDKs stop on 31 Oct 2026
Operator obligation (threat.cafe): everything above

Finding the references

A read-only search across common MCP config locations finds most references; the commands below change nothing. Adjust paths for your clients and operating system, and run the recursive search over your organisation's repositories with your code search tool as well.

# Read-only. Prints matches with line numbers.
grep -nE 'smithery\.ai|run\.tools|@smithery/' \
  ~/.claude.json \
  ~/Library/Application\ Support/Claude/claude_desktop_config.json \
  ~/.cursor/mcp.json \
  ~/.copilot/mcp-config.json \
  ~/.codex/config.toml \
  2>/dev/null

# Project-level configs under your code directory:
grep -rnE 'smithery\.ai|run\.tools|@smithery/' ~/code \
  --include='.mcp.json' --include='mcp.json' \
  --include='claude_desktop_config.json' --include='*.toml' \
  2>/dev/null

# Windows (PowerShell), Claude Desktop:
# Select-String -Path "$env:APPDATA\Claude\claude_desktop_config.json" `
#   -Pattern 'smithery\.ai|run\.tools|@smithery/'

# VS Code user MCP config: open with "MCP: Open User Configuration".
# OpenCode: run "opencode mcp list".

The recursive search matches .vscode/mcp.json, .cursor/mcp.json and project .mcp.json files by name. Claude Code keeps user and local scope servers in ~/.claude.json, per its MCP documentation, and VS Code's configuration reference lists .vscode/mcp.json, a user-profile mcp.json and ~/.copilot/mcp-config.json. Some matches will be registry links in comments; those may stay.

Migration worksheet

SMITHERY MIGRATION WORKSHEET (one row per entry found)

Config file / scope   | e.g. ~/.cursor/mcp.json (user), repo .mcp.json (project)
Server name           |
Current reference     | URL on run.tools / server.smithery.ai, or CLI launch
Still needed?         | yes / no  (no -> delete the entry, then revoke credentials)
Publisher             | organisation that builds the server
Replacement endpoint  | publisher's own URL or install method
Domain owner check    | how verified (publisher docs, repo, DNS) + who + date
Auth method           | OAuth / API key / none; credentials rotated? y/n
Client versions       | e.g. OpenCode >= 1.18.33 on Windows/WSL
Action taken          | replaced / removed (not commented out)
Copies cleaned        | templates, dotfiles, docs, onboarding scripts
Re-verify on          | date
Inventory updated     | publisher + domain + verdict recorded y/n

The strongest counterargument

The strongest counterargument holds that a dead URL is harmless: the connection fails, the developer notices, and nothing runs. On that view, cleaning configs is housekeeping, not supply-chain work.

The evidence points the other way for two reasons. First, the OpenCode case shows that the dangerous moment can be sign-in, which a broken connection invites. Second, configs outlive the people who wrote them, and copies travel through templates. An entry that fails today is a standing instruction that someone else may satisfy later, and deleting it costs minutes.

Where this would be wrong

The analysis would overstate the risk if MCP clients refused to reconnect to an endpoint whose ownership had changed, or pinned endpoints to a verified identity. The analysis would also be wrong for configs already managed through an allowlisting gateway that blocks unknown remote endpoints; there, a stale entry fails closed. And if Smithery or Arcade publish a commitment covering the run.tools and server.smithery.ai domains, the long-tail concern narrows, though the hygiene steps remain sound.

What to tell the people who sign off

  • Finance: the work is config edits and credential rotation; no purchase is required.
  • Security lead: the blast radius is any client that reconnects or re-authenticates to a stale address.
  • Legal and compliance: keep the worksheet as evidence of what was removed, when and by whom.
  • Operations: removal is a one-line change per entry; rollback is restoring the entry from version control.

Open questions

The number of configs that still point at Smithery URLs is unknown, as is the number of teams that relied on managed identity for their own users. Other MCP clients have not been publicly assessed against the OpenCode sign-in pattern. Whether every server in the registry has a publisher-run endpoint is also unknown; where none exists, removal may be the right answer.

Unknown isn't the same as safe. Before reconnecting a client, check the endpoint against the threat.cafe board.

Volatility: SEMI-VOLATILE. Review when Smithery or Arcade publish changes to the run.tools or server.smithery.ai domains, or when another MCP client discloses a sign-in flaw.

Sources

#mcp #smithery #remote-mcp-endpoints #config-hygiene #inventory

All posts