For years, cryptocurrency security has largely focused on protecting private keys. Hardware wallets, multisignature arrangements and offline storage have become essential defenses against unauthorized access to digital assets.
The vulnerabilities lie in the infrastructure surrounding transactions, including software that validates assets, services that authorize withdrawals and smart contracts that determine which instructions can be executed.
A transaction can carry a legitimate cryptographic signature and still produce an unauthorized outcome if the systems responsible for validating or approving it have been compromised.
This distinction matters for exchanges, blockchain networks and decentralized finance protocols. Protecting cryptographic credentials remains fundamental, but the systems interpreting and executing transactions introduce security risks of their own.
Transaction Validation Is Becoming a Critical Security Boundary
Blockchain networks rely on several layers of verification. Cryptographic signatures establish authorization, while consensus rules and transaction-validation software determine whether proposed changes to the network’s state are permitted.
These mechanisms serve different purposes. A valid signature cannot compensate for defective validation logic, particularly when downstream systems assume that previously accepted transactions have already passed every necessary check.
The September 2026 Liquid Network incident exposed the consequences of that dependency. According to Blockstream’s September 23 technical assessment, an attacker exploited a vulnerability in the rangeproof verification cache of Elements, allowing approximately 4,000 unbacked LBTC to be created.
The affected tokens subsequently passed through Liquid’s standard peg-out infrastructure, resulting in the withdrawal of approximately 4,000 BTC from the network’s reserves.
Blockstream explained that the failure did not depend on stolen private keys or a compromised Peg-out Authorization Key. Instead, affected nodes accepted a transaction whose output value was not backed by its inputs. Once the unbacked LBTC entered the accepted chain state, the withdrawal process treated those assets as legitimate.
The incident illustrates how a validation failure can extend beyond the component where it originates. A withdrawal mechanism may correctly authenticate a request while relying on an earlier consensus decision that was itself incorrect.
The consequences were substantial. Blockstream reported that 3,400 BTC had been returned following negotiations, while approximately 602 BTC remained outstanding at the time of its assessment.
For blockchain operators, the lesson is not simply to strengthen transaction validation. It is also to examine whether critical withdrawal processes have safeguards against accounting inconsistencies or invalid network states that earlier checks have failed to detect.
Independent verification at selected security boundaries and controls around exceptional withdrawals can reduce the consequences of such failures without requiring every component to repeat the entire validation process.
Exchange Wallets Can Be Compromised Without Exposing Their Keys
Centralized exchanges face a related challenge because custody, transaction authorization, risk monitoring and customer-facing services often operate through interconnected systems.
A signing environment may successfully protect private keys while other components remain vulnerable to manipulation. If an attacker can influence the instructions reaching that environment, cryptographic protection alone may not prevent unauthorized transfers.
Bitget’s September 24 security incident provides an example. In its initial security notice, the exchange reported approximately $351.6 million in affected funds after detecting unauthorized transfers involving its hot and warm wallets.
The exchange subsequently raised its estimate to approximately $387.5 million after additional on-chain tracing identified transfers involving other assets. The revised figure reflected a broader accounting of the incident rather than a newly reported breach.
According to Bitget CEO Gracy Chen’s account of the investigation, attackers compromised backend infrastructure connected to the exchange’s wallet operations and manipulated transaction instructions submitted to its authorization systems. Chen stated that private keys had not been compromised.
That distinction is central to understanding the incident. The reported weakness was not the exposure of cryptographic credentials but the ability to influence the instructions processed by systems authorized to use them.
Bitget also stated that its cold wallets remained unaffected and that the financial impact fell within the coverage of its User Protection Fund. The exchange temporarily suspended withdrawals while conducting security checks. These assurances describe the company’s reported response and should not be confused with independent confirmation of the ultimate recovery or reimbursement of every affected asset.
A September crypto security review covering Liquid, Bitget and other incidents also examined how weaknesses in transaction validation and administrative permissions contributed to unauthorized asset movements.
The Bitget case highlights a particular custody risk: even when signing credentials remain protected, compromised backend services may generate instructions that appear acceptable to the signing workflow.
For exchanges, the relevant security boundary therefore extends from transaction creation through authorization, signing and final withdrawal execution. Controls at each stage matter because an attacker may exploit the trust placed in an earlier stage without directly defeating the cryptographic protections at the end.
Smart Contract Permissions Introduce Another Layer of Risk
Decentralized finance adds further complexity because smart contracts frequently delegate authority to other contracts, governance systems, routers and administrative modules.
These relationships enable automated financial operations, but they also expand the number of places where authorization decisions can fail.
A transaction may satisfy the technical conditions required for execution even when the caller should not have been granted the authority to initiate it.
The OWASP Smart Contract Security project identifies improper access control as a major vulnerability category. Its guidance addresses weaknesses involving privileged functions, governance mechanisms, upgrade permissions and interactions between contracts.
The September 15, 2026 incident involving an unidentified Gnosis Safe wallet illustrates how these risks can emerge through connected infrastructure.
According to SlowMist’s incident database, an authorization bypass in a router’s multicall function allowed attacker-controlled instructions to reach a connected Safe module. The resulting execution involved DelegateCall operations and the movement of assets through a malicious Uniswap V4 liquidity pool, with approximately $7.73 million in reported losses.
The distinction between the affected components matters. SlowMist’s description points to an authorization flaw in the connected router and execution path, rather than a general compromise of Gnosis Safe wallets or their underlying cryptographic protections.
This type of failure can be difficult to identify through isolated component reviews. A wallet may operate as designed while a connected contract introduces an authorization path that exposes its assets.
The same challenge applies to DeFi protocols that rely on multiple contracts to manage deposits, withdrawals, governance decisions and privileged operations.
Security assessments must therefore examine not only whether individual contracts enforce their intended rules, but also whether combinations of permitted calls can produce actions that no individual component was intended to authorize.
Security Audits Need to Examine How Systems Interact
Security reviews traditionally examine individual components, including cryptographic implementations, wallet software, smart contracts and exchange infrastructure.
These assessments remain essential. However, the three incidents reveal different weaknesses in the assumptions connecting those components.
In Liquid’s case, the decisive failure occurred during transaction validation. Once unbacked assets entered the accepted network state, downstream withdrawal infrastructure processed them as legitimate.
At Bitget, according to the exchange’s account, the problem arose earlier in the transaction workflow. Compromised backend infrastructure allegedly generated instructions that reached systems responsible for authorizing and signing transfers.
The Gnosis Safe incident exposed a different issue: connected smart contracts could create an unintended execution path through permissions and delegated calls.
These distinctions have practical consequences for security reviews.
A blockchain bridge needs to consider whether accepted network state and reserve accounting can diverge. An exchange must examine whether transaction instructions can be manipulated before reaching its signing systems. A DeFi protocol must assess how permissions behave when multiple contracts interact.
The common requirement is to understand the complete execution path rather than treating the successful operation of individual components as sufficient evidence of security.
That includes identifying which systems can authorize asset movements, where information is trusted without further checks and whether an unexpected input can trigger a transaction with irreversible financial consequences.
Security reviews should also examine how emergency controls respond when these assumptions fail. An effective response may depend on recognizing abnormal asset creation, interrupting unauthorized transfers or isolating a compromised contract before further transactions execute.
The goal is not to duplicate every security check. It is to identify dependencies where one incorrect decision can undermine protections elsewhere.
The Next Security Standard Must Cover the Entire Transaction
The consequences of infrastructure failures extend beyond the immediate value of the assets affected.
When exchanges suspend withdrawals or blockchain networks interrupt operations, users may temporarily lose access to funds that were never directly exposed to the exploited vulnerability.
Liquidity providers, applications and counterparties can also experience disruptions because their operations depend on the availability and reliability of the affected infrastructure.
The September incidents offer three concrete lessons for operators.
Liquid demonstrated that accepted network state cannot always be treated as an unquestionable guarantee of asset validity when the underlying validation software contains a defect.
Bitget’s reported breach showed why exchange security must protect the integrity of transaction instructions before they reach signing infrastructure, not only the keys used to authorize transfers.
The Gnosis Safe incident illustrated how contract permissions can create unintended execution paths even when the wallet itself is not the source of the vulnerability.
These are different technical failures, and none suggests that private-key protection has become less important. Stolen credentials, compromised recovery phrases and unauthorized access to signing material remain serious threats.
What the incidents establish is that security also depends on the decisions surrounding a transaction: whether an asset is valid, whether an instruction is authorized and whether the execution path matches the permissions originally intended.
A valid signature establishes that a cryptographic key was used to authorize a transaction under the applicable signing rules. It does not, by itself, establish that the transaction was economically legitimate, correctly approved by every relevant system or safe to execute.
