Taiko Alethia Pacaya inbox verification pointer corruption
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| taikoxyz | taiko-mono | affected |
|
No data.
No data.
| Vendor | Product | Versions |
|---|---|---|
| Taiko | Taiko-mono | — |
No CVSS v3.1
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.334% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Taiko
Taiko taiko-mono |
|
| Vendors & Products |
Taiko
Taiko taiko-mono |
| Type | Values Removed | Values Added |
|---|---|---|
| Description | 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. | |
| Title | Taiko Alethia Pacaya inbox verification pointer corruption | |
| Weaknesses | CWE-129 | |
| References |
| |
| Metrics |
cvssV4_0
|