The person requesting a payment has passed identity verification. The payment has been approved, and the transaction signature is valid. Does that mean the funds are safe?
Not necessarily.
In 2025, BigONE lost roughly $27 million, while Bybit suffered a $1.5 billion attack. In October 2026, Binance reported a security incident affecting approximately $6.34 billion in digital assets. These incidents show why secure private-key storage alone cannot guarantee fund security.
Institutions therefore need to look beyond the secure storage of private keys. What justifies the payment? What exactly is being signed? Who determines whether a transaction can be signed? And after execution, how does the system determine whether the payment is complete?
In this article, BlockSec uses publicly reported incidents to examine overlooked authorization risks across the payment lifecycle, from initiation to settlement.
Our forthcoming technical series, Beyond Secure Storage, will explore two attack paths in detail:
-
Abusing a system’s signing capabilities without obtaining its private keys.
-
Exploiting flaws in cryptographic implementations to recover those keys.
Where Can a Crypto Payment Be Hijacked?
A payment executed through a wallet typically involves four stages:
-
Payment basis and authorization.
-
Transaction construction and verification.
-
Signing authorization and key use.
-
Execution and settlement.
1. Payment Basis and Authorization
Before signing a transaction, the institution must verify that the underlying payment is legitimate:
• For a customer withdrawal, the platform needs to verify the customer’s identity, confirm that sufficient funds are available, and check that the request complies with its business rules.
• An internal transfer also requires the appropriate treasury approval.
But an attacker may alter account records or risk-control logic. The system may then follow its normal workflow and approve a payment that should never have been made.
On July 16, 2025, for example, BigONE disclosed a hot-wallet security incident, with estimated losses of $27 million. BigONE said its private keys remained secure. SlowMist’s investigationreported that the attacker had modified server logic related to accounts and risk controls, enabling unauthorized transfers.
The key point is that the information and rules used to approve the payment had already been altered before signing.
For payment institutions, verifying that a request comes from an internal service is therefore not enough. Each payment should be traceable to an independently verifiable customer instruction or treasury decision. Institutions also need to check whether a single compromised identity could fabricate requests, alter records, and change approval rules.
2. Transaction Construction and Verification
Is what you see really what you intend to sign?
Once a payment is approved, the system must translate business details, such as the recipient address and amount, into transaction data that the wallet can sign.
If this process is compromised, the interface may display a transfer while the transaction sent for signing actually changes who controls the wallet.
Your signature could then authorize an attacker to take over the wallet, even though you believe you are approving a transfer.
The approximately $1.5 billion Bybit attack in 2025 illustrates this risk. Bybit intended to transfer ETH from a cold wallet to a warm wallet. The attacker compromised the Safe interface and made a malicious transaction appear to be a routine transfer. The signers approved it, unknowingly authorizing a change to the wallet’s control logic.
The attacker used the valid signatures to replace the wallet’s control logic, then used the new logic to move assets without obtaining fresh approval from the original owners for each subsequent withdrawal. For a detailed on-chain analysis, see BlockSec’s analysis of the Bybit $1.5 billion hack.
The lesson is clear:
Verification before signing must cover the complete transaction being signed and the effects of its execution. It cannot rely solely on what the interface displays. Even multiple signers may fail to detect a problem if they all rely on the same compromised view.
Transfers, wallet upgrades, and changes to withdrawal permissions should also have distinct authorization requirements. Approval for an ordinary transfer should not be usable to change control of the wallet.
3. Signing Authorization and Key Use
Who can sign, and who can change the rules for signing?
Even if attackers cannot sign transactions directly, they may gain equivalent control by changing the rules or replacing the code running in the system.
Administrative permissions governing access to signing keys therefore need the same scrutiny as signing permissions themselves.
According to Resolv’s official post-mortem of its March 2026 security incident, the attacker’s initial attempts to obtain signing access failed. The attacker then used a privileged role to change the key’s access policy and grant themselves signing authority. With that authority, the attacker minted 80 million USR through two unauthorized transactions.
In another incident, Binance’s initial incident report describes a different route to signing access. The attacker used a compromised employee device and an internal AI tool to reach wallet engineers’ devices. Using a stolen container deployment token, the attacker deployed a container and ran a malicious script. Unauthorized access to the internal wallet signing service then allowed transactions to bypass the normal withdrawal workflow.
The entry points differed, but both incidents expose the same underlying issue:
Protecting keys also means controlling who can change key access policies, modify the signing environment, or grant signing permissions.
Payment institutions therefore need to examine all three questions:
-
Who can call the signing API?
-
Who can grant permission to call it?
-
Who can deploy or modify the signing service?
The separation of duties across business approval, key use, and administrative changes must also remain effective when a privileged identity is compromised.
4. Execution and Settlement
Does the risk end once a transaction is signed?
Not necessarily. Institutions must also consider when a signed transaction can be executed and how it can be invalidated.
Risk 1: A signed transaction may remain executable
A transaction has been signed but has not yet been executed. Can it still be submitted later?
Under some mechanisms, yes. Canceling the underlying business request does not automatically invalidate a signed transaction.
In the Drift Protocol incident on April 1, 2026, the attacker used Solana’s durable nonce mechanism to keep pre-signed transactions valid beyond the short validity window of ordinary transactions. As long as the relevant nonce had not been consumed or advanced, the transactions could still be submitted for execution later.
When a business request is canceled or suspicious activity is detected, institutions need a defined way to invalidate signed but unexecuted transactions. They must also specify who is authorized to do so.
Risk 2: An internal transfer may be misinterpreted and trigger an additional refund
On September 12, 2026, Chainflip suffered a Tron USDT exploit. The attacker attached a crafted memo to a transaction that validators had already signed. Chainflip’s system misread the memo as a separate swap, treated that swap as failed, and issued a refund. Chainflip reported six unauthorized payouts totaling approximately 736,400 USDT.
An on-chain transfer does not necessarily represent a new customer payment or justify a refund. Before making a payment or issuing a refund, the system must also verify the source of the funds, the type of business operation, and whether the corresponding payment obligation has already been fulfilled.
How Resilient Is Your Payment System?
These cases show that funds can be lost both before and after signing. A valid signature alone does not establish that:
• The payment has a legitimate business basis.
• The signed operation matches what was approved.
• The payment obligation has not already been fulfilled.
A meaningful security assessment for a payment institution should therefore answer concrete questions:
• Can each payment be traced to an independently verifiable business basis?
• Does the complete operation being signed match what was approved, including any permission changes or additional transactions?
• If an operational or administrative identity is compromised, do independent controls remain in place to block or limit unauthorized fund transfers?
• After withdrawals are suspended, can existing signatures and on-chain authorizations still be used to move funds? How can the institution confirm that containment is effective?
However, a one-time configuration review cannot provide lasting answers to these questions.
Software updates, permission changes, and changes to business operations can alter existing security boundaries. Institutions need to reassess whether their controls remain effective after such changes.
AI tools can also introduce new attack surfaces. Continuous monitoring helps teams detect suspicious activity. Incident response exercises test whether teams can limit further outflows after a critical identity or production environment is compromised.
For more on assessing these risks, see how BlockSec’s Payment Security Solution helps institutions stay secure in the AI era.
Join Our Webinar: Protecting Funds in the AI Era
To explore these questions, BlockSec will host an online webinar,"Protecting Funds in the AI Era". Drawing on recent security incidents involving exchanges and payment companies, the session will examine how attackers gain access to systems that handle fund through people, tools, and production environments, and how institutions can improve threat detection, authorization checks, and incident response.
Featured speakers:
• Yajin Zhou: Associate Professor at The Chinese University of Hong Kong; Co-founder and CEO of BlockSec
• Lei Wu: Associate Professor at Zhejiang University; Co-founder and CTO of BlockSec
• Muhui Jiang: CSO of BlockSec
Date and time: Wednesday, November 11, 2026, at 7:00 p.m. Singapore Time (SGT, UTC+8)
Format: Online webinar
Attendee benefit: Two participating institutions will be selected during the session to receive a complimentary preliminary security assessment.
Identifying risks early is essential to protecting every payment.
We invite executives, security leaders, and technical teams at payment institutions to join us in examining the security blind spots across the payment lifecycle.
Contact our sales team to learn more about the webinar.
Visit BlockSec Official Website>>>
