Polygon (Old)

Security

<p>Polygon Labs has disclosed a series of security vulnerabilities that, if exploited, could have seriously disrupted its proof-of-stake network. The flaws were quietly patched through two hard forks before any details were made public, a deliberate sequencing intended to prevent bad actors from acting on the information before fixes were in place.</p>
<h2 id="what-the-vulnerabilities-involved">What the Vulnerabilities Involved</h2>
<p><cite>The vulnerabilities affected Polygon's Bor and Heimdall clients and included denial-of-service risks, validator resource exhaustion, and flaws affecting checkpoint and milestone processing, according to a disclosure from Polygon Labs' Validators Support Team.</cite></p>
<p><cite>The most severe issue involved Heimdall, where a specially crafted transaction could force validators to perform excessive processing work, potentially disrupting the network.</cite> On the Bor side, the problems were equally concerning. <cite>L1-to-L2 state-sync events were effectively un-metered, meaning they could consume block resources without the gas accounting that normally limits runaway computation. The Austin fork introduced per-block gas bounds to cap that exposure.</cite><cite>A second issue involved unbounded TxDependency data, a structure Bor uses internally to track transaction ordering. Without limits on how large that structure could grow, a crafted input could stall block processing or crash connected peers entirely.</cite></p>
<h2 id="how-polygon-responded">How Polygon Responded</h2>
<p><cite>Polygon Labs patched the vulnerabilities through two hard forks, Austin on its Bor client and Kyoto on Heimdall, rolled out privately and validated on testnet before mainnet activation.</cite><cite>The fixes landed in the Austin and Kyoto upgrades, which activated on the Polygon proof-of-stake mainnet on August 29, with a community forum post describing the technical details following two days earlier.</cite></p>
<p><cite>None of the vulnerabilities were observed being exploited on mainnet, according to Polygon, which said the fixes were deployed proactively before details were made public.</cite> The approach reflects a recognised best practice in blockchain security: disclosing vulnerabilities only after patches are live reduces the window during which attackers could act on public information.</p>
<p>The hard forks carry an immediate practical requirement for node operators. <cite>Polygon PoS nodes must upgrade to Bor v2.10.0, while validators and full nodes must move to Heimdall v0.11.0.</cite><cite>After the hard fork activation heights, nodes running older client versions will fall out of consensus and must upgrade to rejoin the canonical chain.</cite></p>
<p><strong>Sources:</strong><br><a href="https://cointelegraph.com/news/polygon-discloses-security-flaws-fixed-in-recent-hard-forks" rel="noopener noreferrer nofollow">Cointelegraph: Polygon Patches DoS Risks in Austin, Kyoto Hard Forks</a><br><a href="https://decrypt.co/376911/polygon-quietly-patched-security-flaws" rel="noopener noreferrer nofollow">Decrypt: Polygon Quietly Patched Security Flaws in Two Hard Forks Before Disclosing Them</a><br><a href="https://cryptobriefing.com/polygon-austin-kyoto-hard-forks-security-fixes/" rel="noopener noreferrer nofollow">Crypto Briefing: Polygon Discloses Security Flaws Fixed in Austin and Kyoto Hard Forks</a></p>

Polygon Patches Serious Network Security Flaws

Table of Contents

BSCN

Other articles published on Aug 31, 2026

Join our free newsletter for daily crypto updates!