An agent approaching a service should not treat a login challenge as belonging to a different service. V12 showed a server could present an SIWE extension whose domain and URI referred to an unrelated site, then receive a wallet signature that passed the normal signature validation for that site. An attacker could obtain a challenge from a target service…
Inspect the ClaimsCase · DiggingBeagle record
x402 sign-in extension could relay a cross-origin wallet login signature
V12 demonstrated that an API server could request a valid Sign-In with Ethereum message naming a different website, allowing possible session takeover where the target accepted the challenge.
Scope
x402 SIWE client extension before August 2026 remediation; Ethereum-style wallet authentication.
Assessment profile
Assessment method- Setting
- research demonstration
- Exploitation
- demonstrated
- Evidence
- Grade B
- Remediation
- fixed reported
- AI role
- AGAINST AI
Basis and provenance
CASE-2026-X402-SIWE-ORIGIN: The SIWE client signed a formatted login challenge for an origin other than the service contacted, without checking the domain and URI against that server. Evidence comes from SRC-2026-V12-X402-25-FINDINGS. Published technical statements or controlled results are not verified production-loss counts. No impact band is assigned because the observed outcome and its denominator do not establish a comparable severity measure.
Assessed Oct 24, 2026 using diggingbeagle.assessment/1.
Evidence basis: CLM-X402-SIWE-01 · V12: 25 x402 vulnerabilities and three critical mechanisms
At a glance
The unit of harm is authentication authority, not an on-chain token transfer. A syntactically valid SIWE signature proves control over a wallet but not that the owner intended to log into the target service during this particular request.
Read the implicationsTarget-site account capabilities and live takeover incidence are not established.
Limits and uncertaintyFull account
An agent approaching a service should not treat a login challenge as belonging to a different service. V12 showed a server could present an SIWE extension whose domain and URI referred to an unrelated site, then receive a wallet signature that passed the normal signature validation for that site. An attacker could obtain a challenge from a target service and relay it through the malicious data server, making the client sign the target's challenge. The demonstrated failure occurs before the signature is made: the client failed to bind the prompt to the origin it actually contacted. Session takeover depends on what the target service permits after authentication, and V12 did not demonstrate a production takeover. The x402 fix added origin checks. This differs from unauthorized token spending because no payment amount need be stolen to compromise a wallet-authenticated session.
The attacker does not need to forge a cryptographic signature. It can present a legitimate sign-in challenge for a different website through its own API, relying on the automatic signing client to ignore the mismatch between the contacted service and the requested authentication audience. The signature can be genuine while its meaning for user consent is false. This differs from the wallet-spending issue, where the merchant controls the consideration and recipient. Researcher disclosure preceded publication: V12 dates the report to August 12, fixes to August 20 and public explanation to October 22. V12's chronology.
Mechanism and trust boundary
- 01
Obtain a valid login challenge from another website
An attacker-controlled API server can fetch a SIWE-style challenge from a target that uses wallet authentication.
Boundary: Target site nonce / attacker-controlled server
- 02
Relay the challenge through an unrelated request
The malicious API provides an extension whose domain and URI identify the target rather than the service the agent contacted.
Boundary: Merchant response / target-site authentication message
- 03
Get a signature for the wrong origin
Without comparing contacted origin to signed origin, the agent wallet may sign a message that could authenticate a session at the target, depending on target controls.
Boundary: Local origin verification / wallet signing authority
Timeline
- Aug 12, 2026Event type unspecified
Researchers privately report the critical x402 issue
V12 says this vulnerability was reported to maintainers with two other critical findings.
- Aug 20, 2026Event type unspecified
Critical-finding fixes completed
V12 dates completion of fixes for the three critical findings by August 20, ahead of their public report.
- Oct 22, 2026Event type unspecified
Cross-origin wallet-login issue publicly described
V12 disclosed the test and explained that actual account privileges depend on the accepting target service.
- Oct 22, 2026disclosure
Public disclosure
Claims & evidence
CLM-X402-SIWE-01The SIWE client signed a formatted login challenge for an origin other than the service contacted, without checking the domain and URI against that server.supported
Basis: reported finding
- supportsV12: 25 x402 vulnerabilities and three critical mechanismsprimary disclosure
A server could request a login signature for another website
CLM-X402-SIWE-ENRICH-DOMAINV12 demonstrated a correctly formatted SIWE signature whose domain was unrelated to the contacted host and identified origin binding as the missing client-side check.supported
Basis: reported finding
- supportsV12: 25 x402 vulnerabilities and three critical mechanismsprimary disclosure
A server could request a login signature for another website
Implications
The unit of harm is authentication authority, not an on-chain token transfer. A syntactically valid SIWE signature proves control over a wallet but not that the owner intended to log into the target service during this particular request.
Controls and mitigations
- Upgrade to the patched x402 SIWE client and enforce explicit origin and URI binding before signing. Require nonce, domain, chain and expiry verification at the target service as independent session controls.
Unknowns and contradictions
- Target-site account capabilities and live takeover incidence are not established.
Sources and citation
Material revision history
- Oct 24, 2026 · Canonical change recorded · new in release · revision 188