Hardcoded RPC Gateway Key in Public JavaScript Bundle Exposes Debug Traces and Pending Transactions

Reported Feb 21, 2026

Severity High

Platform Web

Vulnerability Class Hardcoded Secrets (CWE-798)

Target Type DeFi Trading Platform

Impact Privileged blockchain RPC access and pending order visibility

The Risk

A trading platform's website was shipping a paid backend access key inside the public JavaScript that every visitor downloads. Anyone could pull the key out of the page source and use it to read deep technical details about the platform's blockchain activity, including transactions that had not yet been confirmed. That exposure both ran up the company's bill on a metered service and gave outsiders an early window into trades the platform's users were about to make.

The Vulnerability

The web application embedded a production RPC gateway credential directly in the JavaScript bundle served from the main app origin. The credential lived in the URL path of two RPC endpoints, behaving like an API key: a valid token returned HTTP 200 with normal RPC responses, while a randomized token was rejected with HTTP 404 or HTTP 401.

The exposed key gave access to a privileged RPC method set that should never have been reachable from a browser context, including debug_traceBlockByNumber, debug_traceCall, debug_traceTransaction, eth_getBlockByNumber("pending", true), and eth_sendRawTransaction as a relay method.

The Attack

Extraction was a single curl request against the public bundle:

curl -s https://app.example.com/assets/index-XXXX.js \
  | grep -o 'mainnet-rpc.example.com[^"]*' | head

From there, the key was used directly against the gateway with standard JSON-RPC payloads. No authentication beyond the leaked path token was required.

Privileged Trace Access

Calling debug_traceBlockByNumber with a callTracer returned full execution traces, including internal calls, sender and recipient, calldata, return data, and gas usage. This is data normally restricted to operators and infrastructure providers.

Pending Transaction Visibility

Querying eth_getBlockByNumber("pending", true) returned an array of full transaction objects that had not yet been mined, complete with hashes, addresses, values, and calldata. For a trading platform, this is a direct mempool view into orders about to settle.

Relay Method Exposure

Submitting an empty payload to eth_sendRawTransaction returned a "transaction decoding error" rather than "method not found", proving the relay was enabled and would accept a properly signed transaction through the leaked key.

The Impact

A production RPC gateway credential was publicly accessible to any visitor of the platform.
Privileged debug methods exposed internal execution traces and detailed pending transaction payloads.
Unauthorized parties could consume the platform's metered RPC capacity, increasing operational cost.
Heavy debug calls also risked degrading RPC performance for legitimate users.
A second RPC credential on a different host was leaked in the same bundle, confirming a pattern rather than an isolated mistake.

Remediation

Immediately rotate and revoke both exposed RPC credentials.
Remove all secrets from client code. Proxy RPC calls through a backend service, or issue short-lived, origin-bound tokens server-side.
Restrict the RPC method set exposed to client flows. Block debug_trace* entirely and limit or disable pending-block retrieval where it is not strictly required.
Add per-key quotas, rate limits, and anomaly detection at the RPC gateway.
Run secret scanning against built JavaScript bundles in CI to catch keys before they reach production.