Polygon reveals security issues with recent hard fork fixes

Polygon Labs discloses details of security vulnerabilities recently fixed through hard forks

Polygon Labs has released details of multiple security vulnerabilities that may have threatened the reliability of its Proof-of-Stake (PoS) network. Details were made public after two recent hard forks were used to fix problems and disclose potential risks.

According to an announcement released Thursday by the Polygon Labs verifier support team, the vulnerabilities affect the network's Bor and Heimdall clients and involve everything from denial of service (DoS) vectors to errors that could interfere with verifier and checkpoint related processing.

Core Points

Polygon disclosed security issues affecting Bor and Heimdall clients, including DoS risks and verifier resource depletion risks. The fix was implemented through two hard forks-the Austin fork for Bor and the Kyoto fork for Heimdall-and was tested before the main network was activated. Polygon said it had not found evidence that the vulnerabilities were being exploited on the main network. After a hard fork activation level, nodes running older versions of clients will be out of consensus and must be upgraded to rejoin the specification chain. The upgrade is already available on the main network: PoS nodes need to use Bor v2.10.0, and Verifier and full nodes need to use Heimdall v0.11.0.

Polygon Disclosure: Bor and Heimdall Risks

In a security bulletin, Polygon described the vulnerabilities as potentially disrupting network operations by increasing the workload of verifiers and other components, causing slowdowns or instability. The announcement pointed out that Heimdall has the most serious problems. Polygon said a carefully constructed transaction could force a validator to perform too much processing work, creating the real possibility of network outages. For Bor, Polygon's announcement highlighted two separate denial-of-service risks addressed by Austin's hard fork. Although the announcement did not detail every implementation detail in the summary provided, it described potential impacts as slowing block processing or causing node crashes-consequences that could reduce the throughput and availability of verifier driven systems. In addition, Polygon pointed out deficiencies related to checkpoint and milestone handling. These components are critical in a PoS system, which must continue to advance and maintain coordination between different periods and consensus key milestones. If errors in these processes are not fixed, cascading failures can occur.

How Polygon deploys fixes

Polygon said the vulnerabilities were resolved through two hard forks: the Austin fork for the Bor client and the Kyoto fork for Heimdall. The company added that the update was first deployed privately, tested before the main network was activated, and the details were made public only after the network upgrade was completed. Crucial to operators, Polygon said it had not observed any disclosed vulnerabilities being exploited on the main network. The report positioned the disclosure as a precautionary measure-Polygon said it had pushed a fix before releasing full technical details.

Upgrade requirements: Maintain consensus after activation

Polygon also clarifies the practical impact: Nodes that continue to run older versions of any client beyond the hardfork activation level will no longer maintain consensus with the regulated network. To avoid disconnection from the main chain, Polygon stated that all Polygon PoS nodes must use Bor v2.10.0, and verifiers and full nodes must use Heimdall v0.11.0. Polygon further stated that two upgrades have been activated on the main network, which means operators that have not yet updated need to act immediately to ensure their infrastructure is compatible with post-fork network rules.

What this means for PoS operators and users

Even a planned hard fork may be inconvenient, but the disclosure highlights another dimension of PoS security: Availability and resource pressures are not theoretical issues. The overwork of a transaction-based forced verifier described in Heimdall suggests that attackers may sometimes target computing limitations rather than trying to directly override or steal consensus control. Similarly, Bor's DoS risk-ranging from slowing block processing to potential node crashes-suggests that operational stability depends more than just on the correctness of the verifier. Even if the core consensus mechanism remains unchanged, the network may degrade due to excessive node workload or instability. For end users, these events affect the system indirectly mainly through reliability: delays, performance degradation, or node downtime can reduce the smoothness of transaction propagation and confirmation. For verifiers and infrastructure providers, the key revelation is more direct: compatibility after hard fork activation is mandatory, and the issues disclosed highlight the importance of keeping client-side software updated.

Token performance has nothing to do with engineering updates

As of writing, Polygon's native token POL (previously known as MATIC) is trading at approximately US$0.10, down approximately 4% in the past week, but up 44% in the past month and 2.3% year-to-date.

Readers should pay attention to validator/operator confirmations to ensure that post-fork upgrades operate stably across the network-especially since Polygon's disclosures highlight resource exhaustion and processing paths that, even if they are not utilized, can manifest themselves as infrastructure stress under load pressure.