Ankr aBNBc Deployer-Key Compromise / Malicious Token-Upgrade Infinite Mint (2022-12-01)
- Name: Ankr aBNBc deployer-key compromise / malicious token-upgrade infinite mint
- Date: 2022-12-01
- Protocol: Ankr liquid staking (
aBNBc) - Chain: BNB Chain
- Category: privileged upgrade abuse / deployer-key compromise / malicious implementation swap / infinite mint
- Loss: about
$5Mwas extracted directly from aBNBc liquidity pools; the same upstream token compromise also enabled a secondary Helio borrowing exploit that REKT and CoinDesk describe at roughly$15.5M, plus another smaller copycat profit path - Summary: Ankr’s BNB liquid-staking receipt token
aBNBcwas not broken by an ordinary user-callable bug in its live implementation. The decisive failure was that a compromised deployer key still controlled the token’s upgrade path. Using that authority, the attacker published a malicious implementation, upgraded the live token to it, and exposed function selector0x3b3a5522, which bypassed caller verification and allowed arbitrary minting. The attacker minted tens of trillions to their own wallet, dumped enough into PancakeSwap and ApeSwap liquidity to extract about$5M, and bridged proceeds toward Ethereum and Tornado Cash. Once the public realized the new mint path was callable, copycats joined in. Downstream, Helio still treated depeggedaBNBcas high-value collateral long enough for a second exploit wave. - Trigger / entry point:
aBNBcwas an upgradeable reward-bearing BNB staking receipt token on BNB Chain.- Ankr’s deployer / upgrade authority on BNB Chain remained concentrated enough that compromise of address
0x2ffc59d32a524611bb891cab759112a51f9e33c0was sufficient to replace production token logic. - The attacker first used the compromised deployer to publish malicious implementation code, then upgraded the live token to that code.
- The new implementation added a mint path identified in public incident reporting as selector
0x3b3a5522, with caller validation effectively bypassed.
- Root cause:
- The real custody boundary for
aBNBcsat in the privileged deployer / upgrader key rather than in the token’s visible day-to-day business logic. - A single-key production upgrade path meant compromise of one operator credential could redefine what
aBNBcmeant onchain. - Ankr’s own after-action added a sharper operational detail: the key compromise was attributed to a malicious code package inserted by a former team member, so the live upgrade boundary failed through a supply-chain-and-insider path before it failed onchain.
- Public post-incident coverage noted that audits had already flagged privileged-account concentration as a meaningful risk, but that risk remained live.
- Once receipt-token logic became attacker-controlled, the token’s downstream solvency assumptions were gone even though the underlying staked BNB itself remained safe.
- The real custody boundary for
- Exploit path:
- The attacker obtained effective control of Ankr’s BNB Chain deployer / upgrader address
0x2ffc59d32a524611bb891cab759112a51f9e33c0. - In funding transaction
0xeb617798207d1c9dc20afbe90e82a44a9ae4b53004ef47f82d3f70eabf69ba72, the compromised deployer funded exploiter address0xf3a465c9fa6663ff50794c698f600faa4b05c777. - In transaction
0xb2cb9e5311610c48aeed89e44549542362692808257f706accdc75f051ac7303, the attacker published the malicious aBNBc implementation. - In transaction
0xcbc5ff4a6c9a66274f9bde424777c3dc862ab576e282fbea3c9c2609ca3e282b, the live aBNBc contract was upgraded to use that malicious implementation. - In example mint transaction
0xe367d05e7ff37eb6d0b7d763495f218740c979348d7a3b6d8e72d3b947c86e33, the attacker invoked the new mint path and issued huge quantities ofaBNBcto their own wallet. - The attacker dumped roughly
20Tof the forged token into available BNB Chain liquidity, collapsing the market price and extracting about$5Min realizable value. - Because the malicious selector was now publicly callable, copycats also minted worthless
aBNBcand joined the exit scramble. - The primary exploiter bridged proceeds to Ethereum and began laundering through Tornado Cash, while the depegged token later became the input for Helio’s secondary stale-price borrowing exploit.
- The attacker obtained effective control of Ankr’s BNB Chain deployer / upgrader address
- What the attacker needed to be true:
- A single compromised deployer key had to retain live upgrade authority over the production
aBNBctoken. - The upgrade path had to allow implementation replacement without a multisig review, timelock, or other independent veto.
- There needed to be enough AMM liquidity in
aBNBcpairs that forged receipt tokens could still be exchanged for meaningful BNB- or stablecoin-denominated value. - Downstream protocols and traders had to keep trusting
aBNBclong enough that the forged supply could be monetized before trading halted.
- A single compromised deployer key had to retain live upgrade authority over the production
- Technical anatomy worth remembering:
- This was not
mint math gone wrong; it wasprivileged implementation swap -> arbitrary mint -> AMM exit liquidity. - The crucial design failure was letting one upgrade credential define the integrity of a liquid-staking receipt token used elsewhere as collateral and market inventory.
- The incident is a strong example of how a wrapped or staked-asset token can lose all credibility even when the underlying custody pool is still intact.
- Helio’s follow-on losses matter because they show how fast downstream lending venues can inherit upstream token-control failures when oracles and pauses lag the initial compromise.
- This was not
- Representative transactions and addresses:
- Compromised deployer / upgrader:
0x2ffc59d32a524611bb891cab759112a51f9e33c0 - Primary exploiter:
0xf3a465c9fa6663ff50794c698f600faa4b05c777 - Funding tx from compromised deployer:
0xeb617798207d1c9dc20afbe90e82a44a9ae4b53004ef47f82d3f70eabf69ba72 - Malicious implementation publication tx:
0xb2cb9e5311610c48aeed89e44549542362692808257f706accdc75f051ac7303 - Proxy upgrade tx:
0xcbc5ff4a6c9a66274f9bde424777c3dc862ab576e282fbea3c9c2609ca3e282b - Example arbitrary-mint tx:
0xe367d05e7ff37eb6d0b7d763495f218740c979348d7a3b6d8e72d3b947c86e33 - Publicly discussed malicious selector:
0x3b3a5522
- Compromised deployer / upgrader:
- Response / mitigation:
- Ankr publicly stated that underlying staked assets were safe even though the liquid receipt token was compromised.
- The team worked with exchanges and venues to halt trading, secured the contracts with a new key, and temporarily paused movement of underlying BNB in the liquid-staking product.
- Ankr later snapshot affected holders, deprecated
aBNBc/aBNBb, and issued replacementankrBNBplus reimbursements. - The post-incident hardening Ankr described included multisig authentication and timelocks for future updates, explicitly acknowledging that the old single-key upgrade path was a critical point of failure.
Pattern tags
- privileged-upgrade-abuse
- signer-quorum-compromise
- stale-price-exploitation
- wrapper-semantic-price-revocation-and-collateral-derecognition
- The decisive exploit primitive was not
broken staking math; it was live authority to redefine the wrapper contract that downstream venues still priced and honored as if its semantics were intact. - Ankr is also a good cross-layer exemplar for
wrapper-definition failure -> AMM monetization -> downstream stale-semantic collateral abuse. The direct token compromise and the Helio follow-on should be remembered as one cascade, not two unrelated incidents. - The note belongs near privileged-upgrade abuse first, but it also matters for operator-custody review because the attacker only needed one deployer credential — plus the software supply chain reaching it — to seize receipt-token definition authority for a live balance-sheet object.
Why the exploit worked
aBNBcusers and integrators were implicitly trusting the upgrade admin to preserve wrapper meaning, yet that authority boundary remained concentrated enough that compromise of one deployer path could replace production token logic immediately. Once that happened, the receipt token’s supply discipline was whatever the attacker-authored implementation said it was.- The exploit monetized because AMM pools, bridges, and downstream lending venues still treated freshly forged
aBNBcas if it were a normal claim on staked BNB. The attacker did not need to redeem the wrapper honestly; dumping counterfeit receipt supply into live liquidity was enough. - The incident also worked because semantic revocation lagged compromise. Even after the upgrade-induced mint flood began, downstream systems did not instantly derecognize
aBNBcas collateral or pricing inventory, which left room for both the direct AMM exit and Helio’s follow-on stale-collateral exploit. - Ankr’s later attribution to a malicious package inserted by a former team member sharpens the lesson: upgrade security is not only
multisig thresholdsecurity. If build, dependency, or operator-workflow compromise can still reach the root upgrade key, the wrapper’s real custody boundary sits in that full operational pipeline.
Detection and audit pivots
- Alert on every upgrade, implementation publication, and admin-funded helper address around receipt-token contracts as a custody event, not a routine release event. For Ankr, the malicious implementation deployment and proxy upgrade were the decisive exploit steps, not the later pool dump.
- Inventory all wrappers whose upgrade path can change mint authority, redemption semantics, or backing interpretation, then map where those wrappers are accepted as collateral, quoted in AMMs, or bridged elsewhere. The blast radius is almost never confined to the original token contract.
- Treat
underlying reserves remain safeas a partial containment fact, not an all-clear. If the wrapper’s issuance semantics are broken, downstream systems that honor the wrapper still need emergency derecognition logic. - Review signer and deployer workflows as part of the same threat model as onchain upgrade rights. Package-supply-chain compromise, blind signing, and retained bootstrap EOAs can all collapse into
attacker can redefine the wrapperif they terminate at the upgrade key. - Ask whether downstream protocols have automated triggers or operator runbooks for
wrapper semantics revoked: collateral pause, oracle haircut, cap-to-zero, or market isolation. Without that layer, upstream wrapper failures reliably become secondary lending or AMM losses.
Failure-prevention checklist
- Remove single-operator or deployer-EOA control from production wrapper upgrades before the asset is widely integrated, and verify the final authority graph onchain rather than assuming the handoff happened operationally.
- Put wrapper implementation changes behind multisig review, timelocks, exact-bytecode commitment, and independent pause / veto powers sized for the speed at which forged supply could hit AMMs and lending venues.
- Separate build and deployment trust from production root authority: harden package provenance, signer devices, dependency review, and deployment ceremonies so a supply-chain compromise cannot silently become live token-definition authority.
- Pre-negotiate downstream containment for critical wrapped assets: exchanges, AMMs, lending markets, and bridges should have a clear path to halt, haircut, or derecognize a wrapper once its issuance semantics are no longer trustworthy.
- Monitor wrapper-supply jumps, unexpected implementation changes, new privileged selectors, and large wrapper mints into fresh EOAs as one unified incident surface rather than separate tokenomics and DevOps dashboards.
- Design collateral integrations so wrapped-asset trust can fail closed: caps near zero on first listing, fast isolation switches, and oracle / collateral decoupling paths that do not assume the wrapper remains money-good until human review finishes.
Audit prompts
- Which exact roles, keys, and deployment workflows can redefine this wrapper’s mint authority, redemption logic, or implementation today, and how many independent failures would an attacker need to capture them?
- If the wrapper were maliciously upgraded right now, which AMMs, lending markets, bridges, and vaults would still honor it long enough for counterfeit supply to be monetized?
- What objective signal would cause integrators to revoke the wrapper’s inherited collateral semantics: implementation hash change, admin rotation, abnormal mint volume, redemption failure, or an explicit upstream incident flag?
- Can responders freeze or quarantine the wrapped asset faster than attackers can dump forged supply into exit liquidity or borrow against it elsewhere?
- Are upgrade approvals pinning exact bytecode, initializer calldata, and post-upgrade invariants, or are operators still effectively approving a mutable
trust us, this is the new wrapperaction? - Does the protocol’s post-compromise playbook distinguish between
underlying pool is safeandwrapper claim is safe, and does every downstream integrator know which side of that line they are actually exposed to?
Lessons that should already be standard
- A wrapped asset is only as trustworthy as the authority that can redefine it.
Backed by real reservesis not a sufficient safety statement when one admin path can change who may mint the wrapper. - Receipt-token upgradeability is downstream systemic risk, not just protocol-local maintenance risk. The moment a wrapper becomes collateral or AMM inventory elsewhere, its upgrade boundary becomes part of other protocols’ solvency model too.
- Supply-chain compromise belongs inside upgrade-custody review. If malicious tooling or dependencies can reach the signer that controls production token semantics, the protocol has not meaningfully separated software delivery risk from asset-definition risk.
- Integrators need explicit wrapper-derecognition machinery. Once wrapper semantics are revoked, keeping the old collateral meaning alive for even a short window is often enough to create a second exploit wave.
Underlying assets safeandwrapper safeare different incident states. Operations, comms, and risk controls should say that plainly and react at the wrapper layer immediately.
Why this incident matters
- It is a clean liquid-staking case of privileged upgrade abuse: the exploit primitive was the right to redefine a receipt token, not a clever user path through the staking logic.
- It also shows how receipt-token compromise can radiate outward. The direct Ankr AMM losses were smaller than the broader ecosystem damage once Helio and other venues kept honoring
aBNBcbriefly after the mint flood. - For corpus purposes, this is a useful reminder that
underlying collateral safedoes not mean the wrapped token is safe. If the wrapper’s upgrade boundary fails, the wrapper is the incident.
Internal linkages
- Core recurring pattern: privileged-upgrade-abuse.
- Adjacent pattern: signer-quorum-compromise — the signer surface here was a single deployer key rather than a multisig, but the lesson is still that privileged operator compromise becomes direct asset-definition authority.
- Downstream contagion incident: helio-protocol-abnbc-stale-bnb-oracle-bad-debt-exploit-2022-12-02 — Helio shows how quickly an upstream wrapper-definition failure can turn into downstream semantic-staleness collateral abuse at another protocol.
- Adjacent downstream pattern: stale-price-exploitation — Ankr itself belongs on the upstream privileged-upgrade side, but it created the counterfeit wrapper inventory that later let downstream venues keep honoring the old BNB price meaning.
- Downstream emergency-state companion: wrapper-semantic-price-revocation-and-collateral-derecognition — the follow-on design question for integrators is how quickly a broken wrapper like
aBNBcshould lose inherited collateral semantics once the upstream upgrade boundary fails. - Positive-design companion: operator-experimentation-separation-from-live-balance-sheet-authority — useful when the design question shifts from
how was the wrapper seized?towhat production controls should have prevented a changed publication surface from immediately retaining full balance-sheet authority downstream.
Control surface
-
The decisive leverage sat in Ankr’s deployer-key custody, production upgrade authority over the
aBNBcimplementation, the software/update pipeline that could reach that key, and the downstream protocols and AMM pools that still treatedaBNBcas meaningful value after the upgrade. -
The failure was not just that too many tokens were minted. It was that one privileged key — and the surrounding developer-package path that could compromise it — still had the right to decide what
aBNBcwas. -
Sources:
- https://www.ankr.com/blog/after-action-report-our-findings-from-abnbc-token-exploit/
- https://rekt.news/ankr-helio-rekt
- https://www.coindesk.com/markets/2022/12/02/defi-protocol-ankr-exploited-for-over-5m
- https://losslessdefi.medium.com/another-day-another-hack-ankrs-5m-exploit-d3989e858f8c
- https://hackmd.io/evXi_Jv-SKyGVO3181JFpQ
- https://bscscan.com/tx/0xeb617798207d1c9dc20afbe90e82a44a9ae4b53004ef47f82d3f70eabf69ba72
- https://bscscan.com/tx/0xb2cb9e5311610c48aeed89e44549542362692808257f706accdc75f051ac7303
- https://bscscan.com/tx/0xcbc5ff4a6c9a66274f9bde424777c3dc862ab576e282fbea3c9c2609ca3e282b
- https://bscscan.com/tx/0xe367d05e7ff37eb6d0b7d763495f218740c979348d7a3b6d8e72d3b947c86e33
-
Last reviewed: 2026-07-21 UTC