Polygon Fixes Validator Security Flaws With Austin And Kyoto Forks

• Polygon Labs activated the Austin and Kyoto hard forks to patch critical vulnerabilities in its Bor and Heimdall clients, utilizing a coordinated disclosure model to prevent exploitation.
• The upgrades resolved severe denial-of-service risks and validator resource exhaustion, requiring node operators to upgrade to specific client versions to maintain consensus.
• Polygon Labs confirmed no evidence of mainnet exploitation before the patches were deployed, but stale nodes fallen out of canonical consensus.
• The Austin fork capped gas consumption for state-sync events and removed unbounded transaction dependency fields to protect block processing integrity.
• The Kyoto hard fork introduced byte-level nesting checks for protobuf messages, preventing attackers from forcing validators into excessive decoding work.

Polygon Labs has publicly disclosed a set of previously private security vulnerabilities that could have disrupted its proof-of-stake network. The company revealed the flaws only after deploying fixes through the Austin and Kyoto hard forks . The vulnerabilities affected Polygon's Bor and Heimdall clients and included denial-of-service risks, validator resource exhaustion, and weaknesses in checkpoint and milestone processing . Polygon stated that it found no evidence the flaws were exploited on mainnet .

Bor serves as Polygon PoS's block-producing execution client, while Heimdall handles checkpointing and validator coordination. Flaws in either component directly affect how the chain reaches and records consensus . Polygon patched the vulnerabilities before publishing their technical details. This approach allowed developers to test the fixes and activate them without giving potential attackers advance warning . It follows the coordinated disclosure model widely used across the software industry and by major blockchain projects .

The most serious issue affected Heimdall, where a specially crafted transaction could force validators to perform excessive processing work . Such activity could have placed significant pressure on validators and potentially disrupted network operations . The Austin hard fork resolved two separate denial-of-service risks in Bor . These flaws could have slowed block processing or caused affected nodes to crash .

How Did The Austin Hard Fork Improve Network Stability?

The Austin hard fork activated at block 91,949,700, requiring Bor version 2.10.0 or higher . It addressed two resource-exhaustion risks in the execution layer . State-sync events from L1-to-L2 bridge deposits were previously uncounted against gas limits, potentially stalling block processing . Austin caps this gas consumption to prevent these events from exhausting processing resources .

A separate weakness involved the TxDependency extra-data field, which had no size limit . Block producers could exploit this to crash peers with oversized blobs . Austin caps this gas and removes the field from the wire format entirely . These changes ensure that block processing remains efficient and resistant to resource exhaustion attacks .

What Security Improvements Did The Kyoto Fork Introduce?

The Kyoto fork activated at Heimdall height 51,533,000, requiring Heimdall version 0.11.0 or higher . Its highest-severity fix targets deeply nested google.protobuf.Any messages . These messages allowed attackers to force validators into heavy decoding work at low cost . Kyoto introduces byte-level nesting checks at both mempool admission and block-proposal processing .

Additional fixes normalize checkpoint signature recovery and cap fee-coin lists . The changes make replay keys injective to prevent silent event shadowing . Both hard forks are straightforward binary upgrades with no state migration or genesis changes . Nodes that have not diverged do not need to resync, but operators on outdated clients must upgrade .

Why Are Immediate Client Upgrades Mandatory For Operators?

The disclosure underscores the importance of coordinated security responses for blockchain networks . Although Polygon avoided a confirmed mainnet exploit in this case, the vulnerabilities could have threatened network availability . The Austin and Kyoto upgrades therefore served a dual purpose as security patches and critical maintenance steps . The upgrades created an immediate requirement for node operators to maintain consensus .

Nodes running older client versions past the relevant activation heights have fallen out of consensus . They must upgrade to reconnect with the canonical Polygon network . Polygon requires Bor v2.10.0 for Polygon PoS nodes, while validators and full nodes must also run Heimdall v0.11.0 . Both versions are already active on mainnet .

The disclosure came only after the fixes were successfully deployed, reducing the risk that public vulnerability details could be used against unpatched nodes . The upgrades land as Polygon's validator community absorbs the shift from MATIC to POL and ongoing discussion of staking reform . The network remains heavily used, hosting assets such as PayPal's PYUSD stablecoin, raising the stakes for keeping node software current. Independent researchers identified the flaws, with one tied to a $2.2 million bounty. Node operators must install the applicable releases to resume participation in the canonical chain .