Cowrie Research

privileged-message-dispatcher-abuse

13 min read

Privileged Message Dispatcher Abuse / Arbitrary External Call

  • Name: Privileged message dispatcher abuse / arbitrary external call
  • Category: exploit pattern / privileged-dispatch failure / arbitrary external call / selector-collision abuse
  • Summary: Some protocols centralize cross-chain execution, upgrades, settlement, or business logic behind a dispatcher contract that downstream contracts trust as an owner or root operator. If attackers can influence the dispatcher’s target contract, method selector, or calldata more than designers intended, they can repurpose that executor into a privileged call primitive against contracts that were never supposed to be directly reachable. The protocol is not tricked into executing unknown code; it faithfully executes the wrong call with legitimate internal authority. The sharp distinction from many bridge exploits is that the message may be authentic enough to arrive at the dispatcher; the break happens because the dispatcher itself is overpowered and under-constrained.
  • What it is:
    • A generic executor, bridge manager, router, message receiver, or upgrade helper can call into other contracts on behalf of the protocol.
    • Sensitive downstream contracts treat that executor as owner, operator, manager, or some equivalent root authority.
    • Untrusted message content, user input, or loosely validated metadata influences the target address, function selector, or calldata shape.
    • The executor lacks a strict allowlist or message-type boundary that limits which contracts and selectors it may reach.
    • The attacker turns that generic call surface into an authorization bypass against a more privileged contract.
  • Typical preconditions:
    • The executor already has broad authority over config, signer-set, vault, bridge, or upgrade contracts.
    • Target contract selection, method naming, or calldata composition is at least partially attacker-controlled.
    • Selector derivation truncates hashes to 4 bytes, or the call path otherwise permits ambiguous ABI interpretation.
    • Downstream admin functions are simple enough that extra trailing calldata, selector collisions, or partially decoded parameters still let them succeed.
    • There is no second independent check that says this message type is only allowed to touch business contract X with method Y.
  • Common vulnerable surfaces:
    • bridge message managers and cross-chain business-call executors
    • upgrade executors that can call any implementation or initializer target
    • routers or multicall hubs that inherit more authority than ordinary users realize
    • operator-owned config stores that sit behind a generic message bus
    • contracts that derive selectors from untrusted method strings or other non-canonical metadata
  • Exploit sequence:
    1. The attacker finds a dispatcher path that can reach an unexpected target contract or unexpected selector.
    2. They craft message metadata, calldata, or a selector collision so the dispatcher calls a privileged downstream function.
    3. Because the dispatcher already has owner / operator authority, the downstream contract accepts the call.
    4. The attacker uses that call to rewrite signer sets, operators, upgrade pointers, vault permissions, or other control-plane state.
    5. A second-stage action drains assets, forges approvals, or installs lasting control using the newly rewritten authority.
  • Variants:
    • Selector-collision dispatch — an attacker-chosen method string or payload hashes to the 4-byte selector of a privileged function.
    • Arbitrary-target executor abuse — the protocol intended a dispatcher to call one business contract, but insufficient validation lets it reach any contract it owns.
    • Trailing-calldata parameter smuggling — the dispatcher encodes extra arguments, but the downstream function decodes only a prefix and ignores the rest.
    • Owner-through-owner reach-through — contract A is allowed to call contract B for ordinary operations, but B also contains admin setters, so compromising A’s call discipline compromises B’s root authority.
    • Message-bus overreach — a bridge or messaging layer exposes too much business-call flexibility on the destination side.
  • Detection heuristics:
    • Inventory every contract owned by a dispatcher, bridge manager, executor, or router; that ownership graph is part of the attack surface.
    • Ask whether message schemas are typed and canonical, or whether arbitrary method names and raw payloads flow into low-level .call.
    • Recompute 4-byte selectors for attacker-influenced method strings and compare them against admin / upgrade / signer-management selectors.
    • Check whether downstream contracts would still accept the call if extra ABI words were appended after the expected arguments.
    • Treat generic execute powers as root-key code even when they are framed as middleware.

Three destination-side authority promotions healthy bridges should not collapse

  1. Did some message become authentic enough to arrive at the dispatcher at all?

    • This is the bridge-truth question: right source domain, right emitter, right route, right proof or quorum.
    • Many privileged-dispatch incidents do not primarily break here. Poly’s message-execution lane was dangerous because authentic-enough traffic could still overreach once it landed.
    • The weak starting fact is only something got admitted to the destination-side executor.

  2. Did that admitted message count as one bounded authority class for this exact route?

    • This is the typed-intent question: ordinary settlement, mint completion, refund, admin rotation, upgrade, emergency pause, migration, or recovery.
    • The decisive failure in this family is usually that the dispatcher never keeps this promotion explicit. Business message that may call something silently inherits admin message that may rewrite bridge truth.
    • The dangerous jump is from authentic enough to dispatch to canonical permission to exercise this much control-plane meaning.

  3. Did that admitted authority class still deserve this much downstream reach and live release budget right then?

    • This is the bounded-release question: which targets, which selectors, which assets, and which value budget that lane deserved under the current route mode.
    • Even a legitimate admin or recovery lane should usually arrive with narrower destination reach and smaller live custody budget than ordinary healthy-mode settlement.
    • The last promotion is from this authority class is real to this authority class may still touch root contracts or custody at near-ordinary speed and scale.
  • Defenses:
    • Replace generic target-and-method dispatch with explicit message types and per-target / per-selector allowlists.
    • Keep business executors and admin-state owners separate; a message processor should not also be the owner of signer-set or upgrade-control storage.
    • Avoid deriving function selectors from untrusted strings, especially when the result is only checked at the 4-byte selector level.
    • Minimize low-level .call usage for privileged paths, and reject messages whose ABI layout does not exactly match the expected target function.
    • Review ownership graphs during audits: what can this executor call as owner? matters as much as can outsiders call the executor?.

What sound design looks like

  • A bridge should commit one narrow executable meaning per message type. Business action, admin rotation, upgrade, vault release, and emergency pause should not all share one generic call this target with this selector envelope. Bridge truth as a single security object is the broader companion for that one authenticated message, one bounded meaning discipline.
  • Message execution authority should terminate at the business surface it was meant to reach. If an executor exists to process ordinary settlement or application calls, it should not also sit as owner, operator, or admin over signer-set, upgrader, or custody-root storage.
  • The safest dispatcher validates typed intent before execution: expected route, expected target, expected selector, expected argument count and layout, and expected authority class. A healthy bridge should be able to say not only this message is authentic, but also this admitted message is only allowed to become this one bounded authority class, and this authority class only carries this much destination reach and live release budget under the current route mode.
  • Downstream privileged contracts should remain skeptical even of trusted internal callers. Owner-only setters for keepers, validators, upgrade pointers, or vault controllers should still demand a dedicated admin path rather than being reachable through the same executor that handles routine cross-chain business traffic.
  • Bridge message execution should be blast-radius bounded. Even if one dispatch path is misrouted, caps, pauses, delay windows, and authority separation should keep wrong privileged call from immediately becoming rewrite bridge truth and empty custody.

Failure-prevention checklist

  • Define explicit message types and bind each one to a fixed target contract, fixed selector set, fixed calldata schema, and stated healthy-mode versus degraded-mode reach and budget.
  • Separate business-call executors from control-plane owners. A dispatcher that processes routine bridge traffic should not own keeper-set storage, upgrade beacons, token minters, vault admins, or emergency-role registries.
  • Reject attacker-influenced selector derivation. If a route must derive selectors dynamically, prove the derived selector is drawn from a closed allowlist and that no equivalent admin selector is reachable by collision or alternate encoding.
  • Validate exact ABI layout, not just prefix compatibility. Require expected argument count, static/dynamic field placement, and total calldata length so trailing-parameter smuggling cannot turn one call shape into another.
  • Review ownership graphs as first-class security boundaries. Inventory every contract the dispatcher can call directly, every contract it owns, and every contract owned by those owned contracts.
  • Treat internal .call surfaces as root-key code when they run with protocol authority. Low-level call helpers should carry the same review, testing, and change-control bar as signer-set or upgrader code.
  • Put bounded-release controls under any route that can touch privileged state indirectly: pause authority, delayed admin changes, per-asset caps, and rapid rollback for configuration paths.
  • Add tests for selector collisions, ambiguous method metadata, overlong calldata, alternate target addresses, and owner-through-owner reachability.
  • Keep admin-state mutation on a distinct message lane with distinct authentication, review, and telemetry instead of letting ordinary bridge traffic share the same execution primitive.
  • Log which typed message, authority class, target, selector, and downstream authority path each execution consumed so incident response can reconstruct whether a dispatch path crossed its intended boundary.

Audit prompts

  • What exact contracts can this dispatcher call, own, or indirectly control as owner, operator, or upgrader?
  • Does any message path let untrusted data influence target address, selector bytes, method-name hashing, calldata shape, or delegate execution semantics?
  • If the dispatcher is supposed to call only business logic, what prevents it from reaching signer-set storage, vault-admin paths, token minters, or upgrade controllers?
  • Could a downstream privileged function succeed if the caller supplies the right selector prefix plus extra trailing calldata words the callee ignores?
  • Are selectors derived from strings, hashes, enum conversions, or other metadata that an attacker can shape into a 4-byte collision with an admin function?
  • Do route validations prove both authentic message and authorized intent, or do they stop after authenticity and trust the dispatcher not to overreach?
  • For each authority class the dispatcher may exercise, what exact destination reach and release budget does that lane have in healthy mode, and what narrower budget does it fall back to under degraded or recovery modes?
  • Which admin or custody-changing actions remain reachable if the dispatcher itself is honest-but-overpowered rather than fully compromised?
  • During upgrades, what test proves no newly owned contract or newly whitelisted selector silently expands the dispatcher’s authority graph?
  • If one misrouted privileged call lands, what exact control stops immediate keeper rotation, upgrader replacement, or uncapped asset release before operators intervene?
  • Can the protocol explain its execution boundary in typed terms, or only as the bridge can call arbitrary targets but we think the messages are safe?

Lessons that should already be standard

  • Authenticity is not authorization. A bridge can receive a real message and still be catastrophically wrong about what authority class that message is allowed to become.

  • Generic executors are dangerous exactly when they look like harmless middleware. Once downstream contracts trust them as owner or operator, parsing and dispatch become custody code.

  • Selector collisions are not cute edge cases when the caller already has protocol authority. Four bytes are enough to lose the bridge if the target surface is too privileged.

  • Owner-through-owner graphs are real attack surfaces. A dispatcher that owns the contract that defines keepers or upgrade rights is already one design mistake away from root-authority seizure.

  • ABI prefix compatibility is a security boundary. If a callee happily ignores trailing words, then almost the right calldata may still be an admin primitive.

  • Admin mutation should travel on a different lane from ordinary business execution. Reusing one cross-chain executor for both is a convenience trade that turns dispatch bugs into bridge-wide insolvency risk.

  • Correct authority class and correct release budget are different destination-side promotions. A route can be right that this is an admin or recovery lane and still be dangerously wrong if that lane inherits near-ordinary custody reach by default.

  • Bridges should assume misexecution can happen and bound it. If one bad dispatch can instantly rewrite authority and empty custody, the protocol has concentrated too much power in one helper.

  • High-signal incidents:

    • keeper-replacement exploit (2021-08-10) — a cross-chain business-call executor owned the keeper-set storage contract, so a selector collision turned message execution into keeper rotation and then into nine-figure bridge drains.

Where this pattern stops

  • Stay here when the decisive mistake is that a generic dispatcher, bridge executor, or message bus already had too much downstream authority and the attacker only needed to steer it toward the wrong privileged call.
  • Re-route to bridge-verification-failure when the more important claim is that the bridge accepted a forged proof, forged signer quorum, poisoned root, or other counterfeit authenticity object before any dispatch logic mattered.
  • Re-route to arbitrary-call-token-approval-drain when the generic executor mainly monetizes standing user approvals rather than protocol-owned admin authority.
  • Re-route to privileged-upgrade-abuse when the decisive second-stage primitive is direct upgrader control or malicious implementation replacement, rather than overbroad target / selector reachability inside an executor.
  • Re-route to approval-by-address-mutable-code-execution when the target was allowed because of stale address-based trust and later resolved to different code, even if the call surface itself was otherwise narrow.
  • Re-route to account-confusion-root-of-trust-substitution when the core failure is that the protocol authenticated the wrong root object or account graph, not that a legitimate dispatcher could reach too much power.

Internal linkages

Control surface

Graph View

Backlinks