OAK-T10.009 — Cross-Chain Token Configuration-Role Capture

Description

Capture of a configuration role belonging to a token's cross-chain deployment — the authority that defines which remote contracts count as legitimate counterparts, or who may reconfigure the token's messaging setup — and its use to issue or move value on remote chains. The captured object is not the application's own admin role and not a signing key; it is a role introduced by the omnichain messaging standard the token is deployed with.

T10.009 is structurally distinct from T10.006 (Cross-Chain Governance Relay Attack), and the distinction is load-bearing rather than pedantic. T10.006 requires a governance action approved on one chain and relayed for execution on another; the attack targets the relay's verification of that governance message. In T10.009 nothing is relayed and no governance decision exists. The attacker takes a configuration role directly on the deployment that holds it and then uses the messaging standard exactly as designed. Mapping these cases to T10.006 obscures the actual control surface and points defenders at proposal-verification logic that was never involved.

It is equally distinct from T9.004 (Access-Control Misconfiguration), which describes the reachability flaw — a role callable by someone who should not reach it — but not what makes this class consequential. The two compose: T9.004 is usually how the role is obtained, T10.009 is what the role is and what it buys. What it buys is the token's cross-chain identity: the ability to declare what a legitimate peer is, or to reconfigure messaging authority, and therefore to make remote chains accept issuance that the canonical deployment never backed.

Three properties recur and define the class:

• The role is not perceived as part of the token's security model. owner, minter, and pauser are audited as a matter of course. delegate and peer arrive with the integration, are frequently set once at deployment by whoever did the wiring, and sit outside the scope of an audit that predates or excludes the omnichain integration.
• Blast radius is per-remote-deployment, and the canonical chain is typically untouched. Both anchors ended with the operator halting bridging rather than pausing the token, because the canonical supply was never at risk. That is also why realised loss tends to understate severity.
• Realised extraction is bounded by remote liquidity, not by any control. Captured issuance authority is effectively unlimited; what the attacker keeps is whatever the destination pools will absorb. This gap is an accident of market depth and must not be recorded as a mitigation.

Observed indicators

• A setPeer / setDelegate / equivalent configuration call on a token's remote deployment from an address that is not the documented administrator, or from the token contract's own context via a callback.
• A remote deployment whose configured peer set includes an address with no corresponding canonical deployment, or whose delegate differs from the delegate on sibling chains.
• Unbacked issuance on a remote chain with no matching lock, burn, or send event on the canonical chain — the supply invariant across deployments breaks while each individual chain's accounting looks internally consistent.
• A convenience callback on the token itself (approveAndCall, transferAndCall, ERC-1363-style hooks, ERC-777 hooks) that can be induced to issue a call from the token contract's own authority.
• Operator response of halting bridging rather than pausing the token — a strong retrospective signal that the compromise was in the wiring rather than the asset.

Detection signals

• Enumerate configuration roles across every deployment, as one set. The per-chain view is the blind spot: each deployment looks correctly configured in isolation while the cross-deployment graph is inconsistent. Maintain the expected (chain, deployment, peer set, delegate) tuple set as an artefact and diff live state against it continuously.
• Alert on any configuration-role change, unconditionally. These values are set at deployment and legitimately change perhaps a handful of times in a token's life. This is a rare-event signal with an excellent base rate — the opposite of most on-chain detection — and it is available on every chain the token touches.
• Cross-deployment supply invariant. Sum issued supply across remote deployments and compare against locked/burned backing on the canonical chain, on a schedule. This catches the realisation step even when the configuration change was missed, and it is the only check that fires when the attacker has already legitimised themselves as a peer.
• Static review of callback surfaces against configuration authority. Any function that causes the token contract to call an arbitrary target from its own context must be checked against every role that trusts the token contract's address. This is a review question with a definite answer, answerable before deployment.
• Confirm who owns the wiring. In practice the omnichain integration is often done by a different party, or at a different time, than the token deployment. Ask explicitly which review covered the messaging configuration; in both anchors, the honest answer appears to have been none.

Real-world examples

• The Sandbox — Base + BNB Smart Chain — 2026-08-22 — ~$675K realised (~14.75M SAND and ~79.74 ETH) against roughly 14.9B unbacked SAND minted across 400+ transactions, reported at up to $49B face value. Attackers exploited approveAndCall to hijack LayerZero OFT delegate permissions, then minted SAND on Base and BSC with no canonical backing. The Sandbox halted bridging on both chains the same day; canonical supply was untouched and stated impact was under 0.01% of the 3B SAND supply. The clearest anchor for the mint-capacity-is-not-extraction-capacity property. See examples/2026-08-sandbox-sand-layerzero-oft-delegate-hijack-unbacked-mint.md.
• Stake DAO — vsdCRV — 2026-05 — the peer-configuration variant and the first documented case. The attack reshaped the cross-chain authorisation graph rather than exploiting a logic bug in message handling: once a hostile address is an accepted peer, every subsequent message is processed correctly by a correctly-implemented bridge. See examples/2026-05-stake-dao-vsdcrv-layerzero-oft-peer-redirect.md.

Reference implementations

• Configuration-drift monitoring: OpenZeppelin Defender Sentinel / Forta detection bots watching setPeer, setDelegate, setEnforcedOptions and equivalent across all deployment chains; expected-state diffing against a committed configuration artefact.
• Supply-invariant monitoring: Dune / Allium cross-chain supply reconciliation for omnichain tokens — issued-remote versus locked-canonical, on a fixed schedule.
• Pre-deployment: static review of callback surfaces against role holders; timelocks on configuration-role changes; separation of the token's callback surface from its messaging-configuration authority.
• Standard-side: LayerZero, Wormhole NTT, CCIP and Hyperlane all document their configuration roles; none currently require a timelock or multi-party approval on changes to them by default, which is the gap this Technique sits in.

Mitigations

• OAK-M05 (Authority-Graph Enumeration): the primary control. The configuration roles of every remote deployment belong in the authority graph alongside owner and minter; both anchors are cases where they were not.
• OAK-M03 (Continuous Bytecode / Configuration Diff Monitoring): applied to configuration state rather than bytecode — diff live peer/delegate values against the committed expected set.
• OAK-M17 (Time-Locked Governance): a timelock on configuration-role changes converts an instantaneous capture into a window in which the change is observable and revocable.
• OAK-M34 (Pause-by-Default / Emergency Pause): specifically the ability to halt bridging independently of the token — the control that actually bounded both anchors.
• OAK-M11 (Rate-Limiting and Per-Block Caps): per-deployment issuance caps bound realised extraction when the configuration compromise itself is missed.

Citations

• See worked examples for primary citations: the Sandbox 2026-08 case (Blockaid, PeckShield, and operator statements) and the Stake DAO vsdCRV 2026-05 case.

Discussion

The class was promoted on its second independent anchor, three months after the first, and the two cases share no application code, no chain pair, and no entry path — only the standard. That is the argument for separating it: the recurring element is not a bug that keeps being reintroduced but a role that keeps being left out of the threat model.

The deeper reason it gets left out is that omnichain token standards move part of a token's authority model out of the token's own contract and into an integration layer. A team that carefully enumerates owner, minter, pauser and their multisigs can hold a complete and correct picture of the token's permissions while having no view at all of who the delegate is on Base. Both anchors are consistent with this: neither involved a stolen key, and in both the operator's remediation was to sever bridging rather than to regain control of an asset, because the asset had never left.

Contributors documenting future cases should record two things the current write-ups mostly omit: which configuration role was captured, and how it was reachable. That pair is what makes incidents in this class comparable, and it is what distinguishes a genuine T10.009 from a T10.006 governance-relay failure or a plain T9.004 access-control bug. Where realised loss is much smaller than issued supply, record both figures and say which is which — the issued figure describes the authority and generalises to the next deployment; the realised figure describes only this token's liquidity on that day.