Polygon Labs has published details of multiple security vulnerabilities that could have threatened the reliability of its Proof-of-Stake (PoS) network—after fixing the issues via two recent hard forks and then disclosing the underlying risks.

According to a Thursday disclosure posted by Polygon Labs’ Validators Support Team, the flaws impacted the network’s Bor and Heimdall clients and ranged from denial-of-service (DoS) vectors to bugs that could interfere with validator and checkpoint-related processing.

Key takeaways

• Polygon disclosed security issues affecting both Bor and Heimdall clients, including DoS risks and validator resource exhaustion.
• The fixes were delivered through two hard forks—Austin for Bor and Kyoto for Heimdall—and were tested before activation on mainnet.
• Polygon said it has seen no evidence of the vulnerabilities being exploited on mainnet.
• After the hard fork activation heights, nodes running older client versions will fall out of consensus and must upgrade to rejoin the canonical chain.
• Upgrades are already live on mainnet: Bor v2.10.0 for PoS nodes and Heimdall v0.11.0 for validators and full nodes.

What Polygon disclosed: Bor and Heimdall risks

In its security release, Polygon described vulnerabilities that could have disrupted network operation by increasing the amount of work validators and other components had to perform, potentially leading to slowdowns or instability.

The disclosure states that Heimdall carried the most severe issue. Polygon said that a specially crafted transaction could compel validators to carry out excessive processing work, creating a realistic possibility of network disruption.

For Bor, Polygon’s disclosure highlights two separate denial-of-service risks addressed by the Austin hard fork. While the release does not expand on every implementation detail in the summary provided, it characterizes the potential impact as slowing block processing or causing nodes to crash—outcomes that can degrade throughput and availability in a validator-driven system.

Alongside these issues, Polygon also pointed to flaws tied to checkpoint and milestone processing. These components are important in PoS systems that must consistently advance state and maintain coordination across epochs and consensus-critical milestones. Errors in those flows can create cascading failures if left unpatched.

How Polygon rolled out the fixes

Polygon said the vulnerabilities were addressed through two hard forks: Austin for the Bor client and Kyoto for Heimdall. The company added that the updates were deployed privately first, with testing before activation on mainnet, and that the details were made public only after the network upgrades were already in place.

Crucially for operators, Polygon indicated that none of the disclosed vulnerabilities had been observed being exploited on mainnet. The report frames the disclosure as a proactive measure—Polygon says it pushed the fixes before publishing the full technical details.

Upgrade requirements: staying in consensus after activation

Polygon also made the practical implications explicit: nodes that continue running older versions of either client past the hard fork activation heights will no longer be in consensus with the canonical network.

To avoid being cut off from the main chain, Polygon said that:

• Bor v2.10.0 is required for all Polygon PoS nodes.
• Heimdall v0.11.0 is required for validators and full nodes.

Polygon further stated that both upgrades are already active on mainnet, meaning operators who haven’t updated need to act promptly to ensure their infrastructure remains compatible with the post-fork network rules.

Why this matters for PoS operators and users

Hard forks can feel disruptive even when they’re planned, but this disclosure underscores a different dimension of PoS security: availability and resource pressure are not theoretical. Heimdall’s described transaction-based forcing of excessive validator work highlights how adversaries can sometimes target compute limits rather than attempting to directly rewrite or steal consensus control.

Similarly, Bor DoS risks—ranging from block processing slowdowns to potential node crashes—suggest that operational stability depends on more than just validator correctness. A network can degrade even if the core consensus mechanism remains intact, simply by overwhelming nodes with workload or triggering instability.

For end users, these incidents mostly affect the system indirectly through reliability: delays, degraded performance, or node downtime can reduce how smoothly transactions propagate and are confirmed. For validators and infrastructure providers, the key takeaway is more immediate: compatibility after hard fork activation is mandatory, and the disclosed issues increase the importance of keeping client software current.

Token performance remains separate from the engineering update

At the time of writing, Polygon’s native token, POL—formerly known as MATIC—was trading around $0.10, down about 4% over the past week but up 44% over the past month and 2.3% year to date, based on CoinGecko data.

Readers should watch next for validator/operator confirmations that post-fork upgrades are stable across the network—especially because Polygon’s disclosure emphasizes resource exhaustion and processing-path bugs that, even if not exploited, are the kinds of issues that can surface as infrastructure strain under load.

Polygon has published details of multiple previously undisclosed security vulnerabilities that could have affected its proof-of-stake (PoS) infrastructure, including issues spanning node-to-node denial-of-service risk and validator processing bottlenecks. Polygon said the problems were addressed ahead of public disclosure through two recent hard forks and corresponding client upgrades.

In a Thursday post on the Polygon forum, Polygon Labs’ Validators Support Team outlined how flaws in the Bor and Heimdall clients were fixed via the Austin and Kyoto hard forks. The disclosure also notes that none of the vulnerabilities have been observed exploited on Polygon mainnet.

Key takeaways

• Polygon disclosed vulnerabilities affecting both Bor and Heimdall clients, with potential denial-of-service and validator processing disruption.
• The issues were reportedly resolved through Austin (Bor) and Kyoto (Heimdall) hard forks, which were tested before activation.
• Polygon stated that no exploitation was observed on mainnet, and upgrades were deployed proactively before details became public.
• Running outdated client versions after hard fork activation heights means nodes will fall out of consensus and must upgrade to rejoin.
• Polygon requires Bor v2.10.0 for PoS nodes and Heimdall v0.11.0 for validators and full nodes.

What Polygon disclosed about the Bor client

According to Polygon’s disclosure, the Austin hard fork addressed two denial-of-service related risks tied to the Bor client. Denial-of-service flaws in blockchain clients are particularly concerning because they can degrade performance by increasing resource consumption during block handling, and in severe cases could contribute to node instability.

Polygon said these Bor issues could have impacted block processing or caused nodes to crash, depending on how an attacker might have triggered the problematic behavior. Polygon did not state that the vulnerabilities were exploited in the wild, but emphasized that the fixes were deployed in advance of the public release of technical details.

The Heimdall vulnerability that could overload validator processing

The disclosure highlighted a more severe problem affecting the Heimdall client. Polygon said a specially crafted transaction could force validators to perform excessive processing work. In a PoS environment, anything that causes disproportionate workload on validators can become a network reliability issue, since validators must process consensus-related data within practical performance limits.

Polygon framed the Heimdall flaw as one that could potentially disrupt network operation by pushing validators into an inefficient or overly burdensome processing path. The issue was addressed through the Kyoto hard fork, with corresponding updates rolled out before the information was disclosed publicly.

Hard fork mechanics and why upgrades matter

Polygon’s disclosure is explicit about the operational consequences for participants who do not update. Nodes running older versions of either Bor or Heimdall past the relevant hard fork activation heights are described as falling out of consensus and needing to upgrade to return to the canonical network.

Polygon stated that Bor v2.10.0 is required for all Polygon PoS nodes, and Heimdall v0.11.0 is required for validators and full nodes. Both upgrades are reported as already active on mainnet.

For infrastructure operators, this means security preparedness is also a liveness requirement: even if a node is not directly affected by an attack scenario, outdated software can still become unable to participate in consensus after protocol changes. In practice, the operational takeaway is to confirm client versions are aligned with the post-fork requirements and monitoring is in place to catch missed upgrades.

No evidence of mainnet exploitation, but a reminder on proactive patching

Polygon said none of the vulnerabilities described in the disclosure were observed being exploited on mainnet. The company also characterized the fixes as proactive—implemented through hard forks and client upgrades before the detailed vulnerability information was released.

This approach matters because it reduces the window in which real-world attackers could attempt to take advantage of known weaknesses. However, it also raises the bar for ongoing maintenance: even when the attack surface is addressed through upgrades, participants must still keep pace with protocol and client version changes to maintain connectivity and consensus participation.

At the time of writing, Polygon’s native token (POL)—formerly known as MATIC—was trading around $0.10. CoinGecko data shows it was down about 4% over the previous week, up 44% over the past month, and up 2.3% year to date, according to CoinGecko’s price statistics.

Readers should watch for operational confirmations from validators and node operators that their Heimdall and Bor upgrades remain stable post-fork. The next practical question is whether Polygon will publish additional details or guidance on mitigation practices beyond the required version upgrades—especially given that denial-of-service and validator workload vulnerabilities can be sensitive to implementation changes and monitoring thresholds.