Polygon has patched two vulnerabilities in BlockSTM V2, the parallel execution system inside the Bor client that powers the Polygon PoS blockchain, which could have allowed valid transactions to slow down network nodes. According to Polygon's published technical review, the bugs did not change transaction results or threaten consensus. Their risk was availability: a node could compute the correct result for a block yet spend so long processing it that it fell behind the rest of the network. The company disclosed the findings alongside the public release of Bor v2.10.3, the client version that contains the fixes.

Polygon says it has no knowledge of exploitation on mainnet or the Amoy testnet.

Why serial execution finishing first did not end the delay

Bor processes incoming blocks through both serial and parallel execution, adopting whichever route finishes first. Serial execution follows transaction order, while parallel execution attempts to process transactions concurrently and then verifies whether its assumed dependencies were correct. That approach can speed up ordinary workloads when transactions do not depend on one another, but it also creates speculative work that must stop promptly once it is no longer useful.

This design places Bor in the family of optimistic parallel execution systems: the client assumes most transactions are independent, runs them side by side, and pays a verification cost when an assumption turns out wrong. Performance bugs in such systems tend to surface as wasted work rather than wrong answers, which matches the profile Polygon described.

Polygon's repeated-code-hashing test exposed the gap. Serial execution completed the transaction in tens of milliseconds, yet the parallel route kept working for roughly 11 seconds. At the time, cancellation was only checked between transactions, meaning an expensive transaction already running in parallel had to finish even after serial execution had produced the result.

That is why the test mattered: the transaction was valid, and Bor could determine its final state quickly, but the node still had to wait for unnecessary processing to end.

Two flaws created work gas did not fully price

The two vulnerabilities stemmed from different sources of excess work. One allowed speculative execution to retain too much calculated data. The other repeatedly recalculated a contract's code hash when it could have reused an earlier result.

Gas limits charge users for specified transaction operations, but they do not always capture every cost introduced by a client's implementation. In these cases, cache growth and redundant hashing could generate node-side work that was disproportionate to a transaction's apparent cost.

Polygon classified both bugs as medium severity and said neither was consensus-affecting. The rating lines up with the profile of the findings: the exposure was slower nodes and wasted resources, not altered transaction outcomes or damaged consensus.

What the Bor v2.10.3 patch changes

The v2.10.3 fixes constrain that overhead without changing execution outcomes. The update limits the shared cache used during speculative execution and enables Bor to reuse a code-hash result instead of recalculating it during repeated reads. The goal is to prevent a valid but awkward workload from consuming excessive resources or extending block-processing time unnecessarily.

According to the Bor v2.10.3 release notes, the public release requires no hard fork, database migration, or node resynchronization. Operators can upgrade their nodes individually.

Private patching preceded the public disclosure

Polygon said it distributed a private build for the Amoy testnet on October 5, followed by a private mainnet build on October 8. It published the technical disclosure on the Polygon governance forum on October 15, after upgrades had reached most of the network. A separate release announcement covers the rollout on mainnet and testnet.

The release notes state that most validators and major RPC providers already ran the private version. That does not mean every connected node had upgraded, which is why Polygon's operator announcement urges users of Bor v2.10.2 or earlier to update promptly. Operators already on the private builds can move to the public release during their next maintenance window.

The remaining issue is patch coverage

For wallets, applications, and other services, nodes that fall behind can return delayed chain information or take longer to submit transactions. Polygon's disclosure does not establish that users experienced such disruption, and the company says it knows of no exploitation on mainnet or Amoy.

Because v2.10.3 ships without a hard fork, there is no protocol-level deadline that forces laggards to upgrade; adoption proceeds on each operator's own schedule. That makes patch coverage the observable signal to follow: how quickly the Bor operators on v2.10.2 or earlier move to the fixed release.

Polygon's broader work on faster processing and payment infrastructure makes that operational reliability relevant. The patch removes the two identified sources of excess work; the practical next step is for remaining Bor operators to apply it.

This article is provided for informational purposes only. Vulnerability descriptions and exploitation assessments reflect Polygon's published disclosure.

Source: Coindoo