Skip to main content
• 6 min read

MureDistribution Exploit: QUEST
Drained via User-Supplied Signer Source Bypass

MureDistribution lost about $11.7K after a signature-validation path trusted a user-supplied signer source. The attacker supplied their own contract as the signer, passed SignatureChecker validation, and pulled 4.85M QUEST from addresses that had approved the proxy.

AUTOSEC.DEVAUTOSEC.DEV
MureDistribution Exploit: QUEST Drained via User-Supplied Signer Source Bypass
  • Incident Date: May 23, 2026
  • Target: Mureapp / MureDistribution proxy on Ethereum
  • Target Overview: MureDistribution appears to be a QUEST token distribution or transfer proxy that could move QUEST from addresses that had granted it token allowance. Public reporting tied the incident to signature validation and signer-source handling in the distribution proxy, not to a compromise of the QUEST token contract or Uniswap.
  • Victim Contract: 0x365083717eFB17F3895290BA38f20F568C7A4D8a
  • Total Loss: Approximately 4.85M QUEST, swapped for about 5.45 ETH, with public estimates around $11.7K
  • Recovery Status: No public recovery, reimbursement, or final post-mortem had been identified in the reviewed sources.
  • Attack Vector: Access Control / Unvalidated Signer Source / Contract-Signature Trust Bypass / Approval-Based transferFrom Drain

Incident Review & Technical Details​

1. Attack Path​

  1. Signer Source Was Caller-Influenced: Public reporting described a MureDistribution validation path that accepted a user-supplied input as the source of the authorized signer.
  2. Attacker Supplied Their Own Contract: Instead of being forced to prove authorization from a trusted Mure signer, the attacker passed an attacker-controlled contract as the signer source.
  3. SignatureChecker Accepted the Malicious Source: The validation flow used SignatureChecker behavior that can verify signatures for contract accounts by calling the contract. Because the attacker controlled the supplied contract, that contract could return a successful signature-validation result.
  4. Authorization Collapsed Into Self-Attestation: Once the malicious contract was accepted as the signer, the attacker effectively made themselves the authority for the transfer path. The system checked whether the supplied signer approved the action, but the supplied signer was not bound to a trusted registry or expected role.
  5. Existing Token Allowances Became the Drain Surface: The attacker then targeted addresses that had already approved the MureDistribution proxy to move QUEST.
  6. QUEST Was Pulled via transferFrom: In one Ethereum transaction, the attacker pulled approximately 4.85M QUEST from approved addresses through the vulnerable proxy path.
  7. Funds Were Swapped on Uniswap: The drained QUEST was sold into roughly 5.45 ETH, with public reporting estimating the loss at about $11.7K.

2. Impact Scope​

  • Direct Loss: Approximately 4.85M QUEST, converted to about 5.45 ETH.
  • Affected Component: The reported vulnerable surface was the MureDistribution proxy's signature-validation and signer-source handling.
  • Affected Users: The practical exposure was concentrated in addresses that had active QUEST approvals to the MureDistribution proxy.
  • Unaffected Components: The reviewed public sources did not identify a QUEST token contract compromise, Uniswap vulnerability, private-key theft, or validator-level issue.
  • Transaction Shape: Public alerts described the exploit as a single Ethereum transaction, which suggests the failure was directly reachable once the attacker found the signer-source bypass.
  • Residual Risk: Any remaining allowance to the vulnerable proxy would remain risky unless the proxy was paused, fixed, or made unreachable and users revoked approvals.

3. Root Cause Assessment​

The incident is a compact example of a dangerous authorization pattern: the contract performed signature verification, but it trusted the caller to choose the entity whose signature mattered.

Key risk patterns to examine:

  • Identity Source Was Not Trusted: A signature check only protects the system if the signer being checked is itself trusted. If the caller can choose the signer, the check can become self-approval.
  • Contract Signatures Need Stronger Binding: ERC-1271-style contract signature validation is useful for smart wallets and contract accounts, but the verifying contract must know which contract account is allowed to sign. Arbitrary contract callbacks are not an authority boundary.
  • Allowance-Based Designs Amplify Mistakes: A vulnerable distribution proxy does not need to custody funds directly. If enough users or internal wallets pre-approved it, transferFrom can become a broad drain primitive.
  • Validation Inputs Were Mixed With Validation Policy: User input may describe the requested transfer, but it should not define the trust root that decides whether the transfer is authorized.
  • Small Dollar Losses Still Reveal Severe Logic Risk: The reported loss was modest by DeFi standards, but the bug class is high severity because it can fully bypass intended signer authorization.

The core invariant should have been strict: every transfer authorized by MureDistribution must be signed by a signer that the protocol independently recognizes as authorized, and no user-controlled field may replace or redefine that trusted signer set.

4. Mitigation and Response​

Recommended actions for Mureapp, token distribution systems, and approval-based transfer proxies:

  • Disable or pause the vulnerable transfer path until signer-source validation is fixed.
  • Remove user-controlled signer-source selection from authorization logic.
  • Bind each signed authorization to the expected signer, token, source address, destination address, amount, nonce, deadline, chain ID, and verifying contract address.
  • If contract signatures are supported, verify the contract signer against a trusted registry or expected account, not against arbitrary calldata.
  • Add nonce and replay controls for every signed transfer authorization.
  • Inventory all addresses with QUEST allowance to the affected proxy and guide users to revoke stale approvals.
  • Add negative tests where the supplied signer is an attacker contract that always returns signature success.
  • Add fork tests for malicious ERC-1271 signers, arbitrary source fields, stale signatures, wrong chain IDs, wrong verifying contracts, and approvals that should not be spendable.
  • Publish a final post-mortem with the vulnerable function, calldata, patched diff, affected allowance scope, recovery status, and regression tests.

AUTOSEC.DEV Solution: Building a 360-Degree Defense​

The MureDistribution incident shows why signature verification must be reviewed as an end-to-end authorization system, not as a standalone library call. SignatureChecker can behave correctly while the surrounding contract still trusts the wrong signer.

  1. Signature Authorization Review: AUTOSEC.DEV reviews EIP-712 payloads, ERC-1271 contract-signer paths, signer registries, nonce handling, replay controls, and role-binding logic.
  2. Token Allowance Risk Assessment: We identify where approved-spender patterns can turn a logic bug into a direct transferFrom drain, then recommend allowance limits, revocation workflows, and safer proxy architecture.
  3. Fork-Based Exploit Reproduction: We reproduce malicious signer contracts, arbitrary source fields, stale signatures, and approval-drain paths against forked environments before production exposure.
  4. Incident Response (IR): We support transaction reconstruction, affected-wallet scoping, approval inventory, recovery coordination, and user-facing technical disclosure after active token-drain events.

Service Content​

Reference​