Back to Blog

Public Transfer Vulnerability of the Tether Gold Smart Contract

Code Auditing
May 27, 2023

Our internal analysis tool found a bug in Tether Gold contract on April 5th, which allows an attacker to transfer anyone’s XAUt (Tether Gold) token to a predefined address. The team received our report and said they had located this issue internally. Today we found that the issue has been fixed, and we want to share the details here. Also, we will illustrate how to use Phalcon Fork to develop and debug the PoC of this vulnerability.

0x0. The vulnerability

In the transferFrom function of the contract, anyone can invoke this function to transfer other users’ tokens into a trusted receipt defined by the token Owner. Though this vulnerability cannot be directly exploited to transfer the tokens to the attacker’s account, the attacker can still transfer the pool’s token to manipulate the token price in the pool (say WETH-XAUt pool) to profit.

The fix to this vulnerability is straightforward, as shown in the following.

0x1. How to exploit the vulnerability

To write and debug the PoC, we can use the Phalcon Fork for this purpose. First, we can create a Fork before the vulnerability is patched. I used the block height 17038763 when creating the Fork through the Fork API.

Step I: prepare enough Ether

The first step is to get enough Ether for the gas fee for the exploiter. If there is no Ether in the account, the transaction that sends Ether from the vitalik.eth will be issued.

Step II: transfer the ownership of the Tether Gold contract

The owner of the Tether Gold contract is a multisig wallet (0xC6CDE7C39eB2f0F0095F41570af89eFC2C1Ea828). To transfer the ownership to the exploiter, we need to submit a multisig transaction and then confirm the transaction.

Step III: Add a privileged account to the Tether Gold contract

We added a new account 0x189e7947a9d9210eec3a41dcf5f536bb1d7726f5 as a privileged account. And then, we invoke the transferFrom function to transfer the XAUt token from a victim to the privileged account.

0x2. PoC

Please find the PoC on this github:

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

Newsletter - June 2026

This monthly report covers the three largest security incidents in June 2026, totaling approximately $22M in confirmed losses. A sophisticated honeypot attack drained ~$15M from JaredFromSubway's MEV bot by exploiting unchecked token allowances. Two legacy Aztec rollup deployments lost ~$4.35M through proof-settlement boundary gaps. SecondFi's Ed25519 implementation flaw exposed wallet private keys, resulting in ~$2.4M drained from 374 wallets. All three incidents share a common pattern: security guarantees that appeared intact on the surface but were never actually enforced.

~$4.1M Lost: Taiko, SecondFi Exploits | BlockSec Weekly
Security Insights

~$4.1M Lost: Taiko, SecondFi Exploits | BlockSec Weekly

This weekly blockchain security report covers two notable incidents from June 22-28, 2026, with approximately $4.1M in confirmed losses across Ethereum and Cardano. The Taiko bridge exploit combined an exposed SGX enclave signing key with an incomplete attestation policy that failed to reject debug enclaves, allowing the attacker to register a malicious prover and forge L2 state proofs on Ethereum. The SecondFi wallet vulnerability stemmed from a cryptographic implementation flaw in Ed25519 nonce derivation that removed the secret input, enabling offline private key recovery from public Cardano transaction data.

~$18M Lost: jaredFromSubway, Aztec & More | BlockSec Weekly
Security Insights

~$18M Lost: jaredFromSubway, Aztec & More | BlockSec Weekly

This weekly blockchain security report covers June 15 to June 21, 2026, with 3 notable incidents across Ethereum and BNB Chain totaling approximately $18.3M in losses. Two incidents are analyzed in detail. Based on on-chain analysis, the highlighted jaredFromSubway incident reveals a reversed approval attack pattern: unlike traditional exploits where attackers abuse vulnerabilities in trusted DeFi contracts to drain user-approved assets, this MEV bot proactively approved its own assets to untrusted third-party contracts for arbitrage. The attacker constructed fake wrapper tokens and swap pools that emitted real events but never consumed the granted allowances, with reported total losses of ~$15M. The report also covers Aztec's second exploit in three days, where a missing equality constraint between two witnesses for `old_data_root` in the escape hatch ZK circuit allowed the attacker to prove ownership of fabricated notes against a fake Merkle tree while passing on-chain root validation.

Best Security Auditor for Web3

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

BlockSec Audit