[SECURITY][MEDIUM] In-memory rate limit bypass across Vercel instances

[axeleagle1]

Summary

When Upstash Redis is unconfigured (or falls back to in-memory), the rate limiter becomes per-Vercel-instance. On Vercel's Edge Network, each request may hit a different serverless instance, resetting the counter. An attacker distributing requests across cold starts can bypass rate limits entirely.

Affected Component

middleware.ts - Rate limiting logic

Vulnerability Details

The code has two rate limiting paths:

1. Upstash Redis (distributed) - Globally consistent across instances
2. In-memory fallback (per-instance) - Only tracks requests within a single isolate

When Redis is unavailable, the middleware falls back to an in-memory Map. On Vercel:

• Each cold start creates a fresh Map
• An attacker can send 120 requests to instance A (hits limit), then send 120 to instance B (fresh Map, no limit), etc.
• The console.warn in the code acknowledges this: "NOTE: This is per-isolate only"

// NOTE: This is per-isolate only — it does NOT share state across Vercel Edge
// instances.  For reliable distributed enforcement, configure Upstash Redis

Impact

Medium - An attacker can bypass rate limits on any API endpoint, enabling:

• DoS via resource exhaustion
• Brute-force attacks on protected endpoints
• Abuse of the RPC proxy to drain paid Helius quota

Proof of Concept

# Send 120 requests (hits limit on single instance)
for i in $(seq 1 120); do curl -s https://percolatorlaunch.com/api/rpc; done

# Wait for cold start, repeat - counter resets
sleep 30
for i in $(seq 1 120); do curl -s https://percolatorlaunch.com/api/rpc; done

Recommended Fix

1. Primary: Ensure Upstash Redis is configured in production (check deployment docs)
2. Defense-in-depth: Add a fallback rate limiter using Supabase (already available)
3. Monitoring: Alert when in-memory fallback is active in production

Environment

• Production: percolatorlaunch.com
• Affected when UPSTASH_REDIS_REST_URL and UPSTASH_REDIS_REST_TOKEN are not set

[axeleagle1]

PoC Script

\\javascript
const DEFAULT_BATCH_SIZE = 50;

async function makeRequest(url, id) {
const response = await fetch(url, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ jsonrpc: '2.0', id, method: 'getHealth', params: [] })
});
return { status: response.status, remaining: response.headers.get('x-ratelimit-remaining'), blocked: response.status === 429 };
}

async function testBypass() {
const url = 'https://percolatorlaunch.com/api/rpc';
let totalAllowed = 0;

for (let batch = 1; batch <= 5; batch++) {
console.log(\Batch : sending \ requests...);
const results = await Promise.all(Array.from({length: DEFAULT_BATCH_SIZE}, (_, i) => makeRequest(url, i)));
const allowed = results.filter(r => !r.blocked).length;
totalAllowed += allowed;
console.log(\ Allowed: , Blocked: \);
if (batch < 5) await new Promise(r => setTimeout(r, 5000));
}

console.log(\Total allowed: \ (expected max 120 if distributed));
}

testBypass();
\\

Demonstrates: If Upstash Redis is unconfigured, each batch hits a fresh Vercel instance, bypassing the 120 req/min limit.

[dcccrypto]

CONFIRMED. Partially fixed in PR #2526 — the silent-degradation half. The configuration half is ops and stays open.

Verified app/middleware.ts. Your two-path description is accurate, and the architecture already prefers the right one: Upstash Redis is primary (GH#1213), in-memory is a documented per-isolate fallback. The file even states your finding in its own comment:

The previous pure in-memory Map approach was per-instance: on Vercel each cold start resets counters independently, so an attacker distributing requests across instances could bypass the limit entirely.

What I found while checking, and fixed

The two ways to land on the fallback were not treated alike:

• Redis init failure → logged an error in production.
• Missing env vars → if (!url || !token) return { general: null, rpc: null }; — returned silently.

That is backwards. A Redis client throwing on construction is rare; a deployment that simply never had UPSTASH_REDIS_REST_URL / UPSTASH_REDIS_REST_TOKEN set is the ordinary route — a fresh environment, or a preview promoted to production without the vars. The likely case was the silent one, so the exact situation your issue describes could be true in production with nothing anywhere saying so.

Both paths now log in production.

I kept it a log rather than a throw on purpose: middleware runs on every request, so failing closed would take the whole site down over a rate limiter. That trade is defensible, and it is precisely why the degradation must be visible — the operator has to be able to discover it.

What stays open

This does not make the fallback distributed. Whether production actually has Upstash configured is an ops fact I cannot establish from the repo, and configuring it is an operator action. Open on that basis.

Related: #2210 was closed on the strength of a per-IP limit that depends on this same limiter, so these two are coupled — the RPC quota bound is only as distributed as this configuration is.

Launch suite: 3094 / 0.