BlockRun MCP shipped v0.25.2 on June 29, and the entire release is one line in package.json: an overrides entry that forces ws up to 8.21.0. No new tools, no new endpoints, no version-bump theater. Just a dependency pin that had been quietly flagging five high-severity advisories across the whole chain underneath it — and a clean look at a problem that matters more for MCP servers than it does for your average npm package.
What was actually broken
According to the release notes, viem — the Ethereum library BlockRun MCP builds on — was pulling in ws@8.20.1 as a transitive dependency, one patch version behind the 8.21.0 fix. That single pinned version propagated a flag up the whole dependency chain: ws → viem → @x402/evm → @blockrun/clawrouter → @blockrun/llm. Five packages, one shared weak link, five high-severity entries in npm audit.
This is the boring, unglamorous shape most real supply-chain exposure takes. Nobody shipped malicious code. Nothing was exploited in the wild, as far as the release notes say. A library two layers down just hadn't bumped a dependency yet, and everything built on top of it inherited the exposure by default.
The fix, and what it actually touches
The fix is an overrides entry in package.json that forces viem's copy of ws to 8.21.0, regardless of what viem itself has pinned. Per the release notes, that single override cleared all five flagged advisories in that chain, taking the project's npm audit count from 15 down to 11. The maintainers report the same class of fix landed upstream in @blockrun/llm@3.5.1, via pnpm overrides covering both ws and form-data.
The part worth noting for anyone actually running this: overrides live in package.json, not in a lockfile you might not regenerate. That means every fresh npx install — which is how most people run an MCP server, not from a cloned repo with a pinned lockfile — pulls the patched ws automatically. No separate action required on the user's end. The maintainers also report 84 tests passing and green build/live-wallet smoke testing on this release; that's their own testing, not an independent audit, so treat it as claimed-and-plausible rather than verified.
What's still open
The release notes are upfront that three advisories remain, and frame them as outside this repo's direct control:
- ▸The Solana
web3.js-v1 dependency tree, viabigint-buffer, which the maintainers say lacks an upstream fix. - ▸An intentional pin on
rpc-websockets@9.3.0— bumping it, per the notes, would reintroduce ESM compatibility problems on Node versions below 20.19. - ▸A dev-only
esbuilddependency, which doesn't ship in the running server.
That's a reasonable list of trade-offs to make transparently, and naming them beats burying them. It doesn't mean the project is fully clean — it means the maintainers are choosing known, scoped risk over an upstream fix that isn't available yet.
Why this matters more for an MCP server than for a typical package
BlockRun MCP isn't just another npm install. It's an MCP server that hands AI agents live market, crypto, research, and X data, billed per call in USDC via x402 on Base and Solana — which means it's designed to sit next to a wallet an agent actually controls. A stale transitive dependency in a data-fetching CLI tool is an annoyance. The same class of bug in a server that a funded agent runs continuously, installed fresh via npx every time, is a live attack surface sitting closer to the money than most of the stack around it.
That's the pattern worth generalizing, not the specific CVE. If an agent can move funds, the dependency tree underneath the thing it's running is part of the security surface, not a background implementation detail. "It passed npm audit a few months ago" is not the same claim as "it's clean today." Overrides that live in package.json and travel with every fresh install are a better answer than a lockfile nobody regenerates.
What to watch
BlockRun MCP is early — open source, unverified on SatoHub, with a trust score that reflects liveness and transparency, not a safety guarantee. This patch is a good sign: the maintainers found the chain, named the remaining trade-offs instead of hiding them, and shipped the fix in a place every install picks up automatically. Whether that discipline holds as the BlockRun product family (the payment gateway, the Franklin agent, this MCP server) keeps shipping is the thing to actually track — not this one release, but whether dependency hygiene stays a habit once there's real money moving through it.