fix(core): a provider wallet could take over x402 payment signing

[VickyXAI]

Summary

@blockrun/core@0.0.3 lets another application take over x402 payment signing. This ports the fix from blockrun-llm-ts#14 into core, adds the deliberate-adoption path the SDK gained in 3.8.0, and updates the CLI to match.

Root cause

resolveFromFiles() consulted ~/.<app>/wallet.json files before the canonical ~/.blockrun/.session, returning the most recently modified one:

const scanned = scanWallets();
if (scanned.length > 0) return { privateKey: normalize(scanned[0].privateKey), source: "provider" };
// ...only then .session, then legacy

resolvePrivateKey() is what signs payments — commands/x402.ts:91, chat.ts:21, media.ts:34, data.ts:12, sdk.ts:22. So installing another product, or writing one file into the home directory, silently redirects real spending across api, pay, chat, run, image, video, music, speech, and the data commands.

scanWallets() compounded it by reporting each file's self-declared address field instead of deriving it, so the takeover was invisible in the one command a confused user would reach for.

Demonstration

~/.blockrun/.session holds the user's real wallet 0xf39Fd…92266. A planted ~/.attacker/wallet.json holds a different key (really 0x7099…79C8) but declares "address": "0xf39Fd…92266".

Before (0.0.3):

$ blockrun --json wallet
{"address":"0x70997970C51812dc3A010C7d01b50e0d17dc79C8","source":"provider"}  // attacker's key is active

$ blockrun --json wallet recover
[{"source":"provider wallet.json","address":"0xf39Fd…92266"},   // claimed, not derived
 {"source":"session","address":"0xf39Fd…92266"}]
// meta.active = "provider wallet.json"

The user sees their own address twice and has no way to tell that the signing key changed.

After:

$ blockrun --json wallet
{"address":"0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266","source":"session"}   // unchanged

$ blockrun --json wallet list
[{"address":"0x70997970C51812dc3A010C7d01b50e0d17dc79C8", "source":"…/.attacker/wallet.json","active":false}]

$ blockrun --json wallet adopt 0xf39Fd6e51aad88F6F4ce6aB8827279cffFb92266
{"ok":false,"error":{"code":404,"message":"No discovered wallet controls 0xf39Fd…92266. Available: 0x7099…79C8"}}

Changes

core (0.0.3 → 0.1.0)

• resolveFromFiles() reads .session → legacy only. Discovered wallets never participate in automatic resolution.
• scanWallets() derives every address from the discovered key and drops entries whose key is missing or unusable. The file's address field is no longer trusted anywhere in the package.
• WalletSource drops "provider" — unreachable after this change. Breaking for callers narrowing on it.
• New listDiscoveredWallets() (no private keys) and adoptWallet(address). Adoption matches on the derived address and backs up the outgoing .session first, so funds are never stranded.

cli

• New blockrun wallet list and blockrun wallet adopt <address>.
• wallet recover orders by true resolution priority, marks exactly one entry active, and shows discovered wallets as inactive with their file path. meta.active previously named a wallet resolution would not use.

ci

• The smoke test packed only the CLI, so npm resolved @blockrun/core from the registry. It was verifying the last published core, not the code under review — which is how core drifted three weeks behind the SDK unnoticed — and any core version bump failed the step with ETARGET until it had already shipped. (This branch hit exactly that on its first run.) Both packages are now packed and installed as roots; blockrun --json version reports core: 0.1.0 from the tarball.
• The step now asserts the security property against the packed artifact users actually install. Confirmed to fail against the pre-fix build.

Validation

• pnpm build, pnpm typecheck — clean.
• pnpm test — 49/49 pass (was 39; +10 new, and one pre-existing test that asserted the vulnerable behavior is inverted).
• Mutation-verified, both halves. Restoring provider-first resolution turns 4 tests red; trusting the file's address field turns 3 red, including adoptWallet refuses an address no discovered key controls.
• End-to-end against a built CLI in an isolated BLOCKRUN_HOME, shown above.
• CI green on Node 20/22/24, with the new smoke assertions confirmed executing in the job logs (not passing vacuously — an earlier draft of the assertion silently captured only stdout, while err() writes to stderr; fixed and re-verified).

Note on the deleted test

"provider wallet.json is scanned and wins over .session (source=provider)" encoded the vulnerability as intended behavior. It is replaced by two tests asserting the opposite.

Follow-up

Publishing @blockrun/core@0.1.0 unblocks @blockrun/llm delegating its wallet layer to core — the goal of blockrun-llm-ts#13, which was closed because core could not yet absorb the SDK's 3.8.0 surface.