Cowrie Research

pnetwork-pgala-proxyadmin-key-exposure-whitehat-uncollateralized-mint-pancakeswap-pool-drain-2022-11-03

14 min read

pNetwork pGALA ProxyAdmin Key Exposure / Whitehat Uncollateralized Mint + PancakeSwap Pool Drain (2022-11-03)

  • Name: pNetwork pGALA ProxyAdmin key exposure / whitehat uncollateralized mint + PancakeSwap pool drain
  • Date: 2022-11-03
  • Protocol: pNetwork pGALA bridge
  • Chain: BNB Chain + Ethereum
  • Category: bridge verification failure / privileged upgrade abuse / unbacked wrapped-asset mint / proxy-admin key exposure
  • Loss: pNetwork said no Ethereum-side GALA collateral was stolen, but the incident forced a whitehat extraction of 12,977 BNB (about $4.5M then) from the pGALA/BNB PancakeSwap pool and triggered much larger secondary exchange / holder losses as uncollateralized pGALA flooded the market
  • Summary: pGALA on BNB Chain was an upgradeable wrapped-token contract behind a ProxyAdmin whose owner private key had been exposed publicly. That leaked key let an attacker-controlled address seize the ProxyAdmin owner role on 2022-08-28, which in turn meant pGALA could be upgraded or otherwise subverted at any time. pNetwork says it only noticed the compromise on 2022-11-03 while preparing a migration to pNetwork v2. To stop the bridge from becoming a live redemption path for attacker-minted pGALA, pNetwork froze cross-chain processing so the Ethereum-side GALA collateral could not be released. It then deliberately minted 55.6284B uncollateralized pGALA in two batches and sold into PancakeSwap to drain the pool’s BNB before a malicious actor could do the same. The bridge did not lose its locked GALA, but the wrapped token’s credibility and market structure were already broken: a hidden proxy-admin compromise had turned 1 pGALA == redeemable bridge claim into a false assumption long before the public noticed.
  • Trigger / entry point:
    • The BNB-side pGALA token 0x7dDEE176F665cD201F93eEDE625770E2fD911990 was a transparent proxy administered by ProxyAdmin contract 0xF8C69b3A5DB2E5384a0332325F5931cD5Aa4aAdA.
    • SlowMist reported that the owner private key for the ProxyAdmin owner EOA 0xfEDFe2616EB3661CB8FEd2782F5F0cC91D59DCaC had been exposed on GitHub.
    • Using that leaked key, the ProxyAdmin owner role was transferred on 2022-08-28 to 0xB8fe33c4B55E57F302D79A8913CE8776A47bb24C, silently handing an unknown actor upgrade authority over live pGALA.
    • Because the ProxyAdmin controlled the proxy’s admin rail, compromise of that owner meant the pGALA implementation could be upgraded or otherwise manipulated independently of the bridge’s normal mint / burn workflow.
  • Root cause:
    • The decisive failure was not ordinary wrapped-token mint logic; it was that privileged upgrade authority above the pGALA token had become attacker-reachable.
    • pNetwork’s architecture split custody / peg processing from token-admin control, so the bridge collateral on Ethereum could still be paused and protected even while the BNB token contract itself was no longer trustworthy.
    • Monitoring failed to continuously watch the full authority chain. pNetwork later said its alerts covered the token and ProxyAdmin contracts but not the owner of the ProxyAdmin contract, which is why the hostile ownership change went unnoticed for about 70 days.
    • Once that root key was exposed, pGALA supply on BNB no longer proved redeemable claim on locked GALA; wrapped-asset authenticity depended on an already-compromised admin boundary.
  • Exploit path:
    1. pNetwork deployed pGALA behind a transparent proxy whose upgrade authority ultimately depended on ProxyAdmin owner EOA 0xfEDFe....
    2. The plaintext private key for that owner EOA was leaked publicly, creating a latent takeover path over the ProxyAdmin.
    3. On 2022-08-28, the leaked key was used to transfer ProxyAdmin ownership to 0xB8fe33... in transaction 0x133c7676bba99eb8a600dcb70b4c2b1ea81747135be6b2ccf0d0e7c50f31932b.
    4. The new owner then executed upgradeAndCall and upgrade transactions 0x9c11381caf72fc68f62f1f10880c6657b9385a76e9e4755bf13126e5017ab4f7 and 0xc6261b04520ca93dab64a8abe3c30486a515b45710e15e165edcabbea82cbaf3, proving the hostile side held real live admin authority over pGALA.
    5. On 2022-11-03, pNetwork discovered the compromise during maintenance work for the route’s upgrade to pNetwork v2 and concluded that an attacker could mint uncollateralized pGALA or otherwise tamper with the token at will.
    6. pNetwork halted processing of GALA cross-chain operations so newly minted counterfeit pGALA could not be redeemed for the Ethereum-side GALA collateral.
    7. To frontrun any malicious pool drain, pNetwork itself minted two tranches of 27,814,200,000 uncollateralized pGALA and sold them through PancakeSwap, recouping 12,977 BNB into whitehat address 0x6891A233Bca9E72A078bCB71ba02aD482A44e8C1.
    8. Representative whitehat-drain transactions included PancakeSwap-routed BNB inflows 0xa68c18bcf6b7ce8b57b090bd3e3090390cd2f7297cacf930722e2a1fd4c85056 and 0x63d8c1608753851b80c439360b61cbca6d2929c1af40a52cdccb1b612447b671.
    9. The result was not a theft of bridge collateral, but a forced market dislocation: legacy pGALA was openly unbacked, the AMM pool was stripped of BNB, and centralized-exchange / secondary-market users were left dealing with the aftermath of a wrapper that had already lost its trust anchor.
  • What the attacker needed to be true:
    • Upgrade authority over pGALA had to sit behind a single exposed EOA rather than a hardened multisig or revocable key-management boundary.
    • Monitoring had to miss the full admin chain, especially the owner above ProxyAdmin.
    • Downstream venues had to keep treating BEP-20 pGALA as if it were ordinary GALA exposure even after the wrapped token’s admin integrity had failed.
    • The PancakeSwap pool had to hold enough BNB liquidity for counterfeit or whitehat-minted pGALA to extract real value.
  • Technical anatomy worth remembering:
    • This was a bridge incident even though the bridge collateral was not stolen. The core failure was that the wrapped asset’s authenticity boundary broke: pGALA on BNB no longer represented a trustworthy redeemable claim because privileged token-admin control had been captured.
    • It is a useful cousin to Ankr aBNBc, but sharper on the upgrade-root story. The damage started not with public mint abuse itself, but with a hidden compromise of the proxy-admin owner that made public wrapped supply untrustworthy weeks earlier.
    • The whitehat response preserved Ethereum-side collateral while deliberately destroying the remaining market value of legacy pGALA. That tradeoff matters analytically: once the wrapped token had lost canonical admin integrity, preserving the bridge collateral required treating the BNB-side token as already semantically revoked.
    • pNetwork’s later lessons-learned note is a strong reminder that monitor the proxy is not enough; the real control surface is the whole ownership ladder above the proxy.
  • Representative transactions and addresses:
    • pGALA proxy token: 0x7dDEE176F665cD201F93eEDE625770E2fD911990
    • ProxyAdmin: 0xF8C69b3A5DB2E5384a0332325F5931cD5Aa4aAdA
    • Original ProxyAdmin owner: 0xfEDFe2616EB3661CB8FEd2782F5F0cC91D59DCaC
    • Replacement / hostile owner: 0xB8fe33c4B55E57F302D79A8913CE8776A47bb24C
    • ProxyAdmin ownership transfer: 0x133c7676bba99eb8a600dcb70b4c2b1ea81747135be6b2ccf0d0e7c50f31932b
    • ProxyAdmin upgradeAndCall: 0x9c11381caf72fc68f62f1f10880c6657b9385a76e9e4755bf13126e5017ab4f7
    • ProxyAdmin upgrade: 0xc6261b04520ca93dab64a8abe3c30486a515b45710e15e165edcabbea82cbaf3
    • Whitehat recovery address: 0x6891A233Bca9E72A078bCB71ba02aD482A44e8C1
    • Recovery-plan snapshot block S1: BNB Chain block 22745013
  • Response / mitigation:
    • pNetwork froze processing of the GALA bridge so compromised BNB-side pGALA could not be redeemed against Ethereum-side collateral.
    • pNetwork and Gala coordinated exchange notifications and attempted to suspend BEP-20 GALA / pGALA deposits and withdrawals, though pNetwork later said some venue response times were uneven.
    • pNetwork drained the PancakeSwap pool via whitehat mint-and-sell transactions, then planned redistribution of recovered BNB and a new pGALA token backed by the still-intact Ethereum collateral.
    • pNetwork later said it was expanding monitoring to cover the whole authority graph, not just the token and ProxyAdmin contracts, and was moving toward more secure multisig-based key management in pNetwork v2.
    • pNetwork’s later lessons-learned post also argued for exchange-side redeem on deposit handling of wrapped assets so venues do not warehouse large balances of a wrapper whose trust boundary may already have failed.

Pattern tags

  • privileged-upgrade-abuse
  • bridge-verification-failure
  • The sharpest reusable lesson is not wrapped token was overminted; it is that the wrapped token’s upgrade root was compromised above the bridge’s ordinary mint / burn path, so BNB-side pGALA stopped being a trustworthy bridge claim before the whitehat mint even happened.
  • SlowMist’s role breakdown matters: the proxy Admin lane governed upgrades, while DEFAULT_ADMIN_ROLE and MINTER_ROLE lived in the implementation logic. Once the owner above ProxyAdmin was compromised, an attacker could redefine those lower-level mint semantics by swapping logic rather than by first stealing the live minter role directly.
  • The bridge’s peg-processing keys and the token’s upgrade keys were separated, which is why Ethereum collateral could still be protected. But that separation only saved custody after operators actively revoked the market meaning of legacy pGALA.
  • This is also a post-authentication blast-radius case: once a counterfeit pGALA could have been minted by a captured admin lane, the remaining question became how much real BNB exit liquidity and exchange credit lines still treated that counterfeit wrapper as money-good.

Why the exploit worked

  • The decisive failure sat one layer above the token users thought they were trading. pGALA used a transparent proxy, the proxy’s Admin was a ProxyAdmin contract, and that ProxyAdmin was itself owned by an EOA whose plaintext private key was reportedly exposed on GitHub. That meant the real custody boundary for what code defines pGALA? was weaker than users and many downstream venues seemed to assume.
  • SlowMist’s analysis makes the control split explicit: pGALA’s logic tracked DEFAULT_ADMIN_ROLE and MINTER_ROLE, but the proxy Admin lane could still replace the implementation that interpreted those roles. In other words, compromise of the upgrade root was enough to redefine issuance truth without first compromising the current minter workflow.
  • The compromise also stayed latent for roughly 70 days because pNetwork’s monitoring covered the token and ProxyAdmin contracts but not the owner above ProxyAdmin. The route therefore lost wrapper authenticity long before the public incident window started.
  • Once pNetwork noticed the hostile ownership transfer, the bridge faced an ugly but rational security tradeoff. If it left redemption and market trading untouched, a malicious actor could potentially mint counterfeit pGALA, dump it into BNB liquidity, and possibly seek redemption against Ethereum-side collateral. So pNetwork first froze bridge processing, then treated legacy pGALA as semantically revoked and raced to pull the remaining BNB out of PancakeSwap before a malicious mint path could monetize it.
  • That makes pGALA a useful wrapper trust anchor case study, not just an overmint case. The wrapper stopped being economically meaningful at the moment the upgrade root was lost; the later whitehat mint only made that broken reality impossible to ignore.

Detection and audit pivots

  • Monitor the whole authority graph, not just the user-facing proxy and its immediate admin contract. If a third address can still change the admin that changes the code, that address is inside the wrapped asset’s custody boundary.
  • Distinguish bridge collateral safe from wrapped asset still money-good. pGALA shows those can diverge sharply: locked Ethereum collateral can remain intact while the destination-chain wrapper has already lost all canonical meaning.
  • Inventory every route where downstream venues or protocols treat a wrapper as if it were the native asset. Exchange deposit rails, AMM pools, lending collateral admission, and OTC settlement all become part of the blast radius once wrapper authenticity fails.
  • Review role hierarchies across both proxy and logic layers. If auditors only inspect MINTER_ROLE and DEFAULT_ADMIN_ROLE but ignore who can swap the implementation beneath them, they are auditing the wrong authority surface.
  • Treat delayed detection itself as a first-class exploit condition. The pGALA admin capture happened weeks before the public response, which means stale monitoring can silently turn a bridge wrapper into counterfeit supply waiting for a trigger.

Failure-prevention checklist

  • Put upgrade-root authority for wrapped assets behind hardened multisig or equivalent ceremony; a single EOA should not sit one hop above production bridge claims.
  • Monitor the full ownership ladder continuously: token proxy, ProxyAdmin, owner of ProxyAdmin, signer set behind that owner, and any recovery or bootstrap keys that could retake control.
  • Separate bridge collateral safety from wrapper market safety in runbooks. Teams should know exactly when to freeze redemption, when to de-recognize a wrapper, and which venues must be warned before counterfeit supply can monetize.
  • Require privileged changes to commit to exact implementation identity, initializer effects, and any role changes that the new implementation would newly interpret.
  • Maintain venue emergency contacts and test them before an incident. pNetwork’s own writeups show that uneven exchange response time directly shaped downstream damage.
  • Reduce warehouse exposure where possible: exchanges and custodians supporting wrapped assets should prefer redeem-on-deposit or other flows that keep the canonical asset, not a large standing inventory of the wrapper, as the actual balance-sheet object.
  • Model DEX liquidity as real bridge-adjacent collateral. If a compromised wrapper admin can dump into deep pools, those pools are part of the route’s practical loss surface even when canonical collateral sits elsewhere.
  • Rehearse wrapper authenticity failed but collateral not yet stolen incidents specifically. That middle state needs a crisp policy, because the least-bad action may be fast de-recognition rather than attempted parity theater.

Audit prompts

  • Who can change the implementation of this wrapped asset today, and what is the full signer / owner ladder above that power?
  • If the proxy admin were compromised but the bridge redemption keys were not, how quickly could the team freeze redemption and communicate that the wrapper is no longer canonical?
  • Which exchanges, AMMs, lenders, or internal accounting systems still treat this wrapper as equivalent to the native asset, and how much real value could counterfeit supply extract from each before trust is revoked?
  • Does monitoring alert on changes to the owner above ProxyAdmin, or only on proxy-level and implementation-level events?
  • Can a captured upgrade root redefine mint or role semantics without first compromising the currently assigned minter? If yes, are reviewers explicitly modeling that path?
  • What is the response playbook for a route where the safest action may be to intentionally kill market liquidity or deprecate the wrapper before a malicious actor does it for you?
  • If centralized venues keep balances in wrapper form, what mechanism forces or incentivizes rapid conversion back to the canonical underlying asset during stress?
  • Which operator key or bootstrap artifact would still matter after launch even if teams informally think of it as just deployment plumbing?

Lessons that should already be standard

  • Wrapped-asset authenticity is defined by the strongest authority that can still rewrite the wrapper, not by the mint path users see most often.
  • Monitoring one contract deep is not monitoring the real system. Ownership ladders above proxies are part of production security, not metadata.
  • Collateral safe does not mean wrapper safe. A bridge can preserve locked reserves while the market-facing representation has already become counterfeit.
  • Upgrade-root compromise should trigger semantic de-recognition, not just technical curiosity. Once the wrapper’s truth anchor is gone, preserving fake parity usually increases eventual damage.
  • Exchange integration policy matters. Warehousing wrapped assets as if they were the native asset can convert a bridge-wrapper compromise into much broader offchain loss.
  • Whitehat drains are ugly because the design failed earlier. By the time a team is deciding whether to nuke a pool to save collateral, the cleaner prevention opportunities were already upstream in key management, monitoring, and wrapper-risk disclosure.

Why this incident matters

  • It preserves a bridge failure mode that sits between custody drained and market-only wrapper depeg: the bridge backing survived, but the wrapped token had already ceased to be an authenticated claim because upgrade authority was compromised.
  • It is also a good reminder that wrapper incidents do not need a successful malicious redemption to be structurally severe. If the admin rail can print or rewrite the wrapper, the wrapper’s price semantics are already revoked.
  • It is a sharp case for authority graph review: the decisive compromise was not on the token contract people traded or even on the ProxyAdmin contract people might remember to monitor, but on the owner above it.
  • Finally, it is a strong case study in emergency de-recognition: once a bridged token’s authenticity boundary fails, the least-bad response may be to freeze redemptions, quarantine the wrapper, and let the old market die rather than preserve fake parity.

Internal linkages

Control surface

Graph View

Backlinks