bug: Unbounded getProgramAccounts RPC proxy queries allow server memory exhaustion

[v1ktorrr0x]

Public RPC Proxy: Unbounded getProgramAccounts Allowances Cause DoS & Billing Exhaustion

Affected Component

• File: app/app/api/rpc/route.ts
• Method: Custom RPC Proxy Handler

Summary

The Next.js API route serving as the custom RPC proxy (/api/rpc) whitelists the standard Solana JSON-RPC method getProgramAccounts to support frontend workspace queries. However, the handler forwards incoming payloads directly to the upstream RPC node (Helius) without validating the target programId in the parameters or enforcing minimal query filters.
Because of this lack of sanitation, any client can route heavy queries—such as full account state dumps of the SPL Token Program—through the server's endpoint. This results in serverless function Out-of-Memory (OOM) crashes and rapid credit exhaustion on the paid RPC billing tier.

Vulnerability Mechanism

In the API route, incoming requests undergo a basic method check. While there is a whitelist (allowedMethods) containing getProgramAccounts, the endpoint does not intercept or inspect the method's payload parameters:

// Located in app/app/api/rpc/route.ts
if (!allowedMethods.includes(payload.method)) {
  return NextResponse.json({ error: "Method not allowed" }, { status: 405 });
}

The payload is passed directly to the upstream provider via a fetch call.

Proof of Concept (PoC)

An attacker can execute the following request targeting the public token program. The query forces the node to compile and serialize the state of all token accounts on the network (hundreds of megabytes of raw JSON):

curl -X POST https://[LAUNCH_DOMAN]/api/rpc \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "id": 1,
    "method": "getProgramAccounts",
    "params": [
      "TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA"
    ]
  }'

Expected Server Behavior:

1. The proxy forwards the request to Helius, draining thousands of credits in a single query.
2. Helius responds with a payload size exceeding serverless runtime boundaries (typically capped at 4.5MB response size limit / 128-512MB RAM for basic serverless functions).
3. The Node.js parser triggers an Out-of-Memory (OOM) heap limit crash or hits the hosting environment's maximum execution limit, causing a 502 Bad Gateway error for all concurrent users routing legitimate transactions.

---

Impact

• Denial of Service (DoS): High-frequency requests targeting heavy programs will lock the proxy gateway, preventing clients from querying transaction history, oracles, or orderbooks.
• Financial Drain: Unbounded getProgramAccounts calls rapidly consume RPC node service credits, exhausting the project's paid billing tier limits within minutes.

---

Remediation

Enforce a strict whitelist check on the parameters of getProgramAccounts to verify that the query targeting program IDs is constrained only to the project's deployed program(s) (e.g. Percolator Launch program). Reject any other targets immediately:

// Suggested mitigation patch for app/app/api/rpc/route.ts
if (payload.method === "getProgramAccounts") {
  const targetProgram = payload.params?.[0];
  const ALLOWED_PROGRAMS = [
    process.env.NEXT_PUBLIC_PROGRAM_ID, // Deployed Percolator program
    // Add other authorized project program IDs here
  ];
  if (!targetProgram || !ALLOWED_PROGRAMS.includes(targetProgram)) {
    return NextResponse.json(
      { jsonrpc: "2.0", id: payload.id, error: { code: -32602, message: "Invalid program target for getProgramAccounts" } },
      { status: 400 }
    );
  }
  
  // Optionally: Enforce that filters must be present to prevent full database sweeps
  const filters = payload.params?.[1]?.filters;
  if (!filters || filters.length === 0) {
     return NextResponse.json(
      { jsonrpc: "2.0", id: payload.id, error: { code: -32602, message: "Filters are required for getProgramAccounts queries" } },
      { status: 400 }
    );
  }
}

[dcccrypto]

Verified real (workflow + refute): the rate limit alone doesn't cover this — one unfiltered getProgramAccounts can OOM the proxy. Fix added to PR #2211 (validateRequest now requires a dataSize/memcmp filter for getProgramAccounts). Awaiting merge (prod deploy).

[dcccrypto]

FIXED and merged in PR #2530. Closing — both halves of your report were real, and only one had been closed.

The half that was already done

/api/rpc had gained a filter requirement: getProgramAccounts must carry a dataSize or memcmp, else it is refused with -32602.

The half that had not been, and your example is the proof

full account state dumps of the SPL Token Program

That query supplies dataSize: 165 — the SPL token-account size. The filter check passes, and the upstream node still returns every token account on the cluster.

A filter bounds the result shape. It does not bound the program. On a program with millions of matching accounts, that is no bound at all — so the exact attack you named was still open after the first fix.

Your report asked for both, and it was right to:

the handler forwards incoming payloads directly to the upstream RPC node without validating the target programId in the parameters or enforcing minimal query filters

Now pinned to the programs this app actually queries

target	source	used by
wrapper + every slab tier	getAllProgramIds()	userAccountScan
matcher	matcherProgramId	matcherCaps
NFT program	nftProgramId	userAccountScan
stake / vault	vaultProgramId	stake reads

Built from config rather than a hardcoded list, so adding a slab tier extends the allowlist with no change at this site — the same property getAllProgramIds() already provides to assertKnownProgram. A non-string params[0] is rejected rather than coerced.

One test pins that the allowlist is non-empty: an allowlist that degrades to empty still "works" (it rejects everything), but the inverse shape — empty treated as permissive — is the dangerous one, and this makes a config regression visible either way.

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

Related and separately fixed today: #2522 bounded the upstream call with a timeout, and #2210 closed the spoofable-Origin bypass. This endpoint has needed all three — a gate, a bound on what is asked for, and a bound on how long it may take.