Introduction

On November 4th, 2024, 100proof and I sent a vulnerability report to NEAR Protocol's bug bounty program on Hacken Proof. The issue we found allowed an attacker to completely shut down the NEAR blockchain—all the nodes of all the shards—by deploying a very simple contract and calling it. Any attempt to restart the nodes would be futile because a new call to the contract would immediately crash them again. The only solution would be to ship a fix as fast as possible and upgrade all nodes network-wide.

If you want the full technical details of the attack, you can read the actual report we submitted to NEAR's bounty page on Hacken Proof here.

About NEAR

NEAR Protocol is a next-generation blockchain platform designed to tackle the scalability and usability challenges that have long hindered blockchain adoption. By leveraging an innovative sharding system and a developer-friendly environment, NEAR achieves high throughput and low transaction costs while maintaining strong security guarantees. Its architecture is built to be intuitive for both developers and end users, creating an ecosystem of decentralized applications (dApps) spanning DeFi, NFTs, and beyond.

A fundamental aspect of NEAR’s architecture is its asynchronous execution model, which operates on transactions and receipts. When a user submits a transaction, it consists of multiple actions, such as transferring tokens or calling smart contracts. As these actions are processed, they generate receipts, which function as asynchronous execution units. This design allows transactions to execute efficiently across multiple shards, enhancing parallel processing while ensuring security and resilience. However, as we discovered, this receipt-based execution model contained a catastrophic vulnerability.

The Hunt for the NEAR Protocol Vulnerability: An Epic Tale of Persistence and Determination

It all started with an idea—a nagging feeling that something wasn’t right in NEAR’s receipt processing. We, 100proof and neumo, weren’t even sure what we were looking for at first. Just a hunch, a suspicion that there was a critical flaw waiting to be uncovered. What followed was a relentless deep dive into NEAR’s codebase, tracing execution paths, mapping out potential exploits, and testing every edge case we could think of. It was a battle against complexity, a war against obfuscation, and a test of sheer determination.

The Early Leads and the Rabbit Holes

The first promising lead came from StorageError::StorageInconsistentState, an error that appeared throughout the NEAR codebase. What if, we wondered, it could be triggered in just the right way to cause a catastrophic failure? We traced its occurrences through functions like apply_action_receipt, process_receipt, and update_validator_accounts, analyzing how errors propagated across nodes. Each function seemed to be a potential weak point—until we found that most had built-in fail-safes that prevented them from crashing the system outright.

It felt like an endless game of cat and mouse. NEAR’s developers had put in extensive safeguards—protection against UnexpectedIntegerOverflow, conversions of StorageErrors into InvalidTxErrors, and emergency recovery mechanisms. But we knew that somewhere, hidden in the complexity, there had to be an overlooked flaw. And so, we pressed on.

Then, we found it.

The Receipt Size Exploit

The breakthrough came when we discovered max_receipt_size, a crucial configuration parameter set to 4,194,304 bytes. This defined the maximum size of receipts that the network would process. At first glance, it seemed like a basic safeguard. But then we asked ourselves: what if an action receipt could be crafted at the exact limit and then expanded dynamically?

The validation mechanisms were strict—but only at the moment of receipt creation. They weren’t designed to account for receipts growing in size mid-execution. That was the loophole. That was the chink in the armor.

We built test cases, set up local networks, and deployed experimental smart contracts. Each failure brought us closer. We fine-tuned our attack, evaded gas exhaustion errors, and dodged arbitrary execution constraints. Then, finally, with one carefully crafted execution, we broke through.

The Node Crash

The logs told us the story before the system even registered the failure. The function process_incoming_receipts, responsible for handling cross-shard communication, panicked. Our action receipt, once a neatly controlled payload, had ballooned beyond its limit, triggering an unrecoverable failure.

At that moment, we understood the gravity of what we had found. This wasn’t just a bug. It was a fundamental, systemic weakness that allowed a single transaction to bring down the entire NEAR network. If exploited in the wild, an attacker could continuously crash all nodes, rendering the blockchain completely unusable.

Technical Breakdown

The core of this exploit lies in the way NEAR processes receipts. Normally, receipts are validated against max_receipt_size at the moment they are created. However, this validation does not account for subsequent modifications—particularly the expansion of output_data_receivers during execution. By crafting an action receipt that sits just below the size limit and then dynamically adding to it, we were able to trigger a system-breaking overflow.

This occurred because:

Receipts are allowed to change size during execution.
There was no secondary validation after modifications.
Incoming receipts that exceeded the size limit caused a panic.

1. Understanding the Core Vulnerability

NEAR Core applies max_receipt_size validation when processing Action Receipts. This validation occurs in three key locations in runtime/runtime/src/lib.rs:

apply_action_receipt (Line 647)
process_delayed_receipts (Line 1795)
process_incoming_receipts (Line 1860)

Although receipts are validated upon creation, their size can increase after validation under specific conditions, leading to a network-wide failure.

2. How the Attack Works

The exploit works by crafting an Action Receipt that:

Starts at the exact max_receipt_size limit (4,194,304 bytes)
Expands dynamically after being processed, surpassing the limit
Triggers a panic in process_incoming_receipts, shutting down any node that processes it

This occurs because receipts can reference other receipts. If a ReturnData::ReceiptIndex points to a newly created receipt, the output_data_receivers list of the new receipt can be expanded without triggering revalidation. When a node later processes this oversized receipt, it panics and crashes.

3. Deploying the Malicious Contract

The attack requires deploying a contract with a function that creates a max-sized receipt. Since actions of type FunctionCallAction include an arbitrary-sized args field, we can precisely control the size. And the creation of specific promises in the contract call set up the increase in size of the new receipt, as the output_data_receivers field of the receipt is expanded with the index of the main receipt. The right ingredients for failure.

Steps to execute the exploit:

Compile and Deploy the Malicious Contract

cargo build --target wasm32-unknown-unknown --release
near deploy attacker_account ./target/wasm32-unknown-unknown/release/malicious_contract.wasm

Call the function that generates the malicious receipt

near call attacker_account exploit_with_big_action_receipt '{"args_size": 4194104 }' --gas 300000000000000 --accountId attacker_account

Observe Node Failures After executing this function, affected nodes will panic, causing the entire network to crash. To verify:
```
cat ~/.nearup/logs/localnet/node0.log | grep 'panicked'
```

4. Making the Attack Persistent

Arguably the most severe aspect of this attack is that it can be automated to continuously crash the network:

The contract remains deployed on the network
A script can call the function periodically (e.g., every minute)
Every node that attempts to restart will be immediately shut down again

A simple cron job or loop can be used to keep the network in a permanent crash state:

while true; do
   near call attacker_account exploit_with_big_action_receipt '{"args_size": 4194104 }' --gas 300000000000000 --accountId attacker_account
   sleep 60
done

5. Why Increasing max_receipt_size Won’t Help

Even if NEAR increased max_receipt_size, an attacker could simply adjust the args_size parameter accordingly. Since the contract is already deployed, it can dynamically adapt to any receipt size limit.

Responsible Disclosure Process and Bug Fix

We reported this vulnerability through the NEAR bug bounty program hosted on Hacken Proof on November 4th, 2024. Hacken Proof's team responded promptly, acknowledging the severity of the issue. Within 48 hours, NEAR's security team began working on a patch, which was deployed in a security update before public disclosure.

Version 2.3.1 of NEAR Core, released on November 13th, 2024, included the fix for the bug we disclosed.

The Assessment

Although our report—and this blog post—demonstrates the potentially catastrophic impact of this vulnerability, NEAR ultimately classified the issue as high impact. Hacken Proof's triage assigned it an 8.9, suggesting that a reward near the upper end of the high-impact range (around $200k at the time) would be appropriate. They also directed us to a link to a previously disclosed vulnerability of the same class, albeit less impactful, which was rewarded $150k with an 8.8 severity score. However, we received less than half the max amount for high-impact vulnerabilities. Despite presenting further evidence to support a higher valuation, the decision on both severity and payout was made unilaterally by the project.

We never had the chance to communicate directly with the project; Hacken Proof acted as an intermediary, passing messages between NEAR and us. While we respect the internal criteria used by NEAR and Hacken Proof, we cannot help but feel that the resolution did not fully reflect the exploit’s seriousness or the considerable effort involved. We share this experience to shed light on the challenges bounty hunters sometimes face—always with the utmost respect for all parties involved.

The Fix

The solution implemented by NEAR was to remove size validation from the function validate_receipt:

/// Validates a given receipt. Checks validity of the Action or Data receipt.
 pub(crate) fn validate_receipt(
     limit_config: &LimitConfig,
     receipt: &Receipt,
     current_protocol_version: ProtocolVersion,
 ) -> Result<(), ReceiptValidationError> {
-     let receipt_size: u64 =
-         borsh::to_vec(receipt).unwrap().len().try_into().expect("Can't convert usize to u64");
-     if receipt_size > limit_config.max_receipt_size {
-         return Err(ReceiptValidationError::ReceiptSizeExceeded {
-             size: receipt_size,
-            limit: limit_config.max_receipt_size,
-         });
-     }
 ...

To prevent future issues, they introduced a new function, validate_new_receipt, ensuring that receipt size is checked only at creation, preventing nodes from crashing due to unexpected size increases:

pub(crate) fn validate_new_receipt(
     limit_config: &LimitConfig,
     receipt: &Receipt,
     current_protocol_version: ProtocolVersion,
 ) -> Result<(), ReceiptValidationError> {
     let receipt_size: u64 =
         borsh::to_vec(receipt).unwrap().len().try_into().expect("Can't convert usize to u64");
     if receipt_size > limit_config.max_receipt_size {
         return Err(ReceiptValidationError::ReceiptSizeExceeded {
             size: receipt_size,
             limit: limit_config.max_receipt_size,
         });
     }

     validate_receipt(limit_config, receipt, current_protocol_version)
 }

This fix ensures that once a receipt has passed initial validation, it may grow beyond the size limit without making the whole network crash.

Lessons for Blockchain Security

This vulnerability underscores several important lessons for blockchain security:

Receipts must be validated at every step of execution, not just creation.
A receipt expanding in size after creation should not make the network crash, even if surpassing the max_receipt_size value.
Dynamic data growth must be accounted for in all security checks.
Asynchronous execution introduces new challenges that require careful threat modeling.

By addressing these concerns, not just in NEAR but in all blockchain ecosystems, we can prevent similar catastrophic exploits in the future.

Next Steps and Future Research

We are bounty hunters at heart—driven by the thrill of uncovering vulnerabilities before they can be exploited. The blockchain is vast, and our journey is far from over.

Having already secured bounties across multiple ecosystems, including Stacks, NEAR, and various EVM-based blockchains, we are eager to expand our expertise into new frontiers of Web3 security.

Our mission remains the same: find and neutralize the next major exploit before it causes real harm. Stay tuned—there’s more to come.

Conclusion

This vulnerability was a wake-up call. No system, no matter how well-designed, is impervious to failure. We may have found this exploit first, but there are undoubtedly others out there, waiting to be discovered.

If there’s one thing we’ve learned from this journey, it’s that no blockchain is bulletproof. The hunt continues.

About us

We found this bug while working together as Pai Mei & Gandalf.

Pai Mei & Gandalf is:

100proof: X, Immunefi
neumo: X, Immunefi

If you'd like to book us for an audit of your NEAR codebase please contact us at

pai_mei_and_gandalf X protonmail Y com

(replacing the X and Y with the obvious symbols)

Total NEAR Shutdown