GalaChain’s August exploit turned failed transactions into reusable authorization, exposing a security flaw that had survived multiple audits.
The blockchain developed by Gala Games said the attacker used historical signatures from unsuccessful transactions to drain about 2 billion GALA (about $3 million) and dozens of other tokens from nine wallets on Aug. 18.
Its Sept. 14 postmortem depicts an operation prepared before the first unauthorized transfer, with mapped balances, automated submissions, and a weakness spanning both signature verification and replay protection.
Gala patched the flaws after pausing its bridge during the attack. The incident now raises a broader question for blockchain operators: whether systems built around valid signatures and human-triggered emergency controls can respond quickly enough once exploitation has been automated.
Failed transactions became an attack inventory
The attacker arrived with 74 replayable signatures gathered from failed transactions stretching back as far as 55 days, Gala said.
Those signatures were paired with what appears to have been detailed knowledge of the affected accounts. Of 59 account-token combinations targeted during the incident, 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 suggests reconnaissance occurred before exploitation began rather than account balances being discovered transaction by transaction during the attack.
Execution then moved rapidly. Gala recorded 1,066 submissions at a median interval of 4.5 seconds, with 73.9% arriving exactly one block apart.
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. That 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. The system could not guarantee that the account holder had authorized the economic effects execution ultimately produced.
Gala said investigators found no evidence that the affected users’ private keys, seed phrases, or passwords were compromised. That conclusion relies partly on internal evidence that the company has not published.
A separate replay weakness expanded the pool of signatures the attacker could use.
GalaChain assigned unique transaction keys intended to stop the same signed payload from being submitted more than once. But 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.
Gala said 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 the private keys behind every targeted wallet because authentic signatures had already been published on-chain.
GALA audits missed the interaction between safeguards
Meanwhile, the vulnerability had 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 Aug. 18 attacker found the boundary where the safeguard stopped applying: failed transactions whose signed payloads had become public while their unique keys remained unused.
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.
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.
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.
The post Hacker turned 55 days of failed transactions into a $3 million master key that drained GalaChain wallets appeared first on CryptoSlate.
