Polygon has disclosed a series of previously private security vulnerabilities that could have disrupted its proof-of-stake network, including denial-of-service vectors, validator resource-exhaustion risks and flaws affecting checkpoint and milestone processing.
Polygon Labs’ Validators Support Team disclosed the issues on Aug. 27 after fixes had already been activated through two coordinated hard forks: Austin for the Bor execution client and Kyoto for the Heimdall consensus client.
Polygon said it deliberately kept the details private while the fixes were distributed, first validating them on the Amoy testnet before activating them on mainnet. The vulnerabilities were made public only after the affected network infrastructure had been upgraded. None was observed being exploited on Polygon PoS before remediation.
The more serious group of vulnerabilities was addressed by the Kyoto hard fork in Heimdall v0.11.0.
Heimdall sits at the consensus layer of Polygon PoS. It manages validators and staking, chooses Bor block producers and handles checkpoints and milestones used to establish network finality. Polygon’s architecture combines Heimdall with Bor, which serves as the block-production and execution layer.
Among the Kyoto fixes was a vulnerability involving deeply nested google.protobuf.Any fields inside Heimdall transactions.
Because one Any object could be placed inside another without a sufficient depth limit, an attacker could construct a relatively cheap transaction that forced every validator to perform large amounts of decoding work simultaneously.
Polygon described the issue as the most severe vulnerability in the batch because it provided a permissionless way to impose expensive, correlated processing across the entire validator set.
Kyoto introduced a byte-level scan that rejects transactions once nesting exceeds a defined threshold. Crucially, Polygon applied the same rule both when transactions enter the mempool and when validators process proposed blocks, reducing the risk that different validation paths disagree over the same transaction.
The hard fork also capped the number of fee coins that a transaction can declare. Previously, the validation process could be forced to scan an unbounded list, providing another potential resource-exhaustion vector.
Other Heimdall changes dealt with less direct but still important consensus and finality risks.
Polygon corrected checkpoint signature handling that could have caused a valid checkpoint to fail during submission to Ethereum, potentially stalling checkpoint anchoring. It also changed how repeated block-producer downtime messages are processed so the same message cannot create additional spans multiple times.
Kyoto additionally tightened milestone voting by requiring votes extending a milestone range to correspond to the specific signed parent hash, strengthened checkpoint-window continuity checks and changed failed future-span creation so it no longer blocks a milestone commitment.
Polygon also fixed a narrow replay-key issue in which two distinct Layer 1 events could potentially map to the same identifier, causing one event to shadow another.
The Kyoto hard fork activated on Polygon PoS mainnet at Heimdall block 51,533,000 on Aug. 18. Polygon had already activated it on Amoy at block 42,252,000. Heimdall v0.11.0 is mandatory for validators and full nodes.
Austin Closed Two Bor Denial-of-Service Paths
The Austin hard fork addressed two separate denial-of-service risks inside Bor.
One involved Polygon’s state-sync process, through which events such as Layer 1-to-Layer 2 bridge deposits execute contract code on Polygon.
Unlike ordinary transactions, the gas consumed by these state-sync events did not previously count against an explicit per-block hard limit. Polygon said a block containing enough state-sync events, or a particularly expensive event, could therefore require enough processing time to temporarily stall the chain.
Austin added a per-block state-sync gas ceiling.
The second vulnerability concerned Bor’s TxDependency field, which provided information intended to assist parallel transaction execution.
The field had no size limit. That meant a block producer could potentially include an extremely large TxDependency payload in an otherwise valid block, causing other nodes receiving it to crash while processing the data.
Polygon removed the field from the wire format entirely, saying parallel execution does not require peers to trust the block producer’s dependency hint.
Neither Bor vulnerability affected the correctness of consensus itself, according to Polygon. Instead, both represented resource-exhaustion or denial-of-service paths that could interfere with block processing.
Austin activated on mainnet at Bor block 91,949,700 after an earlier Amoy activation. Polygon said Bor v2.10.0 contained the required security changes and warned that any node that remained on an older release after the hard-fork height had already diverged from the canonical network.
Polygon subsequently released Bor v2.10.1 on Aug. 28 with additional features including BlockSTM v2 and peer jailing. The security disclosure still identifies v2.10.0 as the minimum Austin-compatible release, although v2.10.1 is now the newer available Bor version.
Nodes that missed either hard fork do not need a complete resynchronization. Polygon said operators can upgrade, roll back to a block before the relevant activation height and then allow the node to resync onto the canonical chain.
POL was trading near $0.10 on Aug. 30, with CoinGecko showing the token down roughly 5% over seven days but up about 44% over the previous month. Its market capitalization stood at roughly $1.09 billion.
Analysis: Polygon Fixed the Bugs, but the Process Is Part of the Security Model
The most reassuring part of Polygon’s disclosure is straightforward: attackers apparently never got the opportunity to exploit these vulnerabilities on mainnet.
That matters because several of the flaws were not theoretical inconveniences.
The nested-transaction issue could have forced every Heimdall validator to perform expensive work at the same time. The Bor vulnerabilities could have slowed block execution or crashed peers. Other bugs touched checkpoints and milestones, mechanisms that Polygon depends on for finality and communication with Ethereum.
A successful exploit would therefore have created a very different story from a conventional smart-contract hack affecting one application.
But Polygon’s response also illustrates an uncomfortable part of blockchain security: sometimes protecting a decentralized network requires temporarily limiting how much information its decentralized operators receive.
Polygon did not publicly announce exactly what the Austin and Kyoto upgrades fixed before activation. Instead, the team privately distributed and tested consensus-changing software and disclosed the vulnerabilities only after the mainnet had crossed the relevant fork heights.
From an attacker-defence perspective, the logic is strong.
Publishing a detailed description of a network-level denial-of-service flaw before most validators are protected would effectively provide an instruction manual. Even releasing source code can expose enough information for sophisticated researchers to identify the vulnerability by comparing versions.
The alternative creates its own trust issue.
Node operators are being asked to install mandatory software that can change consensus rules without having complete public information about why the change is necessary.
That means decentralization does not eliminate coordinated trust during an emergency. It shifts that trust toward maintainers, validator communication channels and the software-release process.
The hard forks also show why update discipline matters more for blockchain infrastructure than for ordinary software.
A user who ignores a browser update can often continue using an older version for months. A Polygon validator that ignored Austin or Kyoto eventually became part of a different chain.
Polygon made that explicit: once the activation heights passed, old software was no longer merely outdated. It was outside consensus.
That mechanism is necessary for consensus-critical security fixes to work, but it demonstrates that network security depends on enough independent operators upgrading in coordination before a deadline.
There is another useful distinction in Polygon’s disclosure. Not every serious blockchain vulnerability involves stealing tokens.
Most of the newly revealed bugs were availability and resource-management problems. An attacker could potentially have harmed Polygon without taking a dollar directly by making blocks too expensive to process, crashing nodes or interfering with checkpoint progression.
For a blockchain increasingly used for payments and stablecoin transfers, uptime itself is an economic asset.
Polygon’s handling of Austin and Kyoto can therefore be viewed as a successful security operation: the vulnerabilities were identified, privately mitigated, tested and activated without known exploitation.
But the real test of such a process is not simply whether it worked this time.
It is whether Polygon can repeatedly coordinate validators quickly enough when the next vulnerability is more urgent, easier to reverse-engineer or already known to an attacker.
The code fixes are now public. What these two hard forks really demonstrate is that the security of a proof-of-stake network depends just as much on disclosure timing, validator coordination and upgrade discipline as it does on the quality of the code itself.