Mezo’s 5.52 BTC Exploit: The Authorization Flaw and the Audit-Scope Questions

Investigation | BlockBriefing

Reporting method and limits: We checked Mezo’s public incident account against its table of affected positions and a published audit of Mezo Earn. Loss shares and time intervals below are calculated from those records. Explorer links help readers check the project’s account, but we have not independently traced every transfer or identified the attacker. Statements from Mezo are attributed to the project, and its recovery promises are not presented as proof that repayments or recoveries occurred.

How Mezo calculated the 5.52 BTC loss

Mezo’s incident disclosure records 37 positions taken from 36 holders, with a combined reported amount of 5.519271401 BTC. The published table is unusually useful because it lists the affected position IDs, holder addresses and BTC amounts, allowing readers to audit the loss distribution rather than rely only on a rounded headline figure. The total is approximately 5.52 BTC; the exact figure in the table is used throughout this report where precision matters.

One listed position, NFT ID 826, accounts for 3.366676916 BTC, or approximately 61.0% of the reported total. A second holder appears twice in the table, with positions of 1.024286394 BTC and 0.262477784 BTC, totalling 1.286764178 BTC. These are calculations from Mezo’s disclosed table, not independent proof of the underlying wallet ownership. The concentration matters: a count of 37 positions can obscure how unevenly the reported loss was distributed.

The reported gap between theft and detection

According to Mezo’s timeline, the positions were taken between 18:54 and 19:06 UTC on October 5. The project says the proceeds were bridged to Ethereum at 19:09, exchanged for 174.61 ETH at 19:15, and consolidated at 19:51. Mezo says it first noticed anomalous activity at 08:45 UTC on October 6. That places the reported detection 12 hours and 54 minutes after the disclosed consolidation time. This is a calculation from the project’s timeline, not proof that the team could reasonably have detected the exploit earlier; the public report does not provide enough telemetry to establish that.

Mezo says bridge withdrawals were paused at 09:17 UTC, 32 minutes after the stated 08:45 detection time (described by the project as within 33 minutes). It located the vulnerability at 09:21 and halted all chain transactions at 09:27. The sequence suggests the bridge pause was the first disclosed containment measure after detection, while the broader halt followed ten minutes after that pause. To assess whether earlier intervention was technically possible, investigators would need alert logs, bridge monitoring thresholds and the precise timing of the first exploitable transaction—not just the public incident chronology.

How sender checks failed across a library call

Mezo attributes the flaw to the interaction between two design patterns: a trusted forwarder for meta-transactions and external Solidity libraries used to split contract logic. In the project’s account, the forwarder appends the authenticated sender’s address to calldata. When execution enters an external library, the compiler creates a new argument buffer from the function’s declared parameters; the appended sender is not a declared parameter and therefore is not automatically carried into that buffer. A crafted safeTransferFrom data field could then cause the contract to interpret attacker-controlled trailing bytes as the sender.

The security lesson is not that meta-transactions or external libraries are inherently unsafe. It is that identity and authorization assumptions must remain valid across every call boundary. A sender check is only as trustworthy as the data source it reads in the exact execution context where the check occurs. This is Mezo’s explanation of the root cause; a complete independent code-level finding would require reviewing the vulnerable and patched source, compiler configuration, and relevant call traces side by side.

What the documents prove, and what they cannot

• Supported by Mezo’s disclosure: 37 positions across 36 holders were affected; the listed positions total 5.519271401 BTC; the project’s stated transaction sequence; the described authorization flaw; and the project’s account of its containment steps.
• Calculations in this report: the largest position represented approximately 61.0% of the disclosed total; the two positions associated with the same listed holder total 1.286764178 BTC; and the time intervals calculated from Mezo’s timeline.
• Not independently established here: the attacker’s real-world identity, control of any exchange account, the final disposition of all proceeds, whether every recipient address was correctly attributed, and whether promised reimbursements have been completed.

The transaction and address links in Mezo’s incident report provide starting points for independent verification, but an explorer link alone is not a full forensic trace. A publication-grade fund-flow reconstruction should document each transaction hash, sender, recipient, asset, amount, timestamp and bridge or swap event, and distinguish direct on-chain observations from attribution supplied by a project or third party. This report does not label a wallet as belonging to a named person or exchange without corroborating evidence.

What the audit scope can actually tell us

Mezo says the exploited code had been audited twice, but that does not by itself establish which deployed version was reviewed or whether this exact authorization path was in scope. An audit is evidence about a defined codebase and review scope, not a guarantee that every deployed interaction is safe.

BlockBriefing located a public January 30, 2026 Mezo Earn security audit report by Thesis Defense. It identifies the mezo-org/tigris-token-launch repository, names audit and verification commits, and says the review focused primarily on voting-power accounting, boost mechanics, reward distribution and related state transitions. The report lists nine findings.

What this establishes: a public audit report exists, and its stated scope and commit identifiers can be checked against the vulnerable production code. What it does not establish: whether the vulnerable VotingEscrow deployment and meta-transaction sender-resolution path were included, whether the second audit covered the same code, or whether the defect existed at the audited commit. We do not present this document as proof that the named auditors missed the exploit.

The decisive follow-up is a version comparison: match the vulnerable and patched deployed source to the audit’s named commits, identify the exact library call path, and determine whether sender authentication across external-library boundaries was in scope. Until that mapping is documented, both “audited twice” and “audit failure” are incomplete descriptions.

What remains unknown about refunds and recovery

Mezo stated that affected users would be repaid from protocol-owned sources. That is a commitment in the incident report, not evidence by itself that transfers were completed. The public report also offered the attacker a settlement with a deadline of October 14, 2026; that deadline has passed. This investigation does not infer that the offer was accepted or that funds were recovered. Those outcomes require a subsequent official update and, where possible, on-chain confirmation of transfers to affected wallets.

Several questions remain material: Were all affected holders reimbursed, and when? Was any portion of the 174.61 ETH recovered or frozen? Which exact deployed code version introduced the vulnerable interaction? Did the two audits cover that version and execution path? What automated alert would have detected the first unauthorized position transfer, and what evidence supports the project’s statement that this was the only exploitation of the flaw?

What the available evidence supports

The strongest finding is architectural: authorization derived from appended calldata can fail when execution crosses a boundary that rebuilds the argument buffer. The disclosed timeline also shows how quickly the attacker moved the proceeds off Mezo before the project says it detected anomalous activity. But the incident report alone cannot settle the questions of audit coverage, preventability, fund recovery or reimbursement completion. BlockBriefing will treat those as open questions until documentary or on-chain evidence supports a firmer conclusion.

The October 5 incident affected 37 veBTC positions belonging to 36 holders, according to Mezo. The project says the attacker took control of the positions and redeemed the underlying bitcoin. Its position table lists 5.519271401 BTC. The detailed record below examines how meta-transaction sender handling interacted with external Solidity libraries, an implementation boundary Mezo identified as the source of the authorization flaw.

Mezo said the attacker bridged the proceeds to Ethereum, exchanged them for 174.61 ETH and consolidated the funds into a holding wallet. The team disclosed the incident on October 7 and said affected users would be reimbursed from protocol-owned funds. The principal question raised by the disclosed record is not simply why a contract bug existed, but why it allowed a position-transfer path to treat crafted input as proof of ownership.

A closer look at the affected positions

Mezo’s October 7 incident report identifies 37 affected veBTC positions held by 36 addresses. The reported total is 5.519271401 BTC, close to the project’s rounded estimate of 5.52 BTC. The difference is rounding, not a separate loss figure.

The affected-position list also shows that losses were unevenly distributed. One listed position contained 3.366676916 BTC—about 61% of the total reported amount. A second holder had two affected positions totaling 1.286764178 BTC. These calculations are derived from the project’s published table; they do not independently establish the holders’ identities or the final reimbursement status.

The distinction matters. Counting affected positions alone can obscure how concentrated the reported loss was. Thirty-seven positions were affected, but one position represented most of the bitcoin in the disclosed list.

The event-by-event response timeline

The timestamps below are UTC and come from Mezo’s published incident chronology. They should be read as the project’s disclosed timeline, rather than a complete independent reconstruction of every transaction.

• October 5, 18:03: The attacker’s Mezo address was funded for gas from Ethereum, according to Mezo.
• 18:54–19:06: The attacker took 37 veBTC positions. The disclosed attack window lasted approximately 12 minutes.
• 19:09: The proceeds were bridged from Mezo to Ethereum.
• 19:15: Mezo says the proceeds were exchanged for 174.61 ETH on a decentralized exchange.
• 19:51: The proceeds were consolidated into a holding wallet.
• October 6, 08:45: The team noticed anomalous rebase transactions involving bitcoin withdrawals to the zero address and began investigating veBTC locks.
• 09:04: Mezo declared a security incident.
• 09:17: Bridge withdrawals were paused.
• 09:21: The vulnerability was located in the code, according to the report.
• 09:27: Mezo halted all transactions on the chain.
• 15:00: The project said the fix was in place and the bridge and chain were unpaused.

The timing highlights a key operational issue. The disclosed theft and consolidation ended at 19:51 UTC on October 5; the team says it detected anomalies at 08:45 UTC the next day, roughly 12 hours and 54 minutes later. Once the incident was recognized, bridge withdrawals were paused 33 minutes after the reported detection time. Those intervals are calculated from Mezo’s stated timestamps and do not, by themselves, establish negligence or prove that all losses could have been prevented by earlier detection.

The project linked a Mezo explorer transaction in its report. Readers can inspect that record at the Mezo block explorer. Mezo also published an address associated with its proposed return-and-bounty arrangement; the address is visible on the Mezo explorer. The existence of an address page alone should not be treated as proof of current control, identity or recovery status.

Where the contract lost the sender’s identity

Mezo’s explanation centers on its VotingEscrow contract, which manages veBTC positions represented by NFTs. The system supports meta-transactions: a trusted forwarder verifies a user’s off-chain signature and appends the verified sender’s address to the end of the call data. The target contract can then read that appended address to determine who authorized the action.

Mezo also split contract logic into external Solidity libraries to work within the Ethereum Virtual Machine’s contract-size limit. According to the incident report, a call into an external library creates a new stack frame and a fresh argument buffer based on the declared function parameters. The extra sender address appended by the forwarder is not a declared parameter, so it is not automatically carried into that new argument buffer.

The attacker reportedly crafted the _data parameter of safeTransferFrom so that the final 20 bytes could be interpreted as the trusted forwarder’s sender address. In effect, the contract’s authorization logic could be made to attribute the action to an address supplied through attacker-controlled input rather than reliably preserving the original authenticated caller.

This is not the same as a stolen private key or a compromised validator. Based on Mezo’s technical account, the core issue was an authorization-context mismatch across a contract/library call boundary. A valid signature at one stage did not guarantee that the downstream function interpreted the caller correctly.

Why unlocked veBTC positions were vulnerable

Mezo says the flaw could allow control over veBTC positions, but the attacker specifically selected positions whose lock periods had expired and which had not yet been redeemed. That choice reduced the need to wait for a lock to expire: the positions could be redeemed and the bitcoin moved off the chain.

This is a significant detail in understanding the incident. The weakness affected an ownership-sensitive path, while the attacker’s selection of unlocked positions appears to have optimized the route from unauthorized control to liquid assets. The public report does not establish the attacker’s identity or motive, and this analysis does not infer either.

What Mezo’s response confirms

Mezo said it disabled meta-transactions, reviewed other external library functions using the same sender-resolution pattern and found three additional functions with more constrained access-control exposure. The report says those functions were covered by the same fix. It also states that the vulnerable code had been audited twice and had a bug bounty program, but that the flaw had not been reported through the program or the project’s security email.

That disclosure points to a familiar limit of point-in-time audits: a review can miss a bug that depends on the interaction of multiple implementation details. It does not establish that audits are useless. It shows why review scope, call-path modeling, adversarial tests and post-deployment monitoring must complement one another.

Mezo said it contacted SEAL 911, centralized exchanges in the funding chain, venues used in the laundering path and law enforcement. It also said affected users would be reimbursed from protocol-owned sources. This report does not independently verify that every affected user has since been reimbursed, nor does it claim that all assets were recovered. The project’s stated recovery commitment and the actual completion of repayments are separate facts that require separate confirmation.

The questions Mezo still needs to answer

• Detection: What specific monitoring would have identified the first unauthorized position transfer rather than the later anomalous rebase activity?
• Audit coverage: Did prior reviews explicitly model sender identity across external library calls and meta-transaction forwarding?
• Regression testing: Were tests added to ensure crafted callback data cannot override the authenticated sender in any reachable function?
• Recovery: Has Mezo published a verifiable completion record for reimbursements to all 36 affected holders?
• Fund tracing: What portion of the converted assets, if any, has been frozen or recovered by exchanges or other intermediaries?

These are unresolved questions in the public material reviewed for this report, not allegations that the project failed to take action. A complete follow-up should compare future project disclosures with transaction-level records and seek answers from the project and relevant response partners.

What this incident shows about authorization risks

The strongest evidence in this case is the project’s detailed affected-position table and its technical explanation of how the authorization failure occurred. The record supports a clear conclusion: an interaction between meta-transaction sender handling and external-library argument forwarding enabled unauthorized control of veBTC positions, after which the attacker rapidly moved the proceeds off Mezo.

The incident also exposes two distinct security questions. The first is preventive: can a contract guarantee that authorization survives every internal call path? The second is operational: how quickly can abnormal withdrawals be detected and contained before funds leave the system? Fixing the code addresses the first. The second requires monitoring, tested emergency controls and transparent post-incident verification.

For readers, the lesson is not to assume that every audited protocol is unsafe. It is to ask whether its authorization design has been tested across the entire execution path, whether its monitoring can detect anomalous behavior quickly, and whether recovery claims are supported by verifiable updates.

Sources and methodology

• Mezo: Incident report, October 5, 2026 — primary source for the disclosed timeline, affected-position list, technical explanation and stated response.
• Mezo block explorer: transaction linked from the incident report.
• Mezo block explorer: address linked from the incident report.

For comparison with a different smart-contract control failure, see our X100 governance exploit investigation. It concerns voting and treasury permissions, not Mezo’s sender-authorization mechanism.

Methodology: This is an original analytical report based on the primary incident disclosure, calculations from the published affected-position table and explorer links supplied by the project. It is not a claim of independently identifying the attacker, auditing Mezo’s source code or independently tracing every asset through all subsequent addresses. Figures and conclusions may change if further verified evidence is published.