New Market Trading Exploit — Payload-Forgery Drain via Axelar "Express" Path on a Gnosis Safe Module

Source & credit. Exploit reproduction, trace data, and analysis adapted from DeFiHackLabs by SunWeb3Sec — an open registry of reproduced on-chain exploits. Standalone Foundry PoC and full write-up: 2026-05-NewMarketTrading_exp in the evm-hack-registry mirror. Upstream DeFiHackLabs PoC: src/test/…/NewMarketTrading_exp.sol.

Vulnerability classes: vuln/access-control/missing-auth · vuln/bridge/message-spoofing · vuln/logic/missing-check

Reproduction: the PoC compiles & runs in an isolated Foundry project at this project folder (the umbrella DeFiHackLabs repo contains several unrelated PoCs that do not compile together, so this one was extracted). Full verbose trace: output.txt. Verified vulnerable source: contracts_modules_SquidRouterModule.sol.

Key info#

TL;DR#

SquidRouterModule is a Gnosis Safe module that lets a Squid/Axelar cross-chain message drive swap/approve actions on a Safe that has installed the module. It inherits Axelar's AxelarExpressExecutableWithToken, which exposes a permissionless "express" fast path, expressExecuteWithToken(...) (AxelarExpressExecutableWithToken.sol:111-148). The express path is meant for off-chain relayers to front the bridged tokens and be reimbursed later once the real cross-chain message clears the Axelar gateway — so it deliberately performs no gateway / cryptographic validation of the message.

The module's override of _executeWithToken (SquidRouterModule.sol:142-157) "authenticates" the source only by parsing a caller-supplied sourceAddress string and comparing it to the public squidRouter address. It then decodes the safe and delegate straight out of the caller-supplied payload and executes the requested actions — checking only that delegate holds a permission on safe, never that msg.sender == delegate (SquidRouterModule.sol:159-193, BaseModule.sol:133-149).

So anyone can call expressExecuteWithToken with:

1. amount = 0 → the relayer-fronting safeTransferFrom(attacker, module, 0) costs nothing.
2. sourceAddress = the public Squid router address string → passes the only "source" check.
3. payload = (module, victimSafe, realDelegate, actions) where realDelegate is a genuine, public NMT delegate (0x0f7aAa84...) that already holds APPROVE + SWAP permission on the Safe, and the actions are: ERC20_APPROVE (USDC→Permit2), PERMIT2_APPROVE (USDC→UniversalRouter), and UNI_V3_SWAP_EXACT_IN (USDC → worthless "u", amountOutMin = 0).

The module dutifully drives the victim Safe to approve and swap its entire USDC balance into the attacker-owned Uniswap-V3 pool with zero slippage protection. In this PoC the Safe's 5,805.95 USDC is swapped for 5,612.69 worthless "u" tokens — a 100% loss — with the attacker fronting nothing and producing no genuine cross-chain message.

Background — what the protocol does#

New Market Trading (NMT) is a managed-trading product built on Gnosis Safe modules. A user's Safe installs the SquidRouterModule; a set of NMT "delegates" are granted scoped permissions (APPROVE, SWAP, BRIDGE_DEPOSIT, WRAP, …) on that Safe via a PermissionsManager. The module then performs DeFi actions on behalf of the Safe in two ways:

• Same-chain, via executeSameChainActions(safe, params) (SquidRouterModule.sol:51-56), where the delegate identity is derived from msg.sender (_getDelegate(), BaseModule.sol:144-149).
• Cross-chain, by inheriting Axelar's AxelarExpressExecutableWithToken. A Squid/Axelar bridge message lands in executeWithToken/_executeWithToken, which is supposed to be gated by the Axelar gateway, and the module then runs the bundled actions against the Safe.

The permission set used by this exploit (string constants from Permissions.sol): APPROVE = "APPROVE", SWAP = "SWAP". The supported action bundle types are the ExecuteActionType enum (UNI_V2/V3 swaps, ERC20_APPROVE, PERMIT2_APPROVE, NATIVE_WRAP/UNWRAP).

On-chain immutables at the fork block (from the trace):

The vulnerable code#

1. The permissionless Axelar "express" entry point (inherited, unauthenticated)#

// AxelarExpressExecutableWithToken.sol
function expressExecuteWithToken(
    bytes32 commandId,
    string calldata sourceChain,
    string calldata sourceAddress,
    bytes calldata payload,
    string calldata symbol,
    uint256 amount
) external payable virtual {                                   // ← ANYONE can call
    if (gatewayWithToken().isCommandExecuted(commandId)) revert AlreadyExecuted(); // only a replay guard

    address expressExecutor = msg.sender;
    address gatewayToken = gatewayWithToken().tokenAddresses(symbol);
    ...
    IERC20(gatewayToken).safeTransferFrom(expressExecutor, address(this), amount); // amount = 0 ⇒ free
    _executeWithToken(commandId, sourceChain, sourceAddress, payload, symbol, amount); // NO gateway validation
}

(AxelarExpressExecutableWithToken.sol:111-148)

Compare the authenticated path executeWithToken (lines 45-91 of the same file) which does call gatewayWithToken().validateContractCallAndMint(...) and reverts with NotApprovedByGateway(). The express path is the intended relayer fast-lane: it skips validation by design, on the assumption that a relayer who fronts real tokens is later reimbursed only if the message turns out to be valid. The bug is that the NMT module turns this fast-lane into a fully-authorized command channel.

2. The module's "authentication" trusts caller-supplied strings & payload#

// SquidRouterModule.sol
function _executeWithToken(
    bytes32, string calldata, string calldata sourceAddress,
    bytes calldata payload, string calldata tokenSymbol, uint256 amount
) internal override {
    address srcAddress = Strings.parseAddress(sourceAddress);
    require(srcAddress == squidRouter, InvalidSourceAddress(srcAddress)); // ← compares a STRING the caller passed
    IERC20 token = IERC20(_getTokenAddress(tokenSymbol));
    _processPayload(token, amount, payload);
}

function _processPayload(IERC20 bridgedToken, uint256 bridgedTokenAmount, bytes calldata payload) internal {
    (address module, address safe, address delegate, ActionsExecutionParams memory params) =
        abi.decode(payload, (address, address, address, ActionsExecutionParams)); // ← safe & delegate from payload
    require(module == address(this), InvalidModuleAddress(module));
    bridgedToken.safeTransfer(safe, bridgedTokenAmount);   // sends `amount` (0) to the safe
    _handleActions(safe, delegate, params);                // ← executes attacker's actions
}

(SquidRouterModule.sol:142-175)

3. The permission check validates the delegate, never the caller#

// BaseModule.sol
function _checkPermission(address safe, address delegate, string memory permissionName) internal view virtual {
    require(
        permissionsManager.hasPermission(safe, delegate, _getPermissionEntry(permissionName)),
        PermissionDenied(safe, delegate, permissionName)
    );   // ← asks "does `delegate` have permission?" — `msg.sender` is never compared to `delegate`
}

(BaseModule.sol:133-142)

Each action handler calls _checkPermission(safe, delegate, …) with the payload-supplied delegate (e.g. _handleUniV3SwapExactIn, SquidRouterModule.sol:221-252). Because the attacker names a real delegate that genuinely holds APPROVE+SWAP, every check returns true. The Safe then executes the action via execTransactionFromModule (BaseModule.sol:82-102).

Root cause — why it was possible#

_getDelegate() ties the delegate to msg.sender only in the same-chain path (BaseModule.sol:144-149). On the cross-chain path the module relies on the Axelar gateway to authenticate that the message truly came from squidRouter on a real source chain. But by exposing the express path, the module accepts a message that has had zero gateway validation, while still deriving every trust input (sourceAddress, safe, delegate) from caller-controlled calldata.

Concretely, three composing flaws:

1. An unauthenticated entry that grants full authority. expressExecuteWithToken is external payable virtual with no onlyRelayer/onlyGateway guard, yet it reaches the same _executeWithToken → _processPayload → _handleActions pipeline as a validated bridge message. The express path was meant to front tokens, not to issue authenticated commands.

2. String-compared "source address" is not authentication. require(parseAddress(sourceAddress) == squidRouter) verifies nothing about the caller — the Squid router address is public, and the attacker simply types it in. There is no signature, no gateway approval, no msg.sender linkage.

3. The permission model checks the wrong principal. _checkPermission answers "does this delegate hold permission on this Safe?" The missing invariant is msg.sender == delegate (or genuine gateway validation). Since real delegate addresses and their permissions are public on-chain, the attacker borrows a legitimate delegate's authority without controlling its key.

The single missing line is, on the express/bridge path: require(msg.sender == delegate) (and/or refusing to treat un-validated express messages as authorized commands at all). With amount = 0 the relayer-fronting transfer is free, so there is no capital cost, no flash loan, and no genuine cross-chain message — the attacker just hands the module a fully-formed, self-authorizing command.

Preconditions#

• The victim Safe has installed SquidRouterModule and granted a public NMT delegate the APPROVE and SWAP permissions (true for all 88 affected Safes; delegate 0x0f7aAa84... here).
• The Safe holds a liquid ERC20 (USDC here — 5,805.95 USDC at the fork block).
• A whitelisted UniversalRouter exists (isUniversalRouter == true) so the swap action routes.
• The attacker controls a Uniswap-V3 pool for USDC → worthless token (pool 0x151e90..., token 0xe6Ff0FE...) so the zero-amountOutMin swap dumps the USDC where the attacker can keep it. Note: the attacker's "u" token has an only-tx.origin guard protecting its poisoned pool from third parties — that guard lives in the attacker's token, not in the module, which is why the PoC pranks tx.origin = ATTACKER. The module itself never inspects msg.sender or tx.origin.
• A fresh commandId (so isCommandExecuted == false); any unused 32-byte value works.

No funds are fronted (amount = 0), no flash loan, no gateway message.

Attack walkthrough (with on-chain numbers from the trace)#

All figures below come directly from output.txt. USDC has 6 decimals; the "u" token has 18.

Pool 0x151e90... USDC balance went 163,364.23 → 169,170.19 USDC (+5,805.95), confirming the Safe's USDC landed in the attacker-controlled pool (:138, :155).

Profit / loss accounting#

Diagrams#

Sequence of the attack#

Pool / Safe state evolution#

Where the authentication is missing#

Why each parameter#

• amount = 0, symbol "WETH": the express path's only mandatory transfer is safeTransferFrom(msg.sender, module, amount). With amount = 0 this is a no-op, so the attacker needs no capital and no approval for any bridged token. "WETH" is just a symbol the gateway resolves; its identity is irrelevant when the amount is zero.
• sourceAddress = "0xce16F6...D666": the public Squid router address as a string. It's the only value the module compares, and it is not secret — anyone can read squidRouter (the PoC even asserts MODULE.squidRouter() == SQUID_ROUTER as a sanity check).
• delegate = 0x0f7aAa84...: a real NMT delegate that already holds APPROVE+SWAP on the victim Safe. The attacker doesn't need its key — the module only asks the PermissionsManager whether that delegate has the permission, never whether the caller is that delegate.
• amountOutMin = 0 + attacker-owned pool: removes all slippage protection so the entire USDC balance is dumped into a pool whose other side ("u") is worthless and whose liquidity the attacker controls — they keep the USDC.
• Fresh commandId: isCommandExecuted is the express path's only stateful guard (a replay/ double-spend check for relayers). Any unused 32-byte value passes it once.

Remediation#

1. Authenticate the principal on every authorized action. On any path that runs _handleActions with a payload-supplied delegate, enforce require(msg.sender == delegate) (mirroring the same-chain _getDelegate() semantics), or only accept a delegate proven by a validated gateway message — never a delegate freely chosen by an arbitrary caller.
2. Do not expose the Axelar express path as a command channel. The express fast-lane intentionally skips gateway validation; it should be limited to fronting tokens and reconciled against a later gateway-validated executeWithToken. Override/disable expressExecuteWithToken (and expressExecute) in the module, or route express messages through a holding state that only releases authority once validateContractCallAndMint confirms the message.
3. Stop treating a string-equal sourceAddress as authentication. Source-address verification is meaningful only when the gateway has cryptographically attested the message. A parseAddress(...) == squidRouter string compare on an unauthenticated path proves nothing about the caller.
4. Re-check permissions against the actual caller, not a borrowed identity. The PermissionsManager model assumes the caller is the delegate. Either bind msg.sender to the delegate, or require the delegate to produce a signature/authorization for this specific Safe + action set.
5. Add slippage / sink guards as defense-in-depth. Reject swaps with amountOutMin = 0 or into non-whitelisted pools/tokens, and bound the per-call fraction of a Safe's balance that a single module action can move. These would not fix the root auth bug but would have blunted the 100% drain.

How to reproduce#

The PoC was extracted into a standalone Foundry project (the umbrella DeFiHackLabs repo has several unrelated PoCs that fail to compile under a single forge test build):

_shared/run_poc.sh 2026-05-NewMarketTrading_exp -vvvvv

• EVM version: Cancun is required (foundry.toml sets evm_version = 'cancun') — the Uniswap UniversalRouter uses EIP-1153 transient storage.
• RPC: an Ethereum archive endpoint is required (fork block 25,170,512). The default Infura key in the registry template returned HTTP 401, so foundry.toml's mainnet endpoint was switched to https://eth.drpc.org, which serves historical state at that block.
• Result: [PASS] testExploit() — the Safe's USDC is fully drained (5,805 → 0).

Expected tail:

Ran 1 test for test/NewMarketTrading_exp.sol:NewMarketTradingExploit
[PASS] testExploit() (gas: 324624)
Logs:
  Victim Safe USDC before : 5805 USDC
  Victim Safe USDC after  : 0 USDC
  Safe 'u' token after    : 5612693391509875140579
  USDC drained out of Safe: 5805 USDC

Suite result: ok. 1 passed; 0 failed; 0 skipped

Verified sources downloaded under sources/: SquidRouterModule (Ethereum, v0.8.30), AxelarGateway impl (v0.8.9), UniswapV3Pool (attacker pool, v0.7.6). The worthless "u" token 0xe6Ff0FE0... is unverified on Etherscan. References: rekt.news — https://rekt.news/newmarkettrading-rekt

Sources & further analysis#

Reproductions & code

• Standalone PoC + full trace: 2026-05-NewMarketTrading_exp (evm-hack-registry mirror).
• Upstream DeFiHackLabs PoC: NewMarketTrading_exp.sol.

Alerts & third-party analyses

• DeFiHackLabs incident explorer: search "New Market Trading Exploit".
• Web3Sec X hacked database: search.
• Rekt leaderboard: search.
• Solodit incident search: search.

These dashboards index community alerts tweets, post-mortems, and independent write-ups. Reach them through the protocol name above to cross-check this reproduction against other analyses.