`/api/devnet-register-mint` can register syntactically valid addresses without verifying an on-chain devnet SPL mint exists

[Bayyan16]

Weakness class	CWE-306 (Missing Authentication), CWE-345 (Insufficient Verification of Data Authenticity)
Affected routes	POST /api/devnet-register-mint (the writer); POST /api/devnet-mirror-mint (the poisoned consumer)
Affected files	app/app/api/devnet-register-mint/route.ts lines 82-86 (format-only check), 112-121 (upsert); app/app/api/devnet-mirror-mint/route.ts lines 248-260 (early return), 384-396 (ignoreDuplicates upsert)
Assessed at	7ce465b — HEAD of playground as of 2026-08-16. First verified at 8d3e280; re-verified after GH#2519 (confirmation checks only — registry logic untouched)
Related issues	#1771 / #1799 (production incidents proving devnet_mints rows gate user-facing flows), #2477 (this route's per-instance-only throttle)

TL;DR

POST /api/devnet-register-mint writes rows into devnet_mints — the registry that /api/devnet-airdrop and /api/devnet-pre-fund consult — after checking nothing but the base58 shape of the submitted address. Anyone can insert rows naming any mainnet CA with attacker-chosen symbol and decimals, at 20 rows/hour per serverless instance, and those rows can never be corrected through the API (ignoreDuplicates: true). Today this pollutes a registry that two live routes trust for authorization and amount math; if /api/devnet-mirror-mint is ever re-wired to a frontend flow, the same rows permanently break mirror creation for every squatted CA.

1. What the route does

The route exists to record a devnet mint in the devnet_mints mapping table (mainnet_ca → devnet_mint, plus name, symbol, decimals). Its entire validation posture is:

// app/app/api/devnet-register-mint/route.ts
try { new PublicKey(mintAddress); } catch { ... 400 }     // lines 82-86 — the ONLY check
...
const { error } = await supabase.from("devnet_mints").upsert({
  mainnet_ca: mintAddress,        // attacker-chosen registry key
  devnet_mint: mintAddress,       // the "devnet mint" IS the (mainnet!) address itself
  name: safeName, symbol: rawSymbol, decimals: safeDecimals,
}, { onConflict: "mainnet_ca", ignoreDuplicates: true }); // lines 112-121 — first writer wins forever

Never verified: that the address exists on devnet, that it is an SPL mint, or that its mint authority is the server keypair — a check this codebase already ships in app/app/api/devnet-pre-fund/route.ts:402-429 (getMint() + authority comparison).

2. What is exploitable today (verified at HEAD)

1. Unauthenticated, unverified registry writes — 20 rows/hour/instance (the in-memory Map at lines 26-40 is per-instance, the failure class Rate limiters silently fail open (per-instance) when Upstash is unconfigured #2477 tracks).
2. Unrepairable through the API — ignoreDuplicates: true (line 120) means a squatted mainnet_ca row can never be corrected by re-registration; cleanup requires direct DB access.
3. Attacker-chosen decimals feeds consumer math — /api/devnet-airdrop reads decimals from devnet_mints rows (route.ts:491-503) and scales grant amounts with 10 ** decimals; the stored value is accepted verbatim (any integer 0-18).
4. The registry feeds an allowlist — /api/devnet-pre-fund treats a devnet_mints row as "permitted" (route.ts:190-215); for a squatted CA the row's devnet_mint equals the mainnet address, so the DB check passes and only the downstream on-chain getMint authority check stops the mint. The allowlist is being fed unverified data.

3. The latent poisoning chain (why severity is Low, not Medium)

If /api/devnet-mirror-mint is ever called with a squatted CA — by a future wizard re-wiring, old runbook docs, or any new consumer — it consults the registry before creating a mirror and returns early on any hit:

// app/app/api/devnet-mirror-mint/route.ts:248-260
const existing = supabase
  ? (await supabase.from("devnet_mints").select("devnet_mint, name, symbol, decimals, logo_url")
      .eq("mainnet_ca", mainnetCA).maybeSingle()).data
  : null;
if (existing?.devnet_mint) {
  return NextResponse.json({
    status: "existing",
    devnetMint: existing.devnet_mint,   // ← for a squatted row: the MAINNET address itself
    ...
  });
}

The caller is told a devnet mint exists; none does. Every later on-chain step fails far from the cause, and both repair paths refuse (ignoreDuplicates here at line 120 and in mirror-mint's own upsert at line 392) — the mapping is broken permanently until manual DB cleanup.

Why latent: the current wizard no longer calls devnet-mirror-mint at all — the mirror-collateral model was removed (CreateMarketWizard.tsx:330-342: "devnet collateral is ALWAYS Sim-USDC … skip it for every devnet market"), and the post-launch airdrop goes through /api/devnet-airdrop (useCreateMarket.ts:3342-3346). A repo-wide search finds no runtime frontend caller for devnet-mirror-mint, devnet-register-mint, or devnet-mint-token. The §2 exposure, however, is live today against the public deployment.

4. Impact

Today: unauthenticated pollution of a registry two live routes consult, with attacker-influenced metadata (decimals, symbol) and no API-level repair. Latent: permanent mirror-creation poisoning for any squatted CA the moment a devnet_mints.by_mainnet_ca consumer is (re)introduced. Severity Low reflects the removed primary consumer; the unverified-write defect itself is unconditional.

5. Proof of concept

# 1) Unverified write — the "mint" need not exist on any cluster.
CA="<any mainnet CA not yet in devnet_mints>"
curl -s -X POST https://<playground-host>/api/devnet-register-mint \
  -H 'Content-Type: application/json' \
  -d "{\"mintAddress\":\"$CA\",\"name\":\"Squatted\",\"symbol\":\"SQAT\",\"decimals\":18}"
# → {"status":"registered","mintAddress":"$CA"}
#    Registry row: mainnet_ca=$CA, devnet_mint=$CA, decimals=18  (unverified, unrepairable)

# 2) Permanence — re-registration cannot repair:
curl -s -X POST https://<playground-host>/api/devnet-register-mint \
  -H 'Content-Type: application/json' \
  -d "{\"mintAddress\":\"$CA\",\"name\":\"Legit\",\"symbol\":\"REAL\",\"decimals\":6}"
# → {"status":"registered"} but the row is UNCHANGED (onConflict + ignoreDuplicates).

# 3) Live consumer effect — devnet-airdrop resolves through devnet_mints and trusts
#    the stored decimals (route.ts:491-503): the squatted row's decimals=18 feeds
#    10**decimals in any airdrop that resolves through it; for the self-referencing
#    row the native-mint fallback engages — the registry's row shape directly
#    steers a live route's behavior.

# 4) LATENT chain — fire mirror-mint directly (what any future consumer would hit):
curl -s -X POST https://<playground-host>/api/devnet-mirror-mint \
  -H 'Content-Type: application/json' \
  -d "{\"mainnetCA\":\"$CA\",\"walletAddress\":\"<any wallet>\"}"
# → {"status":"existing","devnetMint":"$CA","name":"Squatted",...}
#    Asserts a devnet mint exists — but $CA is a MAINNET address. No devnet mint
#    is ever created for this CA again (early return + ignoreDuplicates everywhere).

6. Recommended fix

Gate registration on a property only genuine server-created mirror mints possess — their mint authority — copying the in-repo pattern from devnet-pre-fund/route.ts:402-429:

// after the format check (line 86):
const mintInfo = await connection.getMint(new PublicKey(mintAddress)); // throws if absent on devnet
if (!mintInfo.mintAuthority?.equals(serverMintAuthorityPk)) {          // getDevnetMintSigner().publicKey()
  return NextResponse.json({ error: "Not a Percolator mirror mint" }, { status: 400 });
}

Given that no frontend calls this route (or devnet-mint-token/devnet-mirror-mint) at HEAD, removing the three legacy routes — or gating them behind checkAdminSecret — equally retires the latent chain. If they stay: join the shared durable fund limiter (checkFundRateLimit) in place of the per-instance Map (#2477 class), and replace ignoreDuplicates: true with a plain upsert so verified re-registrations can repair rows.

7. References

• app/app/api/devnet-pre-fund/route.ts:402-429 — in-repo on-chain mint-authority verification to copy
• app/app/api/devnet-airdrop/route.ts:491-503 — live consumer trusting devnet_mints metadata (decimals)
• app/hooks/useCreateMarket.ts:3342-3346, app/components/create/CreateMarketWizard.tsx:330-342 — the removed mirror model (why the chain is latent)
• Bug: devnet-airdrop fails for mints shared across multiple markets (.maybeSingle() multi-row error) #1771 / Bug: devnet-pre-fund rejects valid mints with multiple devnet_mints rows (PGRST116) #1799 — production incidents proving devnet_mints row state gates user flows
• Rate limiters silently fail open (per-instance) when Upstash is unconfigured #2477 — per-instance in-memory limiter fail-open class

[dcccrypto]

Re-triaged 2026-09-02 — "fully unverified" is no longer accurate. One real gap remains. Keeping open for that.

The route now validates every field before the upsert (app/app/api/devnet-register-mint/route.ts:50-107):

check	line
devnet-only (403 on mainnet)	:51
per-IP rate limit, 20/hour	:57
malformed JSON → 400	:68
mintAddress present and a valid PublicKey	:78, :83
name via isPrintableName (1–64 chars, charset)	:89
symbol via isTicker (1–12, A-Z0-9._-)	:97
decimals integer 0–18	:105

The gap that remains: nothing checks the mint exists on-chain, or that the caller controls it. A syntactically valid pubkey for an account that was never created still upserts into devnet_mints, so the registry can carry entries with no corresponding mint.

That is worth closing and is mechanical — fetch the account and confirm it is an SPL mint owned by the token program, the same shape keeper-register already uses to verify a pool exists before binding it (:19-22 there). Ownership proof is a separate, larger question (it would need a signature, changing the client contract).

Method note on my own triage: my first pass grepped this file for validate|verify|check|require and got zero matches, which read as "no validation at all". The helpers are named isPrintableName / isTicker / isRateLimited — a naming mismatch, not an absence. Recording it because a zero-match grep is not evidence of absence.

[Bayyan16]

Thanks for the re-triage — agreed. I re-checked the assessed revision and the helper-based shape validation was already present, so “fully unverified” was too broad on my side.

The remaining issue is narrower: a syntactically valid address could still reach devnet_mints without verifying that a corresponding devnet SPL mint actually exists.

I also checked 5d6cbf5; the fail-closed on-chain existence/type check before the DB upsert matches that remaining gap well.

Agreed as well on keeping caller-control/ownership proof separate, since that would require a client-contract change rather than this mechanical server-side validation.

I’ll re-verify the narrow regression once the fix lands on playground.

[dcccrypto]

FIXED and merged in PR #2527. Closing.

/api/devnet-register-mint now verifies the mint exists on-chain before registering it, and fails closed with a 503 when the check cannot be performed — rather than registering an unverifiable mint.

That direction matters more than the check itself. The fail-open version of this — "RPC unreachable, register it anyway" — is the shape that turns a transient outage into permanent bad data, and it is the more tempting one to write because it keeps the happy path working during an incident.

One correction to my earlier triage of this issue

I first reported that the endpoint had no validation, having grepped for validate|verify|check and found nothing. That was my error: the helpers are named isPrintableName and isTicker, so the grep missed them. Syntactic validation existed; existence validation did not, which is the narrower and correct statement of the bug. Corrected publicly on the issue at the time.

Launch suite: 3111 passed / 16 skipped / 0 failed.