OAK — OnChain Attack Knowledge

Worked example · 2024-20

Solana Token-2022 transfer-hook class vulnerability and ZK-ElGamal proof zero-day — Solana — 2024-2025

Loss
$0 realised at v0.1 cutoff. The Token-2022 transfer-hook callback-based vulnerability class is a standing surface with no publicly-confirmed exploit at v0.1; the April 2025 Token-2022 ZK-ElGamal proof zero-day was disclosed and patched within two days with no funds compromised per the Solana Foundation post-mortem. The case is included as a class-level worked example because it anchors the OAK-T1.007 (Token-2022 Transfer-Hook Abuse) proposal in TAXONOMY-GAPS.md and provides the structural framing for cohort-scale defender-practice prior to a per-incident anchor materialising.
OAK Techniques observed
OAK-T1.007 — Token-2022 Transfer-Hook Abuse: SPL Token-2022 mints with the TransferHook extension configured to invoke an attacker-controlled program on every transfer_checked invocation, reintroducing the callback-based vulnerability class (reentrancy, mid-transfer state mutation, attacker-controlled CPI) that Solana's runtime had previously precluded by design. OAK-T6 (Defense Evasion) as a layered modifier — the hook program is specified by the token creator not the caller, so a malicious hook is invisible to standard pre-trade checks that only verify the calling program. The case is a class-level anchor for T1.007 because per-incident named cases with public on-chain forensic disclosure remain thin at v0.1 cutoff; the framing parallels T1.005's "primarily visible at the cohort scale" v0.1 framing.
Attribution
unattributed at the per-incident layer (no public exploit confirmed at v0.1 cutoff). The Solana Foundation's April 2025 ZK-ElGamal zero-day was reported to the foundation on 2025-04-16, fixed within two days, and disclosed publicly on 2025-05-05 with no indication of in-the-wild exploitation. The Anza Halborn 2022 pre-production audit of Token-2022 (initial bugfix review) identified the transfer-fee-circumvention and confidential-transfer-non-transferable bugs in pre-launch code; both were patched before mainnet deployment. The transfer-hook class vulnerability is documented at the technical-class level in the dev.to writeup, RareSkills specification, Halborn audit-class commentary, and Chainstack / Quicknode developer guides; per-incident named cases are not yet publicly anchored.
Key teaching point
The Token-2022 transfer-hook extension is the first Solana-native primitive that imports the full Ethereum callback-based vulnerability class — reentrancy, mid-transfer state mutation, attacker-controlled CPI — into a runtime that had previously precluded such classes by design. The class is not yet anchored to a publicly-disclosed exploit at v0.1, which makes it OAK's canonical example of a Maturity: emerging Technique where the threat-class characterisation is mature but the field-confirmed externally-attributed-exploit anchor is empty. T1.007 is the right v0.x-priority Technique to track for promotion from emerging to observed once the first per-incident anchor materialises.

Summary

The Solana Program Library (SPL) Token-2022 program shipped a feature-set called Token Extensions in late 2022 / early 2023, designed to give token issuers programmatic control over mint behaviour without redeploying the underlying token program. Among the extensions: TransferFeeConfig, MintCloseAuthority, PermanentDelegate (see examples/2024-09-solana-permanent-delegate-burn-on-buy-cohort.md for the canonical T1.002 cohort case), ConfidentialTransfer, and TransferHook.

The TransferHook extension lets a token issuer attach an arbitrary program ID that is called via Cross-Program Invocation (CPI) on every transfer_checked invocation against the configured mint. The hook program receives the transfer details and can execute arbitrary logic. Critically:

  1. The hook program is specified by the token creator, not the caller. When transfer_checked is invoked on a mint configured with a transfer_hook_program_id, the Token-2022 program makes an additional CPI call to the hook program. The caller has no say in which program is invoked; the mint config is binding.

  2. Solana's runtime invariant — "a program can only modify accounts it owns" — is preserved at the protection-domain layer, but the callback-based attack surface is reintroduced. The hook program can read transfer details, can perform arbitrary CPI calls of its own, and can return execution to the original Token-2022 program in a state mutated by the hook's actions. This reintroduces the full Ethereum callback-based vulnerability class — reentrancy, mid-transfer state mutation, attacker-controlled CPI — into Solana's runtime, where Solana developers had previously not had to defend against it.

  3. The assumption that "reentrancy can't happen on Solana" is no longer true for any program that interacts with Token-2022 mints. Per the dev.to writeup ("Solana's Token-2022 Transfer Hooks: How a 'Safe' Feature Imported Ethereum's Deadliest Bug Class"): "Token-2022 added callbacks for legitimate business reasons, and with them came every class of callback-based vulnerability that Ethereum has spent eight years learning to defend against."

The threat class is documented at the technical-class level across multiple defender-side and developer-side sources:

  • Halborn's pre-production audit (November 2022) identified two critical Token-2022 bugs in pre-launch code: (a) the withdraw / deposit instructions could be turned into a pseudo-transfer instruction by providing different source / destination token wallets, allowing transfer-fee circumvention; (b) the confidential-transfer extension lacked a check for non-transferable tokens, allowing users to deposit non-transferable tokens into a confidential token account and transfer them. Both were patched pre-launch.
  • Solana Foundation ZK-ElGamal proof zero-day (April 2025) in the ZK ElGamal Proof program (used to verify zero-knowledge proofs for Token-2022 confidential transfers) could have allowed attackers to forge fake zero-knowledge proofs, enabling unauthorised minting or withdrawals of confidential-transfer tokens. Reported 2025-04-16; fixed within two days; disclosed publicly 2025-05-05 with no indication of in-the-wild exploitation.
  • Transfer-hook class vulnerabilities — documented at the class level in the dev.to writeup, RareSkills' Token-2022 specification, Chainstack's and Quicknode's developer guides, the Solana Foundation Token Extensions developer documentation, and the Solana Handbook (Ackee). Specific per-incident exploits with public on-chain forensic disclosure are not yet anchored at v0.1.

The class is the v0.x-priority gap that motivates the OAK-T1.007 (Token-2022 Transfer-Hook Abuse) sub-Technique proposal in TAXONOMY-GAPS.md. The proposal is for Maturity: emerging rather than observed because the threat-class characterisation is mature but the field-confirmed-exploit anchor is empty.

Why this is structurally significant

T1.007 sits at a structurally distinct intersection from T1.002 (Permanent Delegate Authority) and T1.005 (Hidden Fee-on-Transfer / Token-2022 TransferFee extension), even though all three are Token-2022-extension-based:

  • T1.002 (PermanentDelegate): the extension grants standing burn / transfer authority over holder balances. Detection is binary at the mint-config layer; UX-layer enforcement is the binding constraint.
  • T1.005 (TransferFee): the extension imposes a fee on transfers; failure mode is fee-as-tax that the operator can withdraw. Detection is binary at the mint-config layer; legitimate-use overlap is broad (the extension is the mechanism for legitimate fee-on-transfer tokens).
  • T1.007 (TransferHook): the extension invokes attacker-controlled code on every transfer. Detection is not binary at the mint-config layer — the hook program ID is observable, but reasoning about the hook program's behaviour requires program-level static analysis or simulation. The detection surface is structurally closer to EVM honeypot detection (T1.006) than to the other Token-2022-extension Techniques.

Three structural features distinguish T1.007 within the v0.x Technique landscape:

  1. The hook program is independently upgradable / mutable. Unlike T1.002 (PD authority, which can be transferred but not upgraded — the authority semantics are fixed), the hook program can itself be a Solana program upgradable via standard BPFLoaderUpgradeable mechanics. A benign hook at deployment can be upgraded to a malicious hook post-deployment by the program's upgrade authority. This is the runtime-mutable hook sub-pattern, structurally analogous to EVM proxy-upgrade-malicious-switching (T6.005).

  2. The reentrancy class is genuinely new for Solana. Solana developers have eight years less experience defending against callback-based vulnerability classes than Ethereum developers. Standard Ethereum patterns (checks-effects-interactions, ReentrancyGuard, careful CPI ordering) need to be ported to Solana program-development practice. The defender-tooling cohort (Solana program-static-analysis tools — Anchor's static checks, Sec3's tooling, OtterSec's audit practice) is calibrating to the new threat surface in 2024-2026.

  3. The class is not yet anchored to a per-incident exploit at v0.1. This is itself structurally informative: the threat-class characterisation is mature (multiple defender-side and developer-side sources document the surface) but the field-confirmed-exploit anchor is empty. The class is therefore the canonical example of a Maturity: emerging Technique where promotion to observed awaits the first per-incident anchor. The Solana Foundation's April 2025 ZK-ElGamal zero-day demonstrates that Token-2022 internals are an active attack-research surface; the transfer-hook class is the highest-leverage class within that surface for cohort-scale exploitation once the operator-side capability matures.

The case generalises beyond Solana. Any token standard that admits attacker-controlled callbacks on transfer is exposed to T1.007-equivalent exploitation: ERC-777 (the Ethereum analogue, with documented reentrancy exploits including imBTC 2020 and Lendf.Me 2020); ERC-1363 (transfer-and-call); ERC-4626 (vault hooks). The Solana Token-2022 transfer-hook is the latest entry in this class; T1.007 contributors should treat the cross-standard analogues as adjacent reference and ensure the Technique's framing generalises.

Timeline (UTC)

When Event OAK ref
2022-11 Halborn audits pre-production Token-2022 code; identifies transfer-fee-circumvention and confidential-transfer-non-transferable bugs; both patched pre-launch (T1.007 + adjacent class — pre-launch bugfix)
2023-onward Token-2022 extension family rolls out on mainnet; TransferHook extension available for token-creator opt-in (genesis surface)
2024-onward Defender-side coverage of the transfer-hook class develops: dev.to writeup, RareSkills specification, Halborn class-level commentary, Chainstack / Quicknode / Solana Handbook developer guides; per-incident anchor remains empty (standing T1.007 surface)
2025-04-16 ZK-ElGamal proof zero-day reported to the Solana Foundation by external researcher; vulnerability in the ZK ElGamal Proof program could allow forged zero-knowledge proofs for Token-2022 confidential transfers (T1.007-adjacent class — pre-incident-anchor disclosure)
2025-04-18 Vulnerability fixed by Solana developers within two days of disclosure (defender response)
2025-05-05 Vulnerability disclosed publicly via CoinDesk and Solana Foundation post-mortem; no indication of in-the-wild exploitation; standard SPL tokens and main Token-2022 program logic unaffected (forensic surface — class-level anchor only)
Continuing Per-incident T1.007 transfer-hook anchor remains empty at v0.1 cutoff (2026-04-30); class characterisation is mature; promotion to observed awaits first per-incident exploit with public on-chain forensic disclosure (continuing surface)

What defenders observed

  • Pre-event (mint-extension-and-program layer): the transfer-hook program ID is observable at the mint-config layer via the standard Token-2022 extension TLV parsing. Binary detection of whether a transfer hook is configured is straightforward; reasoning about what the hook does requires program-level static analysis (Anchor IDL inspection if available; raw Solana BPF static analysis otherwise) or simulation against the hook. The detection surface is structurally closer to EVM contract-static-analysis (T1.006) than to mint-config binary checks (T1.002 / T1.005). Defender lesson: detection-tool maturity for the transfer-hook class is not yet at parity with the other Token-2022 extensions; vendor coverage at v0.1 is partial.
  • At-event (callback-class signal): absent a per-incident anchor at v0.1, the at-event signal characterisation is theoretical. The dev.to writeup and the broader callback-class literature suggest that successful T1.007 exploits will be characterised by: (a) unexpected mid-transfer state mutations in the calling program; (b) re-entry into the Token-2022 program via the hook's CPI; (c) attacker-controlled CPI to drain pools or mint additional tokens via the hook's privileged execution context. The Ethereum analogue (ERC-777 reentrancy via tokensReceived hook; canonical incidents: imBTC 2020, Lendf.Me 2020 ~$25M) is the closest reference.
  • At-event (Solana-foundation-zero-day signal, April 2025): the ZK-ElGamal proof vulnerability was identified by external research; the patch shipped within two days; no in-the-wild exploitation confirmed. The signal pattern is a positive signal for Solana's Token-2022 security posture (rapid disclosure-and-patch cycle, foundation-level coordination) and a negative signal for the broader threat surface (zero-day class active research). T1.007 contributors should track the disclosure-and-patch cycle as a defender-tooling capability.
  • Post-event: absent a per-incident anchor at v0.1, post-event recovery characterisation is theoretical. The structural expectation is that successful T1.007 exploits whose hook drains pools will produce standard recovery-window-closure profiles via cross-chain bridge laundering (T7.003) or mixer routing (T7.001) — same as the broader Solana exploit cohort.

What this example tells contributors writing future Technique pages

  • T1.007 is the canonical Maturity:emerging Technique candidate at v0.1. The threat-class characterisation is mature (dev.to writeup, RareSkills specification, Halborn class commentary, Chainstack / Quicknode developer guides, Solana Foundation documentation); the field-confirmed-exploit anchor is empty. T1.007 contributors should expect promotion to observed once the first per-incident exploit with public on-chain forensic disclosure materialises.
  • Cross-standard callback-class analogues should anchor the framing. ERC-777 reentrancy (imBTC 2020, Lendf.Me 2020) is the closest cross-standard reference; ERC-1363 and ERC-4626 are adjacent surfaces. Future T1.007 contributors should treat the cross-standard analogues as part of the framing rather than narrowing to Solana-specific examples.
  • Detection-tool maturity for the transfer-hook class lags T1.002 / T1.005 maturity. Mint-config binary checks (PD presence, fee-on-transfer presence) are mature; hook program behavioural analysis is not. v0.x defender-tooling work should prioritise hook-program-static-analysis as a cohort-scale capability.
  • The hook program's own upgrade authority is a residual T6.005 surface. A benign hook at mint-deployment can be upgraded to a malicious hook post-deployment via standard BPFLoaderUpgradeable mechanics. T1.007 detection must enumerate the hook program's upgrade authority as a first-class authority surface (M05 enumeration applied at the Solana program layer, not the EVM contract layer).
  • The Halborn / Anza pre-production audit pattern is the canonical defender-side coverage model. Halborn's November 2022 pre-launch audit caught two critical Token-2022 bugs before mainnet deployment; the ZK-ElGamal April 2025 zero-day was caught by external research and patched within two days. The disclosure-and-patch cycle is a positive defender-tooling signal; T1.007 framing should record the cycle's operational properties.

Public references

Discussion

The Solana Token-2022 transfer-hook class is OAK's canonical 2024-2025 candidate for the Maturity: emerging classification. The threat-class characterisation is mature (multiple defender-side and developer-side sources document the surface in technical detail) but the field-confirmed externally-attributed-exploit anchor is empty. The class is structurally the highest-leverage Token-2022 extension class for cohort-scale exploitation: PermanentDelegate (T1.002) requires the operator to manage the delegate authority off-chain; TransferFee (T1.005-Solana-side analogue) is bounded by the fee-arithmetic primitive; TransferHook permits arbitrary attacker-controlled code execution on every transfer.

The case is included in the v0.1 example set as a class-level anchor because:

  1. The class is the highest-priority Token-2022 surface for v0.x promotion from emerging to observed.
  2. The defender-side framing (callback-class vulnerabilities reintroduced into Solana's runtime) is structurally novel for Solana developers and merits explicit articulation in OAK's reference material.
  3. The Halborn pre-production audit pattern + Solana Foundation ZK-ElGamal April 2025 disclosure-and-patch cycle establish a positive defender-tooling baseline that T1.007 contributors should track.

The structural parallel to ERC-777 / Lendf.Me 2020 (the canonical Ethereum callback-class exploit, ~$25M) is the closest cross-standard reference. T1.007 promotion to observed will follow the first per-incident exploit with public on-chain forensic disclosure; contributors with such disclosures should submit them via PR.

For OAK's broader cohort coverage, this case + the Solana PD burn-on-buy cohort (examples/2024-09-solana-permanent-delegate-burn-on-buy-cohort.md) + the cross-chain honeypot cohort (examples/2024-02-honeypot-token-cohort-cross-chain.md) + the Hyperbridge counterfeit-mint case (examples/2026-04-hyperbridge-merkle-proof-counterfeit-mint.md) collectively populate the fake / honeypot / malicious-by-design smart contract cohort at v0.1. T1.007 is the cohort's Maturity: emerging slot; T1.002 / T1.006 / T6.005 / T6.006 are the observed / stable slots. The cohort-level coverage motivates the v0.x sub-Technique proposals in TAXONOMY-GAPS.md.

Techniques demonstrated (2)