Polygon Fortifies Network with Austin, Kyoto Hard Forks
CHSB
+0.10%
KCS
+0.55%
XMR
+2.65%
ELF
-5.95%
Polygon has quietly deployed two hard forks, Austin and Kyoto, to patch critical security vulnerabilities within its proof-of-stake network. Both updates rolled out before public disclosure, addressing denial-of-service risks and a validator overload flaw. The move highlights Polygon’s proactive approach to network resilience, even as its native token, POL, trades near $0.10 amid broader market softness.

Two Clients, Two Separate Fixes

The Polygon Labs Validators Support Team confirmed the fixes in a recent forum post. The Austin hard fork targeted vulnerabilities in the Bor client, while the Kyoto hard fork addressed a separate issue in the Heimdall client.

Polygon says no exploitation occurred on mainnet before either patch went live. Deploying the fixes proactively, ahead of public disclosure, minimized the window during which an attacker could have acted on the information.

  • Bor client (Austin fork): Fixed denial-of-service risks that could degrade node performance or cause crashes by driving up resource consumption during block handling
  • Heimdall client (Kyoto fork): Fixed a flaw where a specially crafted transaction could force validators into excessive processing, threatening consensus operations

The Heimdall issue was the more severe of the two, since validators depend on efficiently processing consensus data to keep the network functioning. A transaction designed to overload that process could have disrupted operations across the board rather than affecting isolated nodes.

Node Operators Need to Upgrade Now

Both fixes are already active on Polygon’s mainnet, which makes upgrading a liveness requirement, not just a security best practice. Running outdated client software will cause nodes to fall out of sync with the network.

Polygon requires Bor v2.10.0 for proof-of-stake nodes and Heimdall v0.11.0 for validators and full nodes. Operators should confirm their client versions align with these post-fork requirements immediately, since consensus depends on it.

The pattern here reduces immediate attack surface risk, but it also puts the burden on node operators to stay current. Missing a mandatory upgrade window doesn’t just create a security gap, it knocks a node out of sync entirely.

Follow Hashlytics on Bluesky, Facebook, LinkedIn , Telegram and X to Get Instant Updates

Disclaimer: Content displayed above are for informational purposes only and do not constitute financial, investment, or trading advice.