Borrow the page's own client and signer

Code Security Artifact Security

A script injected into an application's own page can act with the
application's own authority without stealing anything. The browser has
already loaded the app's client code, the app has already built its
API clients, and a signed-in user's signer is already reachable from the
page's own component tree. Code in that origin can read the app's
client-side session state, find the framework's internal component
objects, take the client object the app built and call it.

Polymarket's drainer on 29 October 2026 is the reference case. It read
three localStorage entries, walked React fiber objects attached to DOM
elements to find the order client with its signer attached, then built
the same EIP-712 batches the app builds, signed them with the user's
signer and submitted them through the app's own relayer. It carried no
key, no password and no seed phrase.

Distinct from T0188 (CSRF), where a request rides an ambient cookie the
attacker cannot read: here the request is signed by the victim's own key
because the victim's own code path is doing the signing. Distinct from
T0205, which is how such a script gets delivered. The user may still be
asked to approve a signature; whether they are depends on the wallet and
the session, and the technique does not require that they are not.

Where this idea came from

Public incident / advisory

This catalogue, from Ohey's and Hudson Rock's analysis of the drainer served at Polymarket's DebugBear script URL on 29 October 2026. The script carried no key - it read the app's localStorage auth entries, found the order client in React fiber objects with its signer attached, and had the user's own signer approve EIP-712 batches submitted through the app's relayer. Distinct from CSRF, where no signature is available.

Mitigations

None linked yet.

Detections