CVE-2025-66559 in taiko-mono
Summary
by MITRE • 12/05/2025
Taiko Alethia is an Ethereum-equivalent, permissionless, based rollup designed to scale Ethereum without compromising its fundamental properties. In 2.3.1 and earlier, TaikoInbox._verifyBatches (packages/protocol/contracts/layer1/based/TaikoInbox.sol:627-678) advanced the local tid to whatever transition matched the current blockHash before knowing whether that batch would actually be verified. When the loop later broke (e.g., cooldown window not yet passed or transition invalidated), the function still wrote that newer tid into batches[lastVerifiedBatchId].verifiedTransitionId after decrementing batchId. Result: the last verified batch could end up pointing at a transition index from the next batch (often zeroed), corrupting the verified chain pointer.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 12/06/2025
The vulnerability identified as CVE-2025-66559 affects Taiko Alethia, an Ethereum-equivalent permissionless rollup system designed to scale Ethereum while preserving its core properties. This critical flaw exists in the TaikoInbox._verifyBatches function within the smart contract codebase, specifically in versions 2.3.1 and earlier. The vulnerability stems from improper handling of batch verification logic that creates a race condition between transition advancement and actual verification completion. The affected contract file TaikoInbox.sol contains the problematic implementation at lines 627-678 where the system advances a local transition identifier (tid) without ensuring that the corresponding batch will actually be verified.
The technical flaw manifests when the verification function processes batches and advances the local transition identifier to match the current blockHash before confirming whether the batch will actually be verified. This premature advancement occurs within a loop structure where the function may later break due to various conditions such as cooldown window not yet passed or transition invalidation. When these conditions cause the loop to terminate prematurely, the system still writes the newer transition identifier into the batches[lastVerifiedBatchId].verifiedTransitionId field after decrementing the batchId. This results in a critical pointer corruption where the last verified batch ends up referencing a transition index from a subsequent batch, often containing zeroed values. The vulnerability creates a fundamental chain corruption issue that affects the integrity of the verified chain state.
The operational impact of this vulnerability is severe as it compromises the fundamental integrity of the rollup's verification mechanism and chain consistency. The corruption of verified chain pointers can lead to invalid state transitions, potential double-spending scenarios, and complete chain invalidation. Attackers could exploit this vulnerability to manipulate the verification state, potentially causing the system to accept invalid batches or reject valid ones. The issue particularly affects the rollup's ability to maintain a consistent and trustworthy state, which is critical for any Ethereum-equivalent system where security and trustlessness are paramount. This vulnerability directly impacts the system's ability to perform proper batch verification and maintain the chain's historical integrity.
The vulnerability aligns with CWE-691, which covers inadequate initialization of security-critical variables, and demonstrates characteristics similar to CWE-362, indicating a race condition in the verification process. From an ATT&CK framework perspective, this vulnerability could be leveraged for privilege escalation and denial of service attacks within the rollup infrastructure. The attack surface extends to anyone interacting with the TaikoInbox contract, including validators, relayers, and end users who depend on the chain's integrity. Organizations should immediately implement mitigations including patching to version 2.3.2 or later, implementing additional validation checks before advancing transition identifiers, and monitoring for any chain corruption indicators. The fix should ensure proper synchronization between transition advancement and actual verification completion, preventing premature pointer updates that could compromise the chain's verification state.