Polygon Disclosed Bor and Heimdall Vulnerabilities Only After Quietly Patching Them via Austin and Kyoto Hard Forks

Two hard forks quietly went live on Polygon’s proof-of-stake network in recent weeks, and only after both were safely running on mainnet did Polygon Labs reveal what they were actually fixing: a set of vulnerabilities in the network’s core client software that, left unpatched, could have let an attacker disrupt block production or force validators into a processing meltdown.

Deploy first, disclose after

The two upgrades, named Austin and Kyoto, were built, tested and activated on mainnet before Polygon Labs published any detail about what they contained. That sequencing is deliberate: publishing a vulnerability before the fix is live would hand attackers a roadmap to exploit it. Bor, Polygon’s execution client, required an upgrade to v2.10.0 once Austin activated at mainnet block 91,949,700, while Heimdall, the network’s consensus layer, needed v0.11.0 once Kyoto activated at height 51,533,000. Nodes still running older versions of either client have already fallen out of consensus and need to upgrade to rejoin the network.

What was actually broken

The most severe issue lived in Heimdall: a specially crafted transaction could force validators to burn excessive computing resources processing it, a denial-of-service vector that could have disrupted consensus finalization across the network if exploited at scale. Separately, Austin’s fixes addressed two distinct denial-of-service risks in Bor that could have slowed block processing or crashed nodes outright. Polygon Labs also flagged additional flaws affecting validator resource exhaustion and the checkpoint and milestone processing that ties Polygon’s state back to Ethereum.

No evidence of exploitation

Polygon Labs’ validators support team said none of the disclosed vulnerabilities were observed being exploited on mainnet before the patches shipped, framing the entire episode as proactive hardening rather than incident response. That distinction matters: this wasn’t a breach that got cleaned up afterward, but a case of the network’s security researchers finding the cracks before anyone else did and closing them quietly.

Why silent patching is standard practice, not a cover-up

Responsible disclosure in blockchain infrastructure almost always follows this pattern — coordinate the fix, deploy it network-wide, confirm adoption, and only then explain what was wrong. Announcing a live vulnerability before validators have upgraded would effectively broadcast an attack plan to anyone watching. For a network that still secures billions of dollars in value across its proof-of-stake bridge and application layer, the multi-week gap between private patching and public disclosure represents the industry’s accepted trade-off between transparency and security. The bigger takeaway for node operators and validators is procedural: staying current with client releases isn’t optional maintenance, it’s the only way to actually benefit from fixes like these before details go public.

This article is for informational purposes only and does not constitute financial or technical advice. Always run supported, up-to-date client software when operating blockchain infrastructure.

Want to learn more about how blockchain networks handle upgrades and security? Explore Coin680’s Bitcoin Academy.