Polygon has disclosed a set of security vulnerabilities that could have disrupted its Polygon proof-of-stake network. Polygon Labs' Validators Support Team said the flaws were patched through the Austin and Kyoto hard forks after private testing. The upgrades have already been activated on mainnet. The advisory was released only after validators had an opportunity to upgrade.
The stated issues affected Bor and Heimdall, two critical clients in the Polygon PoS stack. According to the advisory, the bugs included denial-of-service risks, validator resource exhaustion, and problems with checkpoint and milestone processing. Polygon said none of the vulnerabilities was observed being exploited on mainnet. The fixes were applied proactively before detailed technical information was made public.
A closer look at Polygon PoS architecture
Polygon PoS is a blockchain network designed to offer fast, relatively inexpensive transactions while still settling checkpoints on Ethereum. The architecture is not a single monolithic client. It is split into a block-producing sidechain known as Bor and a validator coordination layer known as Heimdall. Bor executes EVM-compatible smart contracts and can be thought of as the transaction engine; Heimdall is the control plane that handles staking, validator changes, checkpoints and the transfer of state information that ultimately helps secure Polygon's bridge.
A typical ecosystem participant using a Polygon wallet may only see Bor-level transactions, but those transactions are dependent on Heimdall's validation layer for combined protocol state. If something goes wrong on either side, normal users can experience stalled transactions or uncertain confirmation state. This interwoven design makes both clients important targets for any attacker looking to undermine the chain.
Heimdall vulnerability: extra work and exhausted validators
The most severe bug disclosed by Polygon was in Heimdall. A specially crafted transaction could force validators to perform excessive processing work. Because validators are expected to sign blocks, produce checkpoints and participate in protocol operations at regular intervals, an attacker who pushes their machines to process burdensome payloads could effectively limit capacity. The exhaustion of validator resources is a classic way to attack a proof-of-stake network. If enough validator nodes are busy, the chain could fail to achieve the validator participation required for finalizing checkpoints and milestones.
Polygon did not state that an exploit of this flaw would allow funds to be stolen directly. But attacks that prevent liveness can still be damaging. Delays in checkpointing to Ethereum could postpone bridge withdrawals or make some applications unable to finalize their state. Users rely on stable confirmation times; attacks that interfere with them can erode trust in the network.
Bor denial-of-service issues
The Austin hard fork included fixes for two denial-of-service risks in Bor. Those flaws could slow block processing or, in worse cases, cause nodes to crash. Bor is the client where users and protocols submit transactions. A DoS bug in this layer can be triggered remotely through a carefully crafted payload or transaction. If an attacker can force a node to do too much work, the node may not include new transactions or may fall behind the canonical chain. A network-wide DoS could create a gap in block production, leading to transaction queue buildup, higher fees and dApps with stale state or unavailable RPC endpoints. The fact that the Austin hard fork included mitigations for those two DoS vectors is significant.
Why Polygon delayed public disclosure
One of the most important contextual points is that Polygon did not publicly discuss the vulnerabilities until after the fixes were active. The disclosure describes a deliberate sequence: apply patches privately, test them, deploy them on mainnet, and only then inform the public. This order reduces the possibility that malicious actors will scan for unpatched nodes after reading an advisory. Publicizing before all validators update is a severe risk in blockchain security because the vulnerability details can be used to target nodes that have not yet upgraded.
Polygon said the hard forks were deployed privately and tested before being activated on mainnet and publicly disclosed. This is a standard process for consensus-level defects, but it is not always possible if an exploit is already being used in the wild. In this case, no observed exploits allowed the team to follow that safer sequence.
What node operators must do
Since the hard fork activation heights have passed, nodes running older versions of Bor or Heimdall have fallen out of consensus. In other words, they are no longer processing the same blockchain as the rest of Polygon PoS. This can manifest as stuck block heights, invalid state, failed transaction submissions
Source:Cointelegraph News