T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:10
- Finding
- API Credential Embedded in the JSON-RPC URL Path## Vulnerability Details **File Location**: `SKILL.md`, line 10; related configurable endpoint documented at lines 32-39 **Vulnerability Type**: API credential exposure through URL construction **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown - **Endpoint**: `POST https://lb.routeme.sh/rpc/{chainId}/{apiKey}` ``` Related argument documentation: ```markdown ### Script arguments - `--chain-id`: EVM chain id (string or int, e.g. `1`, `137`, `42161`) - `--api-key`: optional; falls back to `ROUTEMESH_API_KEY` - `--method`: JSON-RPC method (e.g. `eth_getBlockByNumber`, `eth_call`) - `--params`: JSON string for params (default `[]`) - `--url`: optional base URL (default `https://lb.routeme.sh`) ``` ### Technical Analysis The documented endpoint places the RouteMesh API key directly in the URL path. Although HTTPS protects the URL while it is in transit, URL paths are commonly captured by reverse-proxy access logs, application telemetry, monitoring platforms, debugging output, exception reports, and network infrastructure. Consequently, the credential may be retained or exposed to operators and systems that do not need access to it. The documentation also describes a user-configurable `--url` argument. If the missing helper script implements this option by appending `/rpc/{chainId}/{apiKey}` to an arbitrary base URL without enforcing an origin allowlist, invoking it with an untrusted URL would transmit the API key to that host. The referenced `scripts/routemesh_rpc.py` is not present in the audited artifact, so this particular implementation behavior could not be verified. The confirmed issue is the documented placement of the credential in the URL. ### Attack Path 1. A user exports `ROUTEMESH_API_KEY` and invokes the documented RPC helper. 2. The helper constructs a request URL in the documented form `/rpc/{chainId}/{apiKey}`. 3. The complete path, including the API key, is recorded by RouteMesh infr ...[truncated 1327 chars]
- Remediation
- ## Remediation Suggestions - Replace path-based authentication with an HTTP authorization header, such as `Authorization: Bearer <API_KEY>`, or another header explicitly supported by RouteMesh. - If server compatibility requires path-based credentials, ensure all proxy, CDN, application, telemetry, and error logs redact the credential-bearing path. - Remove arbitrary endpoint overrides unless they are essential. Otherwise, allow only `https://lb.routeme.sh` or a documented set of trusted HTTPS origins. - Disable cross-origin redirects, or verify every redirect target before forwarding credentials. - Never include the final credential-bearing URL in command output, exceptions, debug traces, or HTTP client diagnostics. - Read the key from `ROUTEMESH_API_KEY` or a protected secret store rather than accepting it directly on the command line, because command-line arguments may be exposed through process listings and shell history. - Add automated tests confirming that credentials are redacted and cannot be sent to an unapproved host. - Include the referenced helper script in the audited package so its URL validation, redirect handling, logging, TLS verification, and credential treatment can be independently reviewed. - Rotate any API key suspected of having appeared in logs and restrict each key to the smallest available quota and permission scope.