Купить крипто Рынки Спот ФьючерсыBTC Сбережения Центр событий Хаб наград

Еще

A blockchain does not necessarily need to lose hundreds of millions of dollars to be considered the victim of a serious security issue.Sometimes, an attacker’s objective is much simpler:Do not steal aA blockchain does not necessarily need to lose hundreds of millions of dollars to be considered the victim of a serious security issue.Sometimes, an attacker’s objective is much simpler:Do not steal a

Polygon Patches Multiple Vulnerabilities Through Austin and Kyoto: An Incident That Never Happened but Reveals the Risks of High-Performance Blockchains

Автор: Nguyen Rin Hoang

2026/08/31 11:56

A blockchain does not necessarily need to lose hundreds of millions of dollars to be considered the victim of a serious security issue.

Sometimes, an attacker’s objective is much simpler:

Do not steal assets → overload validators → cause nodes to crash → slow down or halt transaction processing.

That is exactly the category of risk Polygon has quietly addressed.

On August 27, 2026, Polygon disclosed details of multiple vulnerabilities affecting two important components of Polygon PoS: Bor and Heimdall. The issues had already been patched through the Austin and Kyoto hard forks before the technical details were made public.

Austin focused on two denial-of-service attack paths in Bor that could slow block processing or cause nodes to crash.

Kyoto addressed a broader set of issues in Heimdall, with the most notable being the ability for a specially crafted transaction to force the entire validator set to perform a large amount of decoding work.

Polygon said it had not observed these vulnerabilities being exploited on mainnet.

Therefore, this was not a post-mortem following an exploit.

It is instead a notable example of:

Discover vulnerability → patch privately → hard fork → protect validators → disclose afterward.

But the event also raises a broader question:

As blockchains become more complex and increasingly optimized for performance, does their attack surface also become larger?

Key Takeaways

Polygon patched multiple security and liveness issues through Austin and Kyoto.

Austin upgraded Bor to v2.10.0 and addressed two denial-of-service attack paths.

Kyoto upgraded Heimdall to v0.11.0 and addressed multiple consensus and input-validation issues.

The most notable vulnerability could force validators to perform large amounts of computation from a relatively inexpensive crafted transaction.

The issues primarily threatened network availability/liveness, rather than directly allowing an attacker to steal POL or user assets.

Polygon deployed and tested the patches before publicly disclosing the vulnerability details.

No exploitation of these vulnerabilities has been observed on mainnet.

Nodes that failed to upgrade after the activation height fell out of canonical consensus.

The event highlights validator resource exhaustion as an important security risk that often receives less attention than smart-contract exploits.

Austin and Kyoto also illustrate the trade-off between performance, complexity, and security in blockchain systems.

First: What Are Bor and Heimdall?

To understand the seriousness of these vulnerabilities, it is necessary to understand the architecture of Polygon PoS.

Polygon does not run on a single piece of software.

Two important components are:

Bor

and

Heimdall.

Bor is the execution client of Polygon PoS.

It is responsible for tasks related to:

Transaction execution

Block processing

EVM state

and other execution-related activities.

Heimdall, meanwhile, handles functions more closely related to validator coordination, checkpoints, milestones, and consensus-related processing.

A simplified model looks like:

Transactions → Bor → Execution

while:

Validators → Heimdall → Coordination / Checkpoint / Consensus-related processing.

Therefore, vulnerabilities on both sides create two different types of attack surface.

Austin addressed issues on the execution side.

Kyoto strengthened validator and consensus infrastructure.

What Did Austin Fix in Bor?

The Austin Hard Fork was deployed together with Bor v2.10.0.

Polygon said Austin addressed two denial-of-service paths related to block processing.

The first vulnerability involved state-sync events.

State sync is used to bring information from Ethereum L1 into Polygon, such as bridge deposits.

These events can execute contract code and precompiles similar to ordinary transactions.

But before Austin, there was a problem:

state-sync gas consumption was not constrained by an appropriate hard cap at the block level.

This created the possibility of:

Many state-sync events

↓

Computation increases sharply

↓

Block processing takes longer

↓

The chain may temporarily stall.

Austin introduced a clear limit on the amount of state-sync gas that can be processed in each block.

Fundamentally, this is a resource accounting problem.

A blockchain must ensure that:

the amount of computation the network is required to perform corresponds to a controllable limit.

If an attacker can force the network to perform large amounts of computation at a disproportionately low cost, denial-of-service becomes a realistic possibility.

TxDependency: An Optimization Can Also Become an Attack Surface

The second vulnerability in Bor is even more interesting.

Bor previously contained a data field called TxDependency.

It was used as a hint for parallel execution, helping the system determine which transactions did not conflict so they could be processed more efficiently.

But the field had a problem:

it had no size limit.

A block producer could therefore theoretically place an extremely large TxDependency blob inside a block.

When another peer received the data:

Oversized TxDependency

↓

Peer attempts to process it

↓

Resource consumption increases

↓

Peer may crash.

Austin addressed the problem quite directly:

TxDependency was removed from the wire format.

The notable point is that TxDependency originally existed to support performance optimization.

But the optimization introduced additional:

Code

↓

State

↓

Input

↓

Attack surface.

This is a trade-off that appears frequently in blockchain engineering.

A Faster Blockchain Is Not Necessarily a Simpler Blockchain

High-performance blockchains always have to solve a difficult problem.

Users want:

High TPS

Fast finality

Low fees

Parallel execution

Fast bridging

High throughput.

But every optimization tends to make the system more complex.

For example:

Parallel execution

may require additional metadata.

Cross-chain state synchronization

requires additional event-processing logic.

Fast consensus

requires more complex validator coordination.

Every new component introduces another area of code where bugs can appear.

Security engineering is therefore not simply about asking:

“Can the smart contract be hacked?”

It also requires asking:

“Can malicious input cause the infrastructure to perform too much work?”

Austin is a clear example.

Kyoto Addressed an Even More Dangerous Problem

While Austin primarily focused on Bor, Kyoto targeted Heimdall.

Kyoto was deployed through Heimdall v0.11.0 and included multiple consensus-hardening and input-validation fixes.

The most notable vulnerability involved:

google.protobuf.Any.

A Heimdall transaction can wrap a message inside Any.

But Any itself can contain another Any.

In theory:

Any

↓

Any

↓

Any

↓

Any

↓

...

Without a limit on nesting depth, an attacker could create a transaction with an extremely deeply nested structure.

The problem is not necessarily how large the transaction is.

The problem is how expensive it is to decode.

A Cheap Transaction Can Create Expensive Computation

This is the most important security issue addressed by Kyoto.

An attacker can create a relatively inexpensive input.

But when validators process it:

Crafted transaction

↓

Deep nested messages

↓

Repeated decoding

↓

CPU workload increases

↓

Validator resource exhaustion.

The dangerous part is that the transaction is not processed by only one validator.

In a consensus network, many validators may be required to process the same input.

This creates a form of asymmetric attack:

Attacker cost: low

while:

Network cost: high.

This is one of the most dangerous characteristics of denial-of-service attacks.

A well-designed blockchain should attempt to maintain:

Attacker cost ≈ Network resource cost

or preferably:

Attacker cost > damage created.

If the relationship instead becomes:

Attacker cost << Validator cost

then the system creates an economic attack surface.

How Does Kyoto Fix the Problem?

Polygon added a byte-level nesting check.

Transactions exceeding the nesting threshold are rejected.

More importantly, the check is applied consistently across both:

Mempool admission — CheckTx

and

Consensus path — ProcessProposal.

This is extremely important.

If the mempool and consensus apply different validation rules, a situation could arise where:

Node A accepts

while:

Node B rejects.

For a blockchain, inconsistency in validation can sometimes be even more dangerous than the malicious transaction itself.

Kyoto therefore does more than reduce computation.

It ensures that multiple execution paths apply the same limit.

Kyoto Actually Fixed More Than One Vulnerability

Nested Any is the easiest issue to focus on, but Kyoto was much broader.

Polygon said the hard fork also added or fixed:

Fee-coin count cap

Checkpoint signature recovery-byte normalization

Producer-downtime handling

Milestone range voting

Checkpoint-window continuity

Future-span creation

L1 event replay keys.

The common theme across these changes is:

input validation + deterministic processing + consensus robustness.

In other words, Kyoto is better understood as a broader Heimdall hardening upgrade rather than a patch for a single bug.

Why Are Checkpoints and Milestones Important?

In Polygon PoS, Heimdall helps coordinate many activities related to validators and network state.

Checkpoints play an important role in anchoring Polygon information to Ethereum.

If checkpoint processing is disrupted, Polygon does not necessarily immediately lose all data or assets.

But the system’s ability to operate reliably can still be affected.

This illustrates an important principle:

Blockchain security ≠ only protecting private keys.

Security also includes:

Safety — the system does not accept an incorrect state.

and:

Liveness — the system continues making progress.

A blockchain may still preserve the correct state, but if it cannot create or process blocks normally, users still face serious problems.

Austin and Kyoto primarily address the second category.

A Vulnerability Can Be Serious Even Without Stealing Money

Crypto often evaluates security incidents by how much money was lost.

For example:

Bridge hack → $100M

Protocol exploit → $50M

Wallet drain → $20M.

But this approach overlooks another category of risk:

Network availability.

If an attacker can cause validators to crash or the network to stall, the consequences can include:

Transactions not being processed

DeFi operations being delayed

Oracle updates being affected

Bridge operations slowing down

Applications losing the ability to function normally.

Even if:

$0 is stolen.

For a blockchain that aims to become financial infrastructure, availability is also part of security.

Polygon Chose “Patch First, Disclose Later”

One aspect worth viewing positively is how Polygon handled disclosure.

According to Polygon, consensus-affecting fixes were:

Developed privately

↓

Rolled out privately

↓

Tested on Amoy

↓

Activated on mainnet

↓

Then the vulnerabilities were publicly disclosed.

The reason is straightforward.

If Polygon had publicly announced:

“Here is how to overload our validators.”

while most validators were still running vulnerable clients, the disclosure itself could have become instructions for attackers.

The team therefore reduced the exposure window before releasing technical details publicly.

This is a common responsible-disclosure approach for critical infrastructure.

But This Approach Also Creates a Trade-Off

Patching first and disclosing later helps protect the network.

But it also raises questions about transparency.

During the period before the vulnerabilities were disclosed:

Core developers knew

while:

the public did not fully understand the level of risk.

For blockchains, this creates an interesting tension between:

Transparency

and

Operational security.

Disclosing too early could expose the network to attack.

Disclosing too late makes it difficult for the community to assess the risks the system previously faced.

There is no perfect answer.

In the case of Austin and Kyoto, Polygon’s decision to disclose after the patches were active can be viewed as prioritizing the reduction of exploitation risk.

Hard Fork Does Not Mean the Blockchain “Split in Two”

The term “hard fork” sometimes makes users think of:

Ethereum → Ethereum Classic

or a community split.

Austin and Kyoto were not that kind of event.

They were protocol/client upgrades involving consensus changes.

Nodes had to upgrade their software to continue following the canonical network.

Polygon said:

Bor < v2.10.0

and

Heimdall < v0.11.0

would no longer remain compatible with canonical consensus after their respective activation heights.

So in this case, a hard fork was more like:

mandatory network software upgrade

than:

community split.

What Happens if Validators Do Not Upgrade?

This is another important point.

Austin activated at Bor mainnet block:

91,949,700.

Kyoto activated at Heimdall mainnet height:

51,533,000.

Nodes that continued running older binaries after those heights fell out of canonical consensus.

This shows that a blockchain security patch is not the same as updating a normal application.

If a user does not update a browser, they can usually continue using the old version.

A validator running outdated consensus software may:

no longer agree with the network.

Validator coordination is therefore an important part of incident response.

This Is Also a Test of Polygon’s Response Capability

When evaluating a blockchain, users often look at:

TPS

TVL

Stablecoin volume

Fees

Active addresses.

But one metric receives much less attention:

Security response capability.

Bugs can almost never be completely eliminated from a complex software system.

A more realistic question is:

How quickly is the bug discovered?

How quickly is the patch developed?

How quickly do validators upgrade?

Does the network experience downtime?

Can the attacker exploit the vulnerability before the patch?

In the case of Austin and Kyoto, Polygon said the vulnerabilities were addressed before public disclosure and that no mainnet exploitation had been observed.

That is a positive outcome.

But That Does Not Mean the Vulnerabilities Were Insignificant

There is also an opposite misinterpretation:

“No money was lost, so there was no problem.”

That is also incorrect.

A vulnerability allowing relatively inexpensive input to force validators into large amounts of computation is a serious architectural issue.

Especially if the attack could affect many validators simultaneously.

What Polygon avoided this time was:

vulnerability → exploitation → outage.

But the vulnerability still existed before the patch.

The event is therefore both a positive signal about incident response and a reminder of Polygon PoS’s attack surface.

Austin and Kyoto Highlight the Importance of Resource Metering

If there is one common theme across the most significant issues, it is:

Bounded computation.

Bor:

State-sync computation needs a gas bound.

Bor:

TxDependency needs a size bound or should be removed.

Heimdall:

Nested Any needs a depth bound.

Heimdall:

Fee coin lists need a count cap.

All of these revolve around one principle:

Externally controlled input must not be allowed to cause unlimited or disproportionate network resource consumption.

This can be summarized as:

Untrusted input + Unbounded processing = DoS risk.

This is not only a lesson for Polygon.

It is a fundamental principle of distributed systems.

Performance and Security Always Involve Trade-Offs

Polygon is pursuing a system with:

low fees

fast transactions

high throughput

Ethereum compatibility.

To achieve this, the network must introduce multiple layers of optimization and infrastructure.

But:

More optimization

→ More complexity

→ More edge cases

→ Potentially larger attack surface.

This does not mean blockchains should stop optimizing.

It means every optimization needs to be accompanied by:

resource bounds

fuzz testing

formal reasoning

security audits

bug bounty

incident response.

Austin and Kyoto show that the security of a high-performance blockchain is an ongoing process rather than a completed state.

Impact on Polygon PoS

In the short term, the direct impact is relatively limited because the vulnerabilities were patched before disclosure.

There is no public evidence of:

Mainnet exploitation

User funds being stolen

or direct asset losses caused by these issues.

Over the long term, the event can be viewed in two ways.

Positive:

Polygon discovered and patched the vulnerabilities before exploitation.

Validator coordination worked.

The hard forks were deployed.

Mainnet continued operating.

Negative:

The vulnerabilities show that execution and consensus clients still contain edge cases capable of affecting network liveness.

The biggest impact may therefore be on the assessment of engineering quality and security processes, rather than direct token economics.

What Do Austin and Kyoto Mean for POL?

It would be too simplistic to conclude:

Security patch → POL price rises.

Or:

Vulnerability disclosure → POL price falls.

Token prices are influenced by many factors.

From a fundamental perspective, validator infrastructure security is more important.

POL plays a role in Polygon’s staking and security system.

If Polygon wants POL to function as the economic asset securing the ecosystem, the underlying infrastructure must maintain:

Reliable consensus

Stable block production

Validator availability.

Therefore, upgrades such as Austin and Kyoto do not directly create additional demand for POL, but they strengthen the infrastructure on which Polygon’s security model depends.

What to Watch Next

After Austin and Kyoto, there are three issues worth monitoring.

First: whether additional related vulnerabilities emerge.

One group of bugs can sometimes lead researchers toward other edge cases in the same architecture.

Second: validator upgrade discipline.

Network security depends not only on new code, but also on operators actually running that code.

Third: whether Polygon strengthens resource accounting and input validation across other parts of the stack.

Because the biggest lesson from Austin and Kyoto is not about one specific function.

It is:

every untrusted input needs a clearly defined resource limit.

The Bigger Picture: Blockchain Security Is Not Just About Preventing Hacks

Austin and Kyoto demonstrate a broader way of thinking about blockchain security.

A network needs to protect at least three things:

Assets

→ prevent assets from being stolen.

Safety

→ prevent the network from accepting invalid state.

Liveness

→ ensure the network continues operating.

Crypto often focuses too heavily on the first factor.

But if blockchain is to become infrastructure for payments, stablecoins, DeFi, and financial applications, the third factor is equally important.

A payment network cannot simply say:

“Your money is still safe.”

It must also ensure:

“You can use your money when you need it.”

Austin and Kyoto are primarily about protecting that property.

Conclusion

The Austin and Kyoto hard forks were not responses to an exploit that had already occurred.

Instead, they are examples of a proactive security response.

Polygon discovered multiple issues in Bor and Heimdall, developed patches, tested them on Amoy, deployed them to mainnet, and only then disclosed the technical details. At the time of disclosure, Polygon said it had not observed the vulnerabilities being exploited on mainnet.

Austin addressed two denial-of-service paths in Bor.

Kyoto performed broader hardening of Heimdall, with the most notable issue being a vulnerability that allowed a crafted transaction to force validators to perform large amounts of decoding work.

There is no evidence that these vulnerabilities directly allowed attackers to steal assets.

But that does not make them unimportant.

If a blockchain is a financial network, then:

Availability is also security.

An attacker does not necessarily need to steal a private key.

If an attacker can:

spend very few resources

↓

force validators to spend massive resources

↓

cause nodes to crash

↓

disrupt block production

then that is already a security problem.

Austin and Kyoto therefore illustrate a lesson that extends beyond Polygon:

The more a blockchain optimizes for performance, the stricter its resource accounting and input validation must become.

Performance creates utility.

But performance often also creates additional complexity.

And:

Complexity → Attack Surface.

The true success of a blockchain is not that bugs never appear.

What matters more is whether the system can:

detect → patch → coordinate validators → upgrade → prevent exploitation

before the bug turns into an actual incident.

In the case of Austin and Kyoto, Polygon managed to do that.

But the event is also a reminder that blockchain security is not a product that is completed once.

It is a continuous process.

FAQ

Was Polygon Hacked?

No. Polygon said it had not observed the vulnerabilities addressed by Austin and Kyoto being exploited on mainnet.

What Is the Difference Between Austin and Kyoto?

Austin primarily patched two DoS attack paths in Bor, while Kyoto hardened Heimdall against multiple consensus and input-validation issues.

Did Users Lose Any Assets?

There is currently no evidence that these vulnerabilities caused asset losses. The main risks involved node crashes, validator resource exhaustion, and network liveness.

Were Validators Required to Upgrade?

Yes. Bor needed to run v2.10.0 or later, and Heimdall needed v0.11.0 or later to remain compatible with the canonical network after the hard forks.

What Is the Biggest Lesson From This Event?

It shows that blockchain security is not only about preventing asset theft. Protecting validators and maintaining continuous network availability are also critical parts of security.

Disclaimer: The information provided here is for informational purposes only and should not be considered financial, investment, legal, or professional advice. Always conduct your own research, consider your financial situation, and, if necessary, consult with a licensed professional before making any decisions.

Возможности рынка

Notcoin Курс (NOT)

----

USD

График цены Notcoin (NOT) в реальном времени

Статьи, размещенные на этой странице, взяты из открытых источников и представлены исключительно для информационных целей. Они не отражают позицию или взгляды MEXC. Все права принадлежат Nguyen Rin Hoang. Если вы считаете, что какой-либо контент нарушает права третьей стороны, пожалуйста, свяжитесь с service@support.mexc.com для оперативного удаления. MEXC не гарантирует точность, полноту или своевременность любого контента и не несет ответственности за любые действия, предпринятые на основе предоставленной информации. Содержание не является финансовым, юридическим или другим профессиональным советом, а также не должно интерпретироваться как рекомендация или одобрение со стороны MEXC. Для получения экспертных мнений и углубленного анализа посетите MEXC Обучение.