Get the Crypto Payment Security & Compliance Playbook
Back to Blog

How a Critical Bug in Solana Network was Detected and Timely Patched

Code Auditing
June 7, 2022

In April, our vulnerability detection system discovered an issue in the rBPF of Solana (i.e., the virtual machine where all the Solana dApps are running on: https://github.com/solana-labs/rbpf). After a careful investigation, we found that it is a security vulnerability that can lead to a wrong execution path of a contract. We have reported the bug to the Solana security team, and the team immediately confirmed and fixed the vulnerability. Also, they granted our team a $800,000 USD worth of SoL token.

The vulnerability exists in newer versions of rBPF (0.2.26 to 0.2.27). When we reported the issue, the validators used on the mainnet has not been upgraded to the affected version(s). Our system detected the issue prior to the affected version being merged, making the validator of the mainnet immune to this vulnerability.

We elaborate on the details of this vulnerability in the following.

1. eBPF and rBPF

eBPF (Extended Berkeley Packet Filter) was initially developed for filtering packets in the kernel. Due to the security, efficiency, and scalability of eBPF, it is now used in various areas like networking, tracing, profiling, etc. Considering the rich capability of eBPF, Solana uses it as the execution engine for the smart contract. To build the dApps on Solana, developers develop their smart contracts in Rust and compile the contract into eBPF bytecode.

Solana uses the rBPF, a virtual machine written in Rust, to execute the compiled BPF bytecode. However, whether the proposed virtual machine (i.e., rBPF) is robust, secure, and precise is unknown. If security issues exist inside the rBPF, all the validators containing the rBPF can be influenced, resulting in the huge loss (e.g., Loss of Funds) for the whole Solana network.

2. Root Cause

We developed a tool that can automatically locate the implementation bugs of rBPF and scan the code of rBPF periodically. One serious problem was identified in rBPF (version 0.2.26) during the scanning process, which may lead to the wrong execution path of a contract.

Specifically, the sdiv instruction is used as a signed division instruction, introduced as a feature enabled by default in rbpf 0.2.26. sdiv supports division for operands in both 32-bits (i.e., sdiv32) and 64-bits (sdiv64). For instruction sdiv32, the calculation result is stored in the bpf register, which is a 64-bits one. However, if the instructions after the sdiv32 one read the calculation result as 64 bits, the result may differ. It is because rBPF does not extend the calculation result of sdiv32 into the correct value in 64-bits during the JIT compilation.

For example, if a positive number (i.e., 12) is divided by a negative number (i.e., -4) with sdiv32, the correct result should be -3 in both 32 bits and 64 bits. The code below is an example.

After running and tracing it under both JIT and Interpreted modes, we could observe the differences between them:

2.1 Interpreted Mode

0 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    29: lddw r5, 0x10000000c
 1 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 000000010000000C, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    31: sdiv32 r5, -4
 2 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, FFFFFFFFFFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    32: jslt r5, 0, lbb_7
 3 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, FFFFFFFFFFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    36: exit

2.2 JIT Mode

0 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    29: lddw r5, 0x10000000c
 1 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 000000010000000C, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    31: sdiv32 r5, -4
 2 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 00000000FFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    32: jslt r5, 0, lbb_7
 3 [0000000000000000, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 00000000FFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    33: lddw r0, 0x1
 4 [0000000000000001, 0000000400000000, 0000000000000000, 0000000000000000, 0000000000000000, 00000000FFFFFFFD, 0000000000000000, 0000000000000000, 0000000000000000, 0000000000000000, 0000000200014000]    35: exit

In the Interpreted mode, register r5 is set to 0xFFFFFFFFFFFFFFFD (-3 in both 32-bit and 64-bit mode), while in JIT mode, r5 is set to 0x00000000FFFFFFFD. In this case, r5 will be recognized as a positive number (i.e., 0x00000000FFFFFFFD) for instruction jslt, which receives a 64-bit value. After that, the execution path will be totally wrong.

3. Impact

This wrong implementation can lead to the incorrect execution path of a contract and may cause serious problems.

For instance, if an essential operation in a smart contract relies on the result of sdiv32 instruction, it can lead to incorrect execution results and be abused by attackers.

This issue was introduced in https://github.com/solana-labs/rbpf/pull/283, meaning that rBPF is vulnerable from version 0.2.26. We identified the problem and reported it to the Solana security team on 2022 April 28th. The team quickly responded to our report and fixed the issue in a few hours by adding the sign-extend operation for sdiv32 instruction. The fix is in https://github.com/solana-labs/rbpf/pull/310. Due to the timely detection and report from our team, validators of the mainnet are not affected by this vulnerability.

This issue is classified as a protocol liveness bug, leading to $800,000 bug bounty granted by Solana.

Timeline

  • 2022/04/28: We reported the problem to the Solana security team
  • 2022/04/29: the vulnerability was fixed
  • 2022/05/09: CVE-2022-23066 was assigned
  • 2022/06/01: The bug bounty was granted

About BlockSec

The BlockSec Team focuses on the security of the blockchain ecosystem, and collaborates with leading DeFi projects to secure their products. The team is founded by top-notch security researchers and experienced experts from both academia and industry. They have published multiple blockchain security papers in prestigious conferences, reported several zero-day attacks of DeFi applications, and released detailed analysis reports of high-impact security incidents.

Twitter: [BlockSecTeam]

Medium: https://blocksecteam.medium.com

Website: https://www.blocksec.com

Sign up for the latest updates
Newsletter - August 2026
Security Insights

Newsletter - August 2026

During August 2026, three major DeFi security incidents caused significant losses. A balance-synchronization vulnerability in the Cosmos EVM module was exploited across six chains (~$14.8M). Moonwell on Base lost ~$9.1M to oracle price manipulation targeting the low-liquidity MAMO token. Term Finance on Ethereum suffered a ~$8.47M governance takeover enabled by near-zero voter participation.

~$10.26M Lost: Term Finance, MAYAChain | BlockSec Weekly
Security Insights

~$10.26M Lost: Term Finance, MAYAChain | BlockSec Weekly

During the week of August 17-23, 2026, two notable security incidents resulted in approximately $10.26M in total losses across Ethereum and MAYAChain. The highlighted Term Finance incident (~$8.5M) was a flawed governance design rather than a coding bug: each vault ships its own on-chain DAO whose support-threshold and participation checks are purely relative, with no absolute floor; with almost no one taking part in governance, there was no electorate to vote a proposal down and no guardian to cancel one, so an attacker acquired a supermajority of a vault's voting power for roughly 0.5 ETH and, after the execution delay elapsed, drained six of Term's vaults for approximately $8.5M in total. MAYAChain (~$1.76M) lost funds to a chain of accounting and state-validation defects, where a single crafted deposit made valid withdrawals appear to have failed, triggered a recovery path that inflated a low-liquidity pool's recorded native-token balance with no real backing, and let the attacker drain the inflated value by adding and withdrawing liquidity.

Harmony Cross-Shard ONE Mint + ~$47M Key Losses | BlockSec Weekly
Security Insights

Harmony Cross-Shard ONE Mint + ~$47M Key Losses | BlockSec Weekly

During the week of August 10-16, 2026, 5 notable security incidents are featured, involving approximately $47M in quantified losses, with the detailed analysis focused on a chain-implementation flaw in the Harmony Layer-1. Harmony suffered unauthorized minting of native ONE through a cross-shard receipt replay: destination shards derived the receipt spent-marker from unauthenticated MerkleProof.ShardID and BlockNum fields instead of the signed source header, so an already-credited receipt could be replayed with no matching source-shard debit. Approximately 3.01T ONE was forged, but its nominal value far exceeds the token's market capitalization and is neither realizable nor confirmed realized loss, so Harmony is excluded from the total; the ~$47M came from private-key compromises (Unknown Whale Wallet ~$25M, Kite ~$14M, and Coinsbuy ~$7.9M) plus a Fox business-logic flaw (~$117K).

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit
How a Critical Bug in Solana Network was Detected and Timely Patched