A previously unknown vulnerability in Solana's privacy-focused token system could have allowed attackers to forge fake zero-knowledge proofs

The Solana Foundation has disclosed a previously unknown vulnerability in its privacy-focused token system that could have allowed attackers to forge fake zero-knowledge proofs

Solana (SOL) Foundation engineers have disclosed a previously undocumented vulnerability in its privacy-focused token system that could have been exploited by attackers to forge fake zero-knowledge proofs (ZKPs), potentially enabling unauthorized minting or withdrawals of tokens.

The vulnerability, first reported on April 16 through Anza’s GitHub security advisory and accompanied by a working proof-of-concept, was discovered by engineers from Solana development teams Anza, Firedancer, and Jito, who began working on a fix immediately, according to a post-mortem published Saturday.

The issue stemmed from the ZK ElGamAL Proof program, which verifies ZKPs used in Solana’s Token-22 confidential transfers. These extension tokens enable private balances and transfers by encrypting amounts and using cryptographic proofs to validate them.

ZKPs are a cryptographic method that lets someone prove they know or have access to something, such as a password or age, without revealing the thing itself. In crypto applications, they can be used to prove a transaction is valid without showing specific amounts or addresses, which can otherwise be used by malicious actors to plan exploits.

The bug occurred because some algebraic components were missing from the hashing process during the Fiat-Shamir transformation—a standard method to make zero-knowledge proofs non-interactive. Non-interactive in this case refers to turning a back-and-forth process into a one-time proof anyone can verify.

A sophisticated attacker could forge invalid proofs that the on-chain verifier would still accept. This would have allowed actions such as minting unlimited tokens or withdrawing tokens from other accounts.

The vulnerability did not affect standard SPL tokens or the main Token-2022 program logic. Patches were distributed privately to validator operators beginning April 17, and a second patch was pushed later that evening to address a related issue elsewhere in the codebase. Both were reviewed by third-party security firms Asymmetric Research, Neodyme, and OtterSec. By April 18, a supermajority of validators had adopted the fix.

There is no indication that the bug was exploited, and all funds remain secure, according to the post-mortem.