GalaChain August Exploit Reveals Signature Verification Flaw That Survived Multiple Audits

A security breach on GalaChain in August exploited a novel vulnerability: failed transactions were converted into reusable authorization credentials, allowing an attacker to drain approximately 2 billion $GALA tokens—worth roughly $3 million at the time—along with dozens of other assets from nine wallets. The incident, detailed in a September 14 postmortem from Gala Games, exposes a critical gap in how blockchain systems validate signatures and protect against replay attacks, raising urgent questions about defense speed when exploitation becomes automated.

Failed Transactions Became an Attack Inventory

The attacker arrived prepared with 74 replayable signatures harvested from failed transactions dating back as far as 55 days, according to Gala. Those signatures were paired with what appears to be detailed knowledge of the targeted accounts. Of 59 account-token combinations attacked, 56 were drained for their exact balance on the first attempt. The four largest $GALA positions were taken in descending order within 18 seconds.

That pattern strongly suggests reconnaissance occurred before exploitation began, rather than balances being discovered transaction-by-transaction during the attack. Execution then moved at machine speed: Gala recorded 1,066 submissions at a median interval of 4.5 seconds, with 73.9% arriving exactly one block apart.

EIP-712 Verification Flaw Allowed Signature Scope Mismatch

The historical signatures were valuable because of how GalaChain handled EIP-712 typed-data verification. Before the patch, the verifier accepted type definitions supplied with the request rather than deriving them from the invoked operation. This allowed a signature covering one set of fields to be presented while another method executed using additional information the signer had never committed to.

One on-chain example shows a TransferToken call processing about 1.64 billion $GALA even though the EIP-712 structure supplied for verification described an AddLiquidity operation. The destination, quantity, and token instance used by the transfer were outside the signed structure. The signature itself was cryptographically valid, yet the system could not guarantee that the account holder had authorized the economic effects execution ultimately produced.

Gala stated investigators found no evidence that affected users’ private keys, seed phrases, or passwords were compromised—a conclusion that relies partly on internal evidence the company has not published.

Separate Replay Weakness Expanded the Attack Surface

A second flaw in replay protection compounded the problem. GalaChain assigned unique transaction keys intended to stop the same signed payload from being submitted more than once. However, when a transaction failed, the key could roll back alongside the unsuccessful state changes. The signature remained visible on the public ledger while the replay key remained available for reuse.

Gala reported that 57 of the 60 historical source transactions linked to the exploit contained at least one failed inner operation, while none completed entirely successfully. The combination effectively turned unsuccessful historical requests into reusable permissions. An attacker did not need to forge signatures or steal private keys behind every targeted wallet because authentic signatures had already been published on-chain.

Audits Missed the Interaction Between Safeguards

The vulnerability survived external security reviews before the attack. Gala said the relevant verification logic was examined during an authorization-focused CertiK engagement in late 2025 and an SDK review by Hashlock in January. Neither identified the signature-scope issue. The company has not published those reports, making it difficult to determine what each review tested or how extensively it examined the interaction between signature verification and replay protection.

Notably, the replay mechanism itself was introduced after an earlier CertiK finding. That protection could prevent reuse after a transaction key had been consumed. The August 18 attacker found the boundary where the safeguard stopped applying: failed transactions whose signed payloads had become public while their unique keys remained unused.

Patches Close the Technical Gaps, Not the Response-Time Problem

Gala subsequently changed both systems. Signature verification now derives its type information from the operation being called rather than trusting a caller-supplied definition. Requests also include identifiers that bind signatures more closely to the channel, contract, and method being authorized, while expiration timestamps limit how long signed payloads remain valid. The replay fix persists a unique transaction key even if the underlying business operation fails, preventing the same historical request from remaining available for another attempt.

Those patches close the two weaknesses described in the postmortem. They do not resolve the response-time problem that emerges once a valid-looking attack is already underway. The first verified unauthorized transfer occurred at 02:21:54 UTC. Gala paused the bridge at 05:09:19 UTC—about two hours and 47 minutes later—and began removing roles from the recipient address at 05:22 UTC. The company has not disclosed when its monitoring first detected the activity, so that interval cannot be treated as its reaction time. Gala said attempts to move assets out through the bridge were rejected after the pause.

The chronology nevertheless shows the disparity facing operators once exploitation reaches machine speed: submissions can arrive every few seconds while detection, investigation, and emergency intervention may still require human decisions.

Bridge Operators Face a Machine-Speed Defense Problem

Gala said it has since added per-identity rate limits, behavioral monitoring for high-value accounts, and additional review for bridge withdrawals above certain thresholds. Those measures move security controls earlier in the settlement process, where unusual activity can be slowed before assets leave the system.

They also introduce trade-offs. Operation-bound signatures, expirations, and replay keys largely enforce the instructions a user actually signed. Rate limits and behavioral triggers require operators to decide what constitutes abnormal activity, while withdrawal holds can delay legitimate users as well as malicious ones.

Gala has described the attacker as using AI-assisted tooling, but that assessment relies on internal evidence the company has not released. That distinction matters as crypto firms increasingly frame security threats around artificial intelligence. For bridge operators, the more immediate issue is whether automated attackers can exploit valid-looking authorization paths faster than monitoring systems can identify and contain them.

Investigation and Longer-Term Audit Implications

Gala said it has filed a complaint with the FBI’s Internet Crime Complaint Center and sent preservation and freeze requests to platforms involved as it tracks proceeds across four chains. The longer-term challenge is now likely to shift toward audit scope. Reviews that test signature verification, replay protection, and transaction execution separately may miss vulnerabilities that appear only when those systems interact.

For GalaChain, future audits will have to establish whether similar authorization gaps remain elsewhere in its SDK. For bridge operators more broadly, the commercial cost of relying on a human-triggered pause rises with every block once an attacker arrives with harvested signatures, mapped balances, and an automated submission engine.