Solana devs fix bug that allowed unlimited minting of certain tokens

The Solana Foundation has confirmed that a zero-day vulnerability that allowed an attacker to potentially mint certain tokens and even withdraw those tokens from user accounts has been fixed.

A May 3 post-mortem from the Solana Foundation said that the security vulnerability, first discovered on April 16, could have allowed an attacker to forge an invalid proof affecting Solana’s privacy-enabling “Token-22 confidential tokens.”

There is no known exploit of the vulnerability, and Solana validators have since adopted the patched version, the foundation said.

Solana zero-day security bug affected Token-22 confidential tokens

The Solana Foundation said the security vulnerability concerned two programs: Token-2022 and ZK ElGamal Proof.

Token-2022 handles the main application logic for token mints and accounts, while ZK ElGamal Proof verifies the correctness of zero-knowledge proofs to show accurate account balances.

The foundation said certain algebraic components were omitted from the hash in the Fiat-Shamir Transformation’s transcript generation, which specifies how provers create public randomness using a cryptographic hash function.

The flaw could have enabled an attacker to exploit the unhashed components by crafting a forged proof that passes verification to mint and steal Token-22 confidential tokens.

Token-22 confidential tokens, or “Extension Tokens,” leverage zero-knowledge proofs for private transfers and aim to enable advanced token functionality.

The vulnerability was first identified on April 16, and two patches were deployed to resolve the issues. A super majority of Solana validators adopted the patches around two days later.

Solana development firms Anza, Firedancer and Jito were the main parties behind the security patch, while Asymmetric Research, Neodyme and OtterSec also assisted.

The foundation confirmed that all funds remain safe.

Despite the fix, the Solana Foundation’s private handling of the issue with Solana validators raised centralization concerns from some in the crypto community.

This included a Curve Finance contributor who raised concerns about the foundation’s close relationship with Solana validators.

“Why does someone have a list of all validators and their contact details? What else are they talking about in those comms channels,” they asked, fearing that they could collude to potentially censor transactions or roll back the chain.

Solana Labs CEO Anatoly Yakovenko didn’t directly deny the claims but said members of the Ethereum community could also coordinate to resolve a similar security bug.

More than 70% of Ethereum network validators are also controlled by crypto exchanges or staking operators such as Lido, Yakovenko said in arguing his point.

“It’s the same people to get to 70% on ethereum. All the lido validators (chorus one, p2p, etc..) binance, coinbase, and kraken. If geth needs to push a patch, I’ll be happy to coordinate for them.”

In August, the Solana Foundation and network validators resolved another critical vulnerability behind the scenes. At the time, the foundation’s executive director, Dan Albert, said the ability to coordinate a patch doesn’t mean that Solana is centralized.

Ethereum wouldn’t fall for the same issue, community member says

Ethereum community member Ryan Berckmans slammed claims that Ethereum is subject to the same centralization issues as Solana, pointing out that Ethereum has sufficient client diversity.

The most popular Ethereum client, geth, has at most 41% market share on Ethereum, Berckmans said, while noting that Solana has just one production-ready client, Agave.

“This means zero day bugs in the single Sol client are de facto protocol bugs. Change the single client program, change the protocol itself. The client is the protocol.”

Meanwhile, Solana is looking to roll out a new client, Firedancer, in the next few months, which is expected to improve the network’s resilience and uptime.

However, Berckmans said that Solana would need three clients to be sufficiently decentralized at the client level.