Attacker Reused 74 Failed Signatures to Steal $3M From GalaChain
An attacker reused 74 historical signatures from failed transactions over 55 days to withdraw about 2 billion GALA (around $3 million) and dozens of tokens from nine GalaChain wallets on Aug. 18.
On Aug. 18 an attacker used 74 historical signatures from failed on-chain requests to drain roughly 2 billion GALA, about $3 million, and dozens of tokens from nine GalaChain wallets through the network’s bridge, according to Gala’s September postmortem.
The attacker collected signatures from failed transactions stretching back as far as 55 days. Those signatures were paired with mapped account balances and an automated submission engine, enabling rapid repeated withdrawals before operators paused the bridge.
The postmortem identifies two technical weaknesses that the attacker exploited. First, GalaChain’s EIP-712 typed-data verifier accepted type definitions supplied with the request instead of deriving them from the operation being executed. That allowed a cryptographically valid signature intended for one set of fields to be presented while a different method executed with additional parameters the signer had not authorized. The postmortem gives an on-chain example where a TransferToken call moved about 1.64 billion GALA while the supplied EIP-712 structure described an AddLiquidity operation.
Second, replay protection assigned unique transaction keys to prevent reuse, but those keys could roll back when a transaction failed. Failed requests left signed payloads visible on the public ledger while their unique keys remained unused, allowing historical signed payloads to be resubmitted. Investigators found that 57 of the 60 historical source transactions linked to the exploit contained at least one failed inner operation, and none completed fully successfully.
Execution on Aug. 18 included 1,066 submissions with a median interval of 4.5 seconds; 73.9% of those submissions arrived one block apart. The attacker targeted 59 account-token combinations and succeeded on the first attempt for 56 of them. The four largest GALA positions were emptied in descending order within 18 seconds.
The first verified unauthorized transfer occurred at 02:21:54 UTC. The bridge was paused at 05:09:19 UTC, about two hours and 47 minutes later. Roles started being removed from the recipient address at 05:22. Gala has not published when its monitoring first detected the activity.
The postmortem reports no evidence that affected users’ private keys, seed phrases, or passwords were compromised. The company also noted the attacker appeared to use AI-assisted tooling but did not release evidence supporting that assessment.
After pausing the bridge, Gala implemented fixes to the verification and replay systems. The verifier now derives type information from the operation being called rather than trusting caller-supplied definitions. Requests must include identifiers that bind signatures to the channel, contract, and method, and expiration timestamps limit how long signed payloads remain valid. Replay protection now preserves a unique transaction key even if the underlying operation fails.
Gala added per-identity rate limits, behavioral monitoring for high-value accounts, and additional review for bridge withdrawals above set thresholds. The company filed a complaint with the FBI’s Internet Crime Complaint Center, sent preservation and freeze requests to involved platforms, and is tracking proceeds across four chains.
External security reviews had examined elements of the system but did not flag the interaction between signature verification and replay protection. The verification logic was assessed during a CertiK authorization engagement in late 2025 and in an SDK review by Hashlock in January; those reports were not published. The postmortem recommends auditors expand testing to cover interactions among signature verification, replay protection, and transaction execution.








