Polygon Reveals Security Flaws Only After Hard Forks Fixed Them

All news is rigorously fact-checked and reviewed by leading blockchain experts and seasoned industry insiders.

• Polygon disclosed vulnerabilities affecting both Bor and Heimdall after deploying the fixes.
• Austin closed two denial-of-service paths in Polygon PoS block processing.
• Kyoto addressed a broader set of consensus and input-validation weaknesses.
• Outdated nodes are already outside canonical consensus and must upgrade.

Polygon Labs has disclosed previously private vulnerabilities in its Proof-of-Stake network after fixes were already deployed through the Austin and Kyoto hard forks. The issues ranged from denial-of-service paths in the Bor execution client to a crafted-transaction attack capable of forcing costly processing across Heimdall validators. Polygon said it observed no exploitation on mainnet.

More notable than the disclosure itself is its timing. Polygon deliberately withheld technical details while patches were privately distributed and tested, reducing the period in which attackers could study a known vulnerability while validators remained exposed.

Polygon Patched First and Disclosed Later

Consensus vulnerabilities create a difficult disclosure problem.

Publishing technical details too early can effectively give attackers instructions before enough node operators have installed the fix. Waiting too long, however, reduces transparency about risks affecting the network.

Polygon chose a patch-first approach.

According to its Aug. 27 security review, the Austin and Kyoto changes were initially rolled out privately and validated on the Amoy testnet before mainnet activation. Details were released once the network had moved onto the patched versions.

That sequence is important because the vulnerabilities were not merely theoretical software bugs. Several could have degraded network availability if deliberately triggered.

Polygon nevertheless reported that neither Austin’s denial-of-service issues nor the Kyoto vulnerabilities were exploited on mainnet before being fixed.

Austin Closed Two Resource-Exhaustion Paths

The Austin hard fork upgraded Polygon’s Bor execution client to v2.10.0 and focused on two denial-of-service vectors in block processing.

One involved Polygon’s state-sync mechanism, which carries events from Ethereum to Polygon PoS.

These operations can execute contracts and precompiles similarly to ordinary transactions, but their resource consumption was not adequately bounded at the block level. A sufficiently expensive state-sync workload could therefore place excessive computational pressure on nodes and potentially stall block processing.

Austin introduced a per-block gas limit for state-sync operations, putting a ceiling on how much processing they can consume.

The second weakness involved Bor’s TxDependency field.

Because the data structure did not have a strict size limit, a maliciously oversized input could consume excessive resources when received or decoded, potentially stalling processing or crashing connected peers.

Austin removed the unbounded field.

Neither vulnerability represented a direct theft mechanism. The primary risk was availability, with an attacker potentially degrading the ability of nodes to process blocks reliably.

Kyoto Addressed the More Serious Validator Risk

The Kyoto hard fork, implemented through Heimdall v0.11.0, dealt with a wider set of problems affecting consensus processing, checkpoints, milestones and input validation.

Polygon identified deeply nested google.protobuf.Any messages as the most severe issue in the batch.

Heimdall transactions can wrap messages inside Any structures, which themselves can contain additional Any messages. Without a depth limit, an attacker could construct a transaction that was relatively cheap to submit but computationally expensive for validators to decode.

The asymmetry is what made the flaw dangerous.

One crafted transaction could force many validators to perform the same expensive processing simultaneously.

Kyoto introduced a byte-level pre-scan that rejects transactions once message nesting exceeds the permitted threshold. Crucially, Polygon applies the same rule at both mempool admission and the consensus-processing stage, preventing different parts of the network from treating the same transaction differently.

The fork also capped fee-coin lists to prevent excessive linear scanning and standardized checkpoint signature recovery bytes to reduce the risk of checkpoint anchoring problems on Ethereum.

Other fixes hardened milestone accounting and L1 event replay behavior.

Why Resource Exhaustion Can Threaten a Blockchain Without Stealing Funds

The vulnerabilities highlight a different category of blockchain security risk from the exploits that typically dominate crypto headlines.

A smart-contract exploit may allow an attacker to drain assets directly. Resource-exhaustion attacks instead target the network’s ability to keep processing transactions and reaching consensus.

The economics can be particularly problematic when there is a large asymmetry between the attacker’s cost and the network’s cost.

If an attacker can cheaply create an input that requires every validator to perform substantial computation, the cost is multiplied across the validator set. Repeating that process can slow block processing, increase node resource consumption or, in severe cases, interfere with network liveness.

Polygon’s patches therefore focus heavily on introducing bounds: limits on gas consumption, message depth and list sizes.

Those restrictions make the computational cost of processing attacker-controlled data more predictable.

Old Nodes Are Already Outside Canonical Consensus

For node operators, the disclosure is no longer simply an advisory about future upgrades.

Both hard forks are already active.

Polygon says nodes that remained on earlier versions beyond the relevant activation heights have already forked away from the canonical network.

Operators can recover by installing compatible binaries, rolling back to the appropriate pre-fork height and allowing the node to resynchronize.

The upgrades do not require a genesis change, state migration or complete resync, reducing the operational burden for affected operators.

Polygon has since released Bor v2.10.1, although v2.10.0 remains the minimum Austin-compatible version.

The Disclosure Changes the Risk for Nodes That Still Haven’t Upgraded

Polygon’s delayed disclosure reduced exposure while the network was migrating, but publication now changes the security environment.

The technical mechanisms behind the vulnerabilities are public. That is not a major concern for nodes already running Austin- and Kyoto-compatible software because the relevant attack paths have been closed.

It is more consequential for operators still running obsolete binaries.

Before disclosure, an outdated node was primarily dealing with a compatibility problem. Now it is running software with publicly documented security weaknesses while also sitting outside canonical consensus.

That makes upgrading more urgent even though Polygon reported no historical mainnet exploitation.

The episode also provides a useful measure of Polygon’s security process beyond whether funds were lost. Austin and Kyoto show the network using coordinated client upgrades to close vulnerabilities before publishing enough detail for them to be reproduced.

The next operational metric is therefore straightforward: how quickly the remaining outdated infrastructure disappears now that both the patches and the underlying attack vectors are public.

Source