Post Mortem: ZK ElGamal Proof Program Bug, June 2025

by Solana Foundation

Post Mortem: ZK ElGamal Proof Program Bug, June 2025
Timeline

On 2025-06-10, a potential vulnerability was reported to the Anza Github Security Advisory by suneal_eth (a security researcher from zksecurityXYZ). The report contained a proof of concept for the vulnerability. There is no known exploit of the vulnerability. Engineers from Anza, Firedancer, and Jito began evaluating the report and confirmed that it allowed for the construction of arbitrary proofs that the ZK ElGamal Proof program would accept as valid.


Engineers created a patch to address the reported issue, however, given that this is the second ZK ElGamal issue reported, and out of an abundance of caution, engineers chose to publish a change to the upgradable Token-2022 program to disable confidential transfers until more auditing could be done. The updated Token-2022 program was deployed via a multisig on 2025-06-11 and mitigated the reported potential vulnerability. On 2025-06-13, an urgent upgrade request was sent to the mb-announcements channel of the solana-tech discord, requesting that operators adopt Agave v2.2.16, Jito-Solana v2.2.16 or Firedancer v0.505.20216. The requested software upgrades contained a feature activation to disable the ZK ElGamal proof program. On 2025-06-19, at approximately 06:00 UTC at the start of mainnet-beta epoch 805, the ZK ElGamal proof program was disabled via feature activation.

Preliminaries

A Token-2022 confidential transfer is executed via two programs: the Token-2022 program and the ZK ElGamal Proof program. The Token-2022 program is a popular on-chain program that handles the main application logic for token mints, and accounts. The ZK ElGamal Proof program is a native program that verifies the correctness of complex zero-knowledge proofs certifying the validity of encrypted balances in accounts and transactions.

Typically, a zero-knowledge proof system is implemented by converting a two-party interactive zero-knowledge proof protocol into a non-interactive proof system using the "Fiat-Shamir Transformation". The Fiat-Shamir Transformation specifies how a prover can generate public randomness using a cryptographic hash function. When verifying proofs generated via the Fiat-Shamir Transformation, the verification logic must hash all algebraic components comprising the proof.

The bug

In the on-chain ZK ElGamal Proof program, a component was not included in a hash used to generate a transcript for the Fiat-Shamir Transformation. A sophisticated attacker could use this unhashed component to develop a forged proof of an unauthorized action that passes verification. This vulnerability only affects Token-2022 confidential tokens and allows an attacker to perform unauthorized actions such as minting unlimited tokens or draining a victim’s confidential balance.

The fix

The ZK ElGamal program is a new program on Solana Mainnet Beta. After an exploration, it was found that only the Confidential Transfer features of the Token-2022 program use the ElGamal functionality affected by the bug. The Token-2022 program is currently an upgradable program. As a short term mitigation, the Token-2022 program was updated to disable confidential transfers on 2025-06-11. To mitigate any future attacks on the ZK ElGamal program, and out of an abundance of caution, a feature activation was activated at the start of Mainnet-Beta epoch 805 that has disabled the ZK ElGamal program while further audits can be performed. The ZK ElGamal program will be re-enabled after audits are completed and any issues reported have been mitigated. The process of auditing the program, implementing any necessary changes, and then deploying the updated software will take at least a few months. Please monitor the mb-announcements and mb-feature-gates channels of the Ssolana tech discord for further updates.

Impact

Token-2022 features that require the ZK ElGamal program are used by innovative products that are still in testing. While a number of major stablecoins like PYUSD, AUSD, and USDG have Confidential Transfers initialized, none of them have activated this feature for their end users. Actual usage of Confidential Transfers is still extremely low. No real volumes or dollar value is currently moved through Confidential Transfers. The impact, therefore, is minimal. There are no known exploits of the potential vulnerability.

Tl;dr

A potential vulnerability was responsibly reported. The vulnerability could allow an attacker to forge an invalid proof and have it accepted by the ZK ElGamal Proof program.