Polygon Austin and Kyoto Security Fixes: What Was Vulnerable and Why Node Upgrades Are Mandatory

Polygon has publicly documented a set of Polygon PoS security and liveness issues only after the fixes were deployed and validated.

The vulnerabilities were addressed through two coordinated hard forks:

• Austin — Bor v2.10.0
• Kyoto — Heimdall v0.11.0

Polygon says both releases were first rolled out privately, validated on the Amoy testnet and made public after mainnet activation once the fleet was considered safe.

The project also says the disclosed issues were not observed causing disruption on mainnet.

This is therefore not an active exploit article. It is a patched security-disclosure and mandatory-upgrade event.

Why Private Rollout Was Reasonable

Consensus and liveness vulnerabilities create a disclosure problem.

If maintainers publish exploit details before most validators and nodes have upgraded, the disclosure itself can create an attack window.

Polygon’s approach was to develop fixes, roll them out privately, validate them on Amoy, activate them on mainnet and publish technical detail afterward.

That is a standard coordinated-disclosure pattern for vulnerabilities that could affect block processing or validator behavior.

Austin / Bor v2.10.0: State-Sync Gas Exhaustion

The first Austin issue involved state-sync events.

State-sync events can execute contract code and precompiles similarly to normal transactions, but the gas they consumed was not bounded by a hard per-block cap.

Polygon says a block carrying enough state-sync events, or one particularly expensive event, could take long enough to process that the chain transiently stalls.

Austin adds an explicit per-block state-sync gas bound, aligning the resource constraint more closely with ordinary transaction-gas treatment.

The risk was availability rather than unauthorized asset transfer.

Austin: Unbounded TxDependency Data

The second Bor issue involved the TxDependency wire field, used as a hint for parallel transaction execution.

The field had no size limit.

A malicious block producer could therefore include an arbitrarily large TxDependency blob in an otherwise valid sibling block. A peer receiving the block could crash while trying to process the oversized data.

Austin removes the field from the wire format.

Polygon says parallel execution does not depend on peers trusting the producer’s hint for correctness, so removing it does not break execution semantics.

Austin Activation

Polygon lists:

• Amoy activation: block 44,120,000
• Mainnet activation: block 91,949,700

Polygon classifies both Bor issues as resource-exhaustion / denial-of-service paths, not consensus-correctness failures, and says neither was observed disrupting mainnet.

Kyoto / Heimdall v0.11.0: Nested Protobuf Any

The most severe Kyoto item involved deeply nested google.protobuf.Any fields.

Heimdall transactions wrap inner messages in Any, and Any can itself contain nested Any structures.

Without a depth cap, an attacker could construct a transaction cheaply but force every validator to perform expensive decoding work at the same time.

That asymmetry is dangerous: low attacker cost, correlated network-wide validator cost.

Kyoto adds a byte-level pre-scan that rejects a transaction once nesting exceeds a threshold.

Polygon says the same rule is enforced at both mempool admission (CheckTx) and the consensus path (ProcessProposal), preventing different treatment of the same transaction across those paths.

Kyoto: Unbounded Fee-Coin List

A transaction could previously declare an unbounded list of fee coins.

Validation scanned the list with O(n) work.

Kyoto adds a cap before the scan, reducing the ability to create disproportionate validator work using oversized input structures.

Kyoto: Checkpoint-Signature Normalization

Polygon also fixed a checkpoint-signature edge case.

The recovery byte was not canonicalized before submission to L1. A correctly signed checkpoint could therefore be presented in a form that failed signature recovery on L1.

The result could be a stall in checkpoint anchoring without an attacker needing to forge a valid signature.

This is a liveness/finality problem, not a private-key theft problem.

Kyoto: Milestone, Downtime and Replay Hardening

The release also includes:

• idempotent producer-downtime handling;
• milestone-range voting tied to the signed parent hash;
• checkpoint-window continuity checks;
• non-halting future-span creation;
• injective replay keys for certain L1 events, avoiding a narrow collision case where one event could shadow another.

Individually, several are edge cases. Together they harden the machinery linking Polygon PoS validation, milestones, checkpoints and Ethereum-facing events.

Kyoto Activation

Polygon lists:

• Amoy: height 42,252,000
• Mainnet: height 51,533,000

The project says all fixes were resolved and validated before activation.

What Node Operators Must Run

Polygon’s guidance is unambiguous:

These are binary upgrades without a state migration or genesis change.

Polygon warns that a node still on an older version beyond the activation height has already fallen out of consensus. It must upgrade and catch up to rejoin the canonical network.

Why the Event Is Medium, Not High

There is no reported mainnet exploitation.

The fixes were deployed before the technical details became public.

There is no confirmed customer-asset loss.

Those facts lower severity.

However, the affected code sat in block-processing and validator/consensus-adjacent paths. A successful exploit could have degraded availability or created expensive correlated work across validators.

For operators still running stale software, the issue is operationally serious.

Evidence Status

Confirmed by Polygon

• Austin and Kyoto addressed security and liveness issues.
• Fixes were privately deployed and tested before public disclosure.
• Austin fixed two Bor DoS paths.
• Kyoto fixed multiple Heimdall consensus/input-validation issues.
• No disclosed issue was observed causing mainnet disruption.
• Bor v2.10.0 and Heimdall v0.11.0 are mandatory.
• Old nodes past activation heights have forked off canonical consensus.

No evidence found

• Active exploitation of the disclosed vulnerabilities.
• Direct customer-asset theft caused by these flaws.

Risk Assessment

Medium.

The vulnerabilities were real and consensus-adjacent, but they were patched before public disclosure and no mainnet exploitation was observed.

What to Watch Next

1. Whether operators continue reporting stale nodes.
2. Additional CVE/security-advisory detail.
3. Independent audits of the affected paths.
4. Operational instability after upgrades.
5. Similar vulnerabilities in Polygon-derived or forked codebases.
6. Whether Polygon formalizes new limits for other unbounded input structures.

FAQ

Was Polygon hacked?

Polygon says the disclosed vulnerabilities were not observed causing mainnet disruption and does not report an exploit or asset theft tied to them.

What does Austin fix?

Austin fixes two Bor denial-of-service paths: unbounded state-sync gas per block and an unbounded TxDependency wire field.

What does Kyoto fix?

Kyoto hardens Heimdall against nested-message resource exhaustion, unbounded fee-coin lists, checkpoint/milestone edge cases and L1 event replay issues.

Which versions are mandatory?

Bor v2.10.0 and Heimdall v0.11.0.

What happens if a node did not upgrade?

Polygon says nodes remaining on older versions past activation have already forked off the canonical chain and need to upgrade and catch up.