BNB Chain has released a hotfix for its BSC-Reth execution client after an upstream Reth bug was found capable of producing incorrect blockchain state roots under specific conditions. The issue is limited to infrastructure running BSC-Reth, while BNB Chain says opBNB is unaffected because it does not use op-reth. No user funds have been reported lost and BNB Smart Chain has not experienced a confirmed disruption tied to the flaw.
According to the official BSC-Reth v0.1.4-hotfix release, published on November 6, all BSC-Reth operators on mainnet and testnet are recommended to upgrade and restart their nodes as soon as possible. The guidance covers validators, MEV builders, full nodes and sentry operators. Ordinary users do not need to take action.
Hotfix Targets Legacy State-Root Path
The vulnerability originates in Reth’s trie implementation and concerns a legacy path used to calculate state roots, the cryptographic commitments representing the current state of accounts and contract storage. Under specific trie conditions, the affected code could calculate an incorrect root, potentially leaving a node with state information that does not match the canonical chain.
The upstream correction was merged into Reth through pull request #28264, which tightened an iterator boundary and added a regression test for incremental state-root calculations. BNB Chain incorporated that correction into v0.1.4-hotfix. Installing the patch requires a client restart but no database migration or hard fork, making the remediation an operational software update rather than a consensus upgrade.
The distinction is relevant because BSC operators already manage protocol-level upgrades separately. Earlier in 2026, the network’s Fermi hard fork reduced BNB Smart Chain block times, requiring coordinated node software changes. The Reth hotfix does not introduce new consensus rules or activate a network feature, but instead corrects client behavior that could cause inconsistent state calculations.
Base Also Patches Reth Bug
The flaw was not specific to BNB Chain. Base, which also relies on Reth-derived infrastructure, said it identified exposure to the same issue and patched its block builders. Base independently recomputed its state root, confirmed that the existing chain state was correct and said users were not affected. The network subsequently released version 1.5.3 for node operators to remove the risk of validators halting on invalid state roots.
Execution-client updates are a distinct security layer from application-level smart-contract incidents. Clients such as Reth, Geth and Besu maintain and execute blockchain state, with maintenance releases such as Geth v1.17.5 affecting infrastructure operators rather than ordinary token holders. A bug in one client therefore does not automatically mean that the underlying blockchain itself has been exploited.
That boundary is particularly important when software components are reused across EVM ecosystems. Similar dependency concerns have appeared when Cosmos EVM networks faced vulnerabilities in shared infrastructure, although the technical causes and impact were different. In the BSC-Reth case, the currently documented response is preventative: patch affected nodes before an incorrect state-root calculation creates an operational problem.
BNB Chain’s release notes recommend immediate adoption of v0.1.4-hotfix but do not report a chain rollback, resynchronization requirement or user-facing recovery process. The confirmed issue remains a client-level correctness bug with a patch available, not evidence of a successful attack on BNB Smart Chain.