January 2026: Gossip and Vote Processing Security Patch Summary

Summary

Two critical potential security vulnerabilities were responsibly disclosed to Anza via GitHub security advisories in December 2025. The first report related to an attack on the gossip protocol that could cause a validator node to crash and the second involved a potential vote censoring attack. After assessment, the vulnerabilities were patched in collaboration with Firedancer, Jito, and the Solana Foundation. It is recommended to upgrade to Agave/Jito v3.0.14 or Frankendancer 0.808.30014.

There was no known attack on the cluster. 

Gossip Root Cause Analysis

Preliminaries

The Gossip protocol is responsible for high-availability propagation of signaling information in Solana. Gossip remains available even if block production is stalled or impossible. To facilitate identification of stalls caused by equivocation, gossip propagates duplicate shred proofs. These proofs are larger than a single gossip packet and therefore require reassembly in a defragmentation buffer before they can be fully validated.

The Bug

The reassembly buffer has finite capacity, with cleanup triggered once the buffer exceeds a configured size threshold. A bug in this cleanup logic triggered the bounds check error during read of an intermediate data structure, resulting in a panic, terminating the validator process. Had enough stake been taken off line simultaneously by exploiting this vulnerability, loss of cluster availability would be achieved.

The Fix

The fix adjusts the cleanup trigger condition to ensure that indexing assumptions are not violated, preventing the panic.

Vote Processing Root Cause Analysis

Preliminaries

Validators participating in Solana consensus specify a vote authority. This authority is a keypair that must sign vote transactions originating from the validator. The vote program and transaction processing pipeline are responsible for verifying that the correct vote authority signature is present on each validator’s votes.

Votes are processed as on-chain transactions. To facilitate this, validators maintain a buffer of recent vote transactions (the VoteStorage data structure) received from the cluster. During block production, leaders drain any valid votes for the fork they are building on from VoteStorage into the block they propose.

The Bug

As an optimization, VoteStorage only stores the most recent vote from each validator. However, VoteStorage was implemented without the proper vote authority check. As a result, the following attack was possible:

• Construct vote transactions for each validator targeting a slot far in the future.

• Sign these transactions with an arbitrary keypair (not the validator’s vote authority).

• Send these transactions to an upcoming leader.

If the signature is valid, these transactions are accepted into the leader’s VoteStorage. The critical bug is that VoteStorage failed to verify that the signer is the configured vote authority for that validator. Because the voted-on slot is very large, any genuine votes from that validator are blocked from being ingested.

When the upcoming leader later attempts to pack their block, they skip draining these malicious votes: the large voted slot is not part of the fork they are building on, so those votes are ignored during packing. 

The net effect is that the leader is unable to pack any valid votes for affected validators into its block. There is no expiration from the VoteStorage buffer, so this affects leader slots until the validator restarts their process. If this attack were carried out against enough validators consensus would stall.

The Fix

The fix adds the proper checks to VoteStorage, verifying that the vote transactions are correctly signed with the vote authority associated with the validator, before ingesting the vote into the buffer.