other
Warning
- Location
- SKILL.md:29
- Finding
- Persistent User Fingerprint and Transaction Metadata Disclosed to a Third-Party Service<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md:29`, `SKILL.md:39-40`, and `SKILL.md:168-186` **Vulnerability Type**: Privacy tracking and transaction metadata disclosure **Risk Level**: Medium ### Vulnerable Code The Skill instructs agents to assign and transmit a stable agent or user identifier: ```text 1. Set `X-Client-Fingerprint: <stable_agent_or_user_id>` for predictable free-tier accounting. ``` It also states that the service uses other identifying request signals if this value is omitted: ```text - Free tier is best-effort abuse-limited, not a security mechanism. Rotating fingerprints can bypass free-tier buckets. - If `X-Client-Fingerprint` is omitted, the service falls back to other request signals (IP/User-Agent) for accounting. ``` Transaction simulation sends wallet addresses, amounts, chain information, and potentially sensitive raw calldata to the remote service: ```markdown Request body fields: - `from` (required): sender address - `to` (required): recipient or contract - `value` (required): amount in wei (string) - `data` (optional): calldata hex (`0x...`) - `chain_id` (optional): chain being simulated (default: Base 8453 is a common choice for payments, but simulation chain is up to you) ```bash curl -X POST "https://aegis402.xyz/v1/simulate-tx" \ -H "Content-Type: application/json" \ -d '{ "from": "0xYourWallet...", "to": "0xContract...", "value": "0", "data": "0x", "chain_id": 8453 }' ``` ``` ### Technical Analysis Sending transaction parameters to a remote simulation service is related to the declared blockchain security functionality. However, requiring a stable agent- or user-level fingerprint exceeds the minimum data needed to analyze a transaction. A persistent identifier enables the API operator to correlate requests over time. When combined with `from`, `to`, `value`, `chain_id`, and raw calldata, the fingerprint can create a detailed profile of a user's wallet relationships, inten ...[truncated 2548 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Do not use a stable user-level identifier by default. Use an ephemeral, randomly generated identifier scoped to a single session or request. 2. If free-tier accounting requires persistence, scope the identifier to the installation rather than the person and rotate it regularly. 3. Ensure the fingerprint contains no email address, account name, wallet address, device identifier, or other directly identifying information. 4. Obtain explicit informed consent before transmitting transaction details to the third-party API. The confirmation should identify the destination and enumerate the data being sent. 5. Add a privacy notice describing data collection, purpose, retention period, log handling, deletion procedures, and whether information is shared with subprocessors. 6. Minimize submitted data. Do not transmit raw calldata when a less detailed local decode or risk check is sufficient. 7. Provide a preview of the outbound payload and allow users to redact optional fields before submission. 8. Avoid silently falling back to IP address and user-agent tracking. Clearly disclose such fallback behavior and provide an opt-out mechanism. 9. Separate rate-limit accounting identifiers from transaction-analysis records so they cannot be routinely joined. 10. Apply short retention periods, encryption at rest, strict access controls, audit logging, and automatic deletion to stored request data. 11. Preserve the existing prohibitions against collecting private keys, seed phrases, mnemonics, signatures, and other signing secrets. ]]>