Security

Polygon Quietly Patched Critical Network Vulnerabilities in Two Hard Forks

2026-08-30

Polygon has disclosed several previously private security vulnerabilities that could have disrupted its proof-of-stake network, after deploying fixes through two recent hard forks named Austin and Kyoto. No exploits occurred on mainnet. The flaws were addressed without operational disruption, but they're worth understanding—especially if you're running a validator node.

The vulnerabilities affected Polygon's Bor and Heimdall clients. Bor is the execution client; Heimdall handles consensus and checkpointing. The separation of functions across two clients meant vulnerabilities in either could cascade through the network. Think of it as two critical systems that depend on each other—a flaw in one propagates to both.

Three distinct attack vectors emerged. First: Heimdall faced a denial-of-service risk where a specially crafted transaction could force validators to perform excessive processing work. Denial-of-service attacks on proof-of-stake systems are classical vectors. Attackers exploit computational or memory requirements to overwhelm network participants. This wasn't theoretical.

Second and third: Bor had two separate denial-of-service risks that could have slowed block processing or crashed nodes entirely. The most interesting one involved state-sync events from Polygon's L1-to-L2 bridge deposits. These events execute contract code and precompiles—but their gas consumption wasn't previously counted against a fixed block-level ceiling. Enough events, or one sufficiently expensive event, could make block processing slow enough to stall the chain transiently. It's a specific implementation gap: the bridge deposits interacted with the execution layer's resource constraints in ways nobody had properly capped.

Polygon Labs' Validators Support Team identified and fixed these issues before public disclosure. The Austin hard fork targeted Bor's risks; the Kyoto hard fork targeted Heimdall's. Both were deployed privately, tested, then activated on mainnet before details went public. This is how security patches should work. Node operators got advance notice. No chaos. No exploit-in-the-wild scenarios.

The hard fork activations imposed strict version requirements. Bor versions earlier than v2.10.0 became incompatible after Austin activated at mainnet block 91,949,700. Heimdall validators and full nodes need v0.11.0 after Kyoto activated at height 51,533,000. Nodes running older versions past those activation heights have already fallen out of consensus. They can't rejoin without upgrading.

What stands out here is the proactive approach. Polygon's security team identified and remediated these attack surfaces before they could be weaponised. They didn't wait for external researchers to disclose findings or for exploits to surface in the wild. Continuous security auditing and adversarial testing within protocol development teams matter. Historical incidents across blockchain networks show what happens when similar vulnerabilities go undetected until exploitation occurs. Polygon didn't repeat that mistake.

If you're running a Polygon validator or full node, you've already upgraded or you're not seeing blocks. That's the entire point of the hard fork mechanism: mandatory consensus enforcement. The network moved on without breaking stride.

Source & further reading:

Sources