TL;DR:
- Two Vulnerabilities Mitigated: Polygon fixed medium-severity flaws in the BlockSTM V2 parallel execution engine of its Bor client.
- Computational Overload: Technical tests recorded delays of up to 11 seconds in the parallel engine compared to the milliseconds required by the serial path.
- Phased Rollout: The private rollout began on October 5 on Amoy and October 8 on mainnet, with no reports of active malicious exploitation.
The Polygon team fixes bugs across its mainnet execution architecture following the release of an update for the Bor client on October 15. The technical intervention resolved two medium-severity vulnerabilities that allowed valid, low-gas transactions to consume disproportionate computational resources across validator nodes.
Key Elements of the BlockSTM V2 Engine Flaw
The incident directly involved BlockSTM V2, the subsystem responsible for parallel execution within the Polygon Proof of Stake (PoS) network.
In this client, incoming blocks are processed through two simultaneous channels: a serial path and a parallel path, adopting the result from whichever finishes first. Internal tests demonstrated that transactions containing repeated code hashing took tens of milliseconds via serial execution. However, the parallel path remained occupied for approximately 11 seconds computing redundant operations.
The technical report disclosed by the team clarified that transaction cancellation checks only took place between transactions, forcing the node to complete costly speculative workloads even after the block’s state had already been finalized by the serial path. According to the firm’s analysis, the attack vector neither corrupted transfer outcomes nor compromised network consensus, but it posed a direct operational threat to node availability and state synchronization.
The two identified bugs stemmed from inefficient local resource management. First, speculative execution retained an excessive volume of data in memory through a shared cache lacking containment boundaries. Second, the software repeatedly recomputed the hash of smart contract code instead of reusing previously cached values.
Official documentation explains that gas fees charged to users account for standard operations, but do not always reflect internal processing overhead within client software implementations. Under this scenario, low-fee operations exerted a computational burden neither monetized nor anticipated by the virtual machine’s parameters.
To resolve this operational mismatch, Polygon rolled out Bor v2.10.3, which enforces a strict ceiling on the shared cache size. Additionally, the patch enables the reuse of cached hashing results whenever repeated reads occur on the same smart contract bytecode.
Rollout of Bor v2.10.3 and Operator Recommendations
The distribution of technical fixes was handled gradually prior to public disclosure to safeguard network infrastructure.
The official roadmap detailed that an unannounced preliminary release was distributed on the Amoy testnet on October 5. Subsequently, on October 8, Polygon delivered confidential builds to mainnet operators to ensure ecosystem stability. The public release of the post-mortem report and release notes took place on October 15, after the majority of validators and Remote Procedure Call (RPC) providers were already running the patched codebase.
Technical documentation for Bor v2.10.3 confirms that the deployment requires no hard forks, database migrations, or node resynchronizations. Node operators can apply the update independently across their servers.
Should nodes fall behind the tip of the chain, end-users could experience delays in transaction confirmations or stale data reads across wallets and decentralized applications. Polygon’s audit logs confirm that zero active exploits were detected across the mainnet or the Amoy testnet environment prior to the patch rollout.
The protocol’s immediate milestone requires remaining independent node operators still running Bor v2.10.2 or earlier to upgrade to version v2.10.3 during their next scheduled maintenance window.
Be the first to comment