Foreword

This report, published by GCSA Web3 Labs ZkSec, discusses arbitrary external call vulnerabilities—where contracts completely delegate the call target and data to the caller—as a core risk facing on-chain authorized funds. Based on archived node data, this report replays 2.1 billion historical transactions, identifying over one hundred contracts with related risks, spanning multiple code families. The report systematically introduces detection methods (historical transaction replay, call parameter tracing, and mutation verification), analyzes the vulnerability's structure and differences between Ethereum/BSC chains, cross-validates with known attacks and detected cases, and finally provides defense recommendations.

1.1 Arbitrary External Call Vulnerability

A contract vulnerable to arbitrary external calls provides a public entry point: the target address and data for the call can be filled in by any submitter, and the contract executes as if it were its own. Normal contracts do not operate this way—the decision of who to call and what data to send is written in the code or limited to a whitelist.

Such entry points are sometimes intentional design choices (batch tools and cross-chain bridges are deliberately opened for general use), and sometimes they are design flaws (the intention was to limit the scope of calls, but verification was missed). Whether it is intentional opening or a verification oversight, as long as the contract holds user authorization or retains funds, the lack of caller restrictions makes the entry point vulnerable to exploitation by unintended callers.

1.2 A case of insufficient target constraints

The MetaAggregatorSwapContract (0xc17b234fad8e40642662f1d2a6cbd1d609e7b9b5) on BSC carries the risk of arbitrary external calls due to insufficient target constraints. Its function is to perform swaps on behalf of users: receiving tokens and calling an external aggregator to complete the transaction.

// Entry point: Anyone can call this function, all parameters come from calldata. `function swapERC20(SwapERC20Params calldata params)` `external nonReentrant { (uint256 amountOut, uint256 fee) = _swapERC20(params); // …… emit TokenSwapped(……)}` `function _swapERC20(SwapERC20Params memory params)` `internal returns (uint256, uint256) { address aggregator = params.aggregator; // Any address bytes memory swapData = params.swapData; // Any bytes // …… uint256 balanceBefore = tokenOut.balanceOf(address(this)); _executeAggregatorCall(swapData, isDelegate, aggregator, 0); uint256 amountOut = tokenOut.balanceOf(address(this)) - balanceBefore; if (amountOut < 0)` minAmountOut) revert InsufficientTokenOutAmount(); // ……}function _executeAggregatorCall( bytes memory swapData, bool isDelegate, address aggregator, uint256 value) internal { (bool success, bytes memory returnData) = isDelegate ? SWAP_TARGET.delegatecall(swapData) : aggregator.call{value: value}(swapData); // The target and code path of CALL or DELEGATECALL are affected by the parameters // ……}

BothaggregatorandswapDataoriginate from the caller, and the contract lacks whitelist verification. In non-delegate mode, the contract invokesaggregatorviaCALL; in delegate mode, the code executes within the context ofSWAP_TARGET. Insufficient target restrictions may broaden the scope of the contract's callable functions; furthermore, the contract also holds user-allocated redemption quotas.

WhileaggregatorandswapDataare controllable, this alone does not preclude arbitrarytoken.transferFromattacks.minAmountOutin the source code is required to be greater than zero. In non-delegate mode, the MetaAggregator callsaggregatorviaCALL, and the caller seen by the token is determined by the actual call chain. Therefore, this case can only be identified as an authorized transfer vulnerability after providing a complete trace, sender, and fund path.

To classify this entry point as an authorization transfer vulnerability, the actual spender, victim authorization, and fund flow must be listed; the current example only supports the lingering balance path. The two paths should be listed separately.

2.1 Vulnerability Scanning System Design

The historical transactions are re-executed one by one to obtain a complete call tree—every call and every parameter is recorded. Then, manipulable points are searched within the tree: a specific parameter in an internal call (who is transferred to, how much is transferred, which contract is called, what data is included). If it can be traced back to the original bytes in the top-level calldata of the transaction, it only indicates that this parameter may be influenced by an external submitter, and further confirmation is needed through mutation replay. These points are replaced one by one and replayed to verify whether the parameters are indeed controllable and whether manipulation can translate into real fund flows.

2.2 Scanning Execution Process

The complete execution flow of a transaction in the code is shown in Figure 1.

2.3 Tracing the Source of Call Parameters

The scanner first checks if the original bytes of the inner parameter can be found in the top-level calldata. If found, it only indicates that the parameter can be influenced by the submitter on the current encoding path; further confirmation is still required through mutation replay.

The scanner performs byte-level matching: if the 32 bytes of the parameter appear directly at the top-level alignment, or if the entire calldata is embedded as a continuous byte string at the top level, it is registered as an internal parameter that can be changed by external parameters, and the offset is recorded; if no match is found, it is marked as "cannot establish parameter source", and this does not determine that the value was calculated internally by the contract. During mutation, the top-level offset is modified, and the process is replayed to verify whether the inner layer follows.

The current implementation does not perform semantic analysis, only byte matching at the EVM layer, thus it can handle both open-source and closed-source contracts. The known gap is that when the contract reassembles calldata in memory, the source of the parameters may no longer be traceable.

2.4 Implementation

The entire system has only one core design: each historical transaction is executed twice in the world state just before it occurs (Figure 2).

The outcome of a transaction depends on the state left by all the previous transactions—the balance seen by the 5th transaction in a block is the balance after the first 4 transactions were executed. Before replaying the 5th transaction, the first 4 transactions are executed one by one into a temporary state layer (PreState), stopping before the 5th transaction begins.

Then, run this transaction twice using this state. The first time, execute it as is, recording the complete process: which contracts were called, how much money was transferred, and which storage was modified. The second time, change the controllable parameters—initiator, recipient, and amount—and execute it again, observing the differences in results. The state is not modified in either run, so different parameters can be tried repeatedly.

After the first attempt, the result is written into the state layer, and the next transaction is processed. In this way, every transaction in a block is executed in the world it saw in that year.

2.5 Eliminating false alarms

The number of records awaiting review from the replay output is in the tens of thousands. It is impossible to review them all manually, and the vast majority are screened out by the production line before they can be reviewed. Each 'x' in Figure 1 marks a reason for being screened out, and some of these reasons are elaborated here.

Address poisoning batches:Phishers contaminate address records with counterfeit currency, zero-value or extremely small transfers. Scanners will see similar patterns such as multiple victims, official token names, and extremely small transfers, so it is necessary to combine token codes, amounts, and call batches for exclusion.

// Batch transfer entry (two selectors in the same code family) transfer(address[] from, address[] to, address token, uint256[] amount) // 0xe19c2253transfer_7211834412884((uint8,address,address,address,uint256)[]) // 0x12514bba// The list of victims is directly written in calldata, and a transaction sends dozens of addresses.

Example:0x184aaf087ca6dd17eb1200dbfbee9f671bd906fc. This family generated hundreds of records in the same round of scanning, including dozens of helpers, and no non-zero balance of the official stablecoin was found.

Counterfeit Token Names: An Upgraded Form of Counterfeit Token Attacks – Token names containing Cyrillic letters or zero-width characters, appearing to be USDT to the naked eye but not in the correct byte order. Mark all such instances.

USDT → 55 53 44 54 (ASCII) USDT → 55 53 44 d0a2 (The last character is the Cyrillic letter Т, U+0422)

Examples:0x9257cf49…f4253and0x6b1b80b4…1ca6cc, are counterfeit USDT/USDC transferred from the same batch of addresses in the poisoning records.

EIP-7702 Replay Restrictions:In this type-4 replay, the original transaction was executed by the original initiator carryingauthorizationList; after switching to the test address and removing the list, the transaction was rolled back. This result only indicates that this replay depends on the original authorization state and cannot be generalized to mean that all EIP-7702 transactions must carryauthorizationList. The scanner retains these records and uses the caller_only and dual variants to distinguish between the actual executable path and the rollback caused by the replay conditions.

Original transaction type-4, carrying authorizationList (account holder's signature) → Execution successful, replay with a different user. Same calldata, initiator changed to test address, no authorization list → Entire transaction reverted.

Accounts using the same bytecode:Multiple addresses running the same bytecode, using the same initiator and aggregation address, and pending records originating from a group of accounts with the same characteristics.

// Common characteristics of a group of accounts: all bytecode points to the same delegate target 0xef0100 + 631af7731569e10b22a0430051cfd5c8930a1656 // Multiple accounts share the same initiator and the same aggregation address

Example:0x001100bd…3ff16and0x043d01a9…669d, the bytecode of the two members is exactly the same.

3.1 Judgment conditions

The vulnerability records identified by the scanner are judged sequentially as shown in Figure 3. Conditions one and two are used to confirm the controllability of parameters and the success of the simulation execution; condition three only distinguishes the source of funds: when the payer is the authorizer, it is marked as authorization abuse; when the funds come from publicly available liquidity, it is marked as public arbitrage. The subsequent review of the two types of records is different and cannot be directly equated with real vulnerabilities.

3.2 AI Review

The records to be reviewed by the scanner are automatically verified by AI (Figure 4). The AI reads the original transaction's call and fund flow, and replays them by changing the initiator and payee respectively. A successful simulation only proves that the transaction can be executed after the parameters are replaced; if the evidence of the source of funds, authorization relationship, or call chain is insufficient, the record is marked as "insufficient evidence, pending manual review" and is not automatically identified as a vulnerability.

The AI review results are written back to the panel (Figure 5). Figure 5 shows the five-stage chain of evidence, tags, notes, and simulated number for a single record; it does not show the global tag count.

4.1 Detection of Known Attack Transactions

Seneca Protocol Chamber is used to verify vulnerabilities detected by scanners: the event has been publicly analyzed, and the relevant call patterns also appear in the scan results.

Seneca Protocol was attacked on February 28, 2024, resulting in losses of millions of dollars. BlockSec, SlowMist, and Rekt analyzed the incident. The affected contract address was0x65c210c5…91f06, and itsChamber.solsource code has been verified by Etherscan. The PT-weETH replay transaction corresponding to Figures 6 and 7 is0x6da8f7cb…e820d, and the call target is clone0xbc83f271…7c05.0x23fcf9d4…01286is another PT-rsETH transaction and should not be confused with the figures.

The vulnerable code is as follows, with irrelevant parts omitted:

// Entry point: Anyone can call this function. All three array parameters come from calldata. `function performOperations( uint8[] calldata actions, uint256[] calldata values, bytes[] calldata datas) whenNotPaused external payable returns (uint256 value1, uint256 value2) { // …… } else if (action == Constants.OPERATION_CALL) { (bytes memory returnData, uint8 returnValues) = _call(values[i], datas[i], value1, value2); // ……}function _call(uint256 value, bytes memory data, ...) internal returns (bytes memory, uint8) { // The caller provides the target address and calldata, which is used directly after the contract is decoded. (address callee, bytes memory callData, ...) = abi.decode(data, (address, bytes, ...)); // callee is only checked by the blacklist. require(!blacklisted[callee], "Chamber: can't call"); // Pass` `callee.call` executes an external call; the caller seen by the token depends on the current call frame. `(bool success, bytes memory returnData) = callee.call{value: value}(callData); require(success, "Chamber: call failed"); return (returnData, returnValues);}`

This falls into the same category of external call risk as the MetaAggregatorSwapContract in Section 1.2: the caller encodescalleeandcallDatainto the top-levelcalldata, which Chamber decodes and uses directly. In this historical state, Chamber retains the ERC-20 authorization granted by the user for the managed position, therefore further verification of the actual sender, the victim's authorized object, and the fund path is needed to determine if it is an authorization transfer vulnerability.

The scanner replays the transaction, recording the complete call tree usingcall_tracer. Within the Chamber's internal call frame, it locatescallee.call(callData)and confirms that bothcalleeandcallDatacan be traced back to the top-level `datasparameter. The system registers these as manipulable points, replaces the corresponding recipient address in the top-levelcalldatawith the test address, and replays the transaction on the same historical state. The transaction executes successfully, and the test address receives PT-weETH; evidence of the funding source and call chain is recorded separately.

Figure 6 shows the Invocation Flow Diff for this PT-weETH replay transaction, and Figure 7 shows the corresponding Fund Flow Diff; the two figures together present the differences in invocation and funds before and after the recipient was replaced.



thirdweb Pay UniversalGatewayV1 (2025, Ethereum) – Public Event Cross-Validation

ThirdWeb's payment gateway0x81d57dd01a15bc1c19563693902df621500d4d2aalso appeared in the scan results. ThirdWeb's public report confirmed that the old contract had authorized balance risks and has been deactivated.

There is no directly verifiable source code for this historical implementation. The specific relationship between signature binding, fake token address, andcallDataneeds to be aligned with the proxy implementation and transaction trace of the corresponding block; the current reference source code cannot replace the historical implementation as the basis for conclusions.

The historical call data in this case includes combinations of token addresses, forwarding data, and authorized balances. The current material is insufficient to determine that "fake token addresses bypassing deductions" is the root cause of this historical implementation; it will not be considered a confirmed mechanism until the corresponding block's implementation code and complete trace are obtained.

5.1 Risk paths detected by the scanner

The evidence in the following cases varies: some come from historical transaction replays, while others are supported by source code, audits, or incident reports. Each section will only evaluate the listed evidence and distinguish between scan results and external materials.

The case status is based on the block status of the referenced transaction or the specific query time; whether the balance, authorization, and contract are still callable is not directly derived from historical transactions to determine the current status.

1. Maker Multicall2: A batch executor without a caller whitelist

0x5ba1e12693dc8f9c48aad8770482f4739beed696

// Official contract, deployed in 2021, source code publicly available. function aggregate(Call[] memory calls) public returns (uint256 blockNumber, bytes[] memory returnData){ blockNumber = block.number; returnData = new bytes[](calls.length); for (uint256 i = 0; i < calls.length; i++) { (bool success, bytes memory ret) = calls[i].target.call(calls[i].callData); // No caller whitelist require(success, "Multicall aggregate: call failed"); returnData[i] = ret; }}

BothtargetandcallDataoriginate from the caller. The contract lacks a caller whitelist check, but still verifies the success of the underlying call. It is a general-purpose batch executor; the risk depends on whether the user has authorized this executor with tokens. The authorization and funding paths in the sample presented in this article should be verified on a transaction-by-transaction basis.

II. THORSwap TSAggregatorGeneric: Incomplete target constraints

0x0ccd5dd5bcf1af77dc358d1e2f06ee880ef63c3c

function swapIn( address router, address vault, string calldata memo, address token, uint amount, address swapRouter, // Call target provided by parameter bytes calldata data, // Call data provided by parameter uint deadline) public nonReentrant { // Only disables TTP (THOR's token proxy) require(swapRouter != address(tokenTransferProxy), "no calling ttp"); tokenTransferProxy.transferTokens(token, msg.sender, address(this), amount); token.safeApprove(address(swapRouter), amount); (bool success,) = swapRouter.call(data); // Other targets can still call require(success, "failed to swap"); // ……}

The current source code only excludes TTPs and does not whitelistswapRouter, so token contracts can still be targets. Historical state replays show that callers can pointswapRouteranddatato token transfer paths; whether this constitutes an abuse of authorization requires verification of the sender, authorizer, and source of funds.

III. Symbiosis MetaRouter: Arbitrary call data across links

0xf621fb08bbe51af70e7e0f4ea63496894166ff7f

metaRouteretrieves the user-authorized token from the gateway and checks ifrelayRecipientis not the gateway and if the target address contains code. Then, the source code directly callsrelayRecipientusingotherSideCalldataprovided by the caller; no whitelist is established based on the function selector.

The byte content ofotherSideCalldatais not whitelisted according to the function selector; the target address is only constrained by the gateway address and code existence checks. In transactions detected by the scanner, this parameter containsUSDT.transferFrom; to determine if it is an authorization abuse, the sender, authorizer, and fund recipient in the transaction must be listed item by item.

IV. LayerZero LZMultiCall: Authorization Misalignment and Unsigned Execution Entry Point

0x5528cf58feb8fbfce94f43b33240fffb1312bde3

// The contract provides both signed and unsigned execute overloads: function execute( Call[] calldata _calls, bytes32 _quoteId) public payable virtual { uint256 nonce = nonces[msg.sender]++; _executeCalls(_calls, msg.sender); emit Executed(msg.sender, _quoteId, nonce);}function _executeCalls(Call[] calldata _calls, address signer) internal { for (uint256 i = 0; i < _calls.length; ++i) { if (_calls[i].target == address(TRANSFER_DELEGATE)) { _handleTransfer(_calls[i].data, signer); } else { _handleCall(_calls[i].target, _calls[i].data, _calls[i].value); } }}

The original verification transaction uses a two-parameter, unsigned entry point, not the overload with_signature. This entry point usesmsg.senderas the signer; it only checks iffromof `transfer` equals the signer when the target is `TransferDelegate`. If the call list directly uses the token contract as the target and puts it intotoken.transferFrom(受害者, 自己, 金额)`, the code will use the generic_handleCall, with `LZMultiCall` as the sender to initiate the transfer.

LayerZero's normal workflow should delegate authorization to TransferDelegate; if the user directly authorizes LZMultiCall, the exposed unsignedexecutemight consume that quota. This risk stems from the misalignment between the authorized object and the general forwarding path, and does not involve signed entry points.

V. Third Web Pay Universal Gateway V1: Scope of Evidence

0x81d57dd01a15bc1c19563693902df621500d4d2a

This case has been cross-validated as a public event in section 4.1. Public reports confirm that the old contract had authorized balance risks and has been deprecated; the specific relationships between signature bindings, token addresses, andcallDatain the historical implementation need to be aligned with the proxy implementation and transaction trace of the corresponding block. This article does not use the currentUniversalBridgeV1reference source code to replace historical implementations to draw conclusions.

VI. BSC BnbSettler: BASIC Arbitrary Call Consumption and Misauthorization

0x4c6f446dd88fd1be8b80d2940806002777dc12a2

This is the BSC deployment of 0x Protocol Settler. The risk entry point consists of publicly accessibleexecuteandBASICactions; the transfer path enters the token contract through these actions.

// Sample code, omitting action dispatch and settlement, cannot replace the complete source code function execute( AllowedSlippage calldata slippage, bytes[] calldata actions, bytes32) public payable takerSubmitted returns (bool) { // Actions are provided by the caller, dispatched here in BASIC // takerSubmitted only records the payer, does not authenticate the caller }function basicSellToPool( IERC20 sellToken, uint256 bps, address pool, uint256 offset, bytes memory data) internal { if (_isRestrictedTarget(pool)) revert ConfusedDeputy(); // Only restrict Permit2 (bool success, bytes memory returnData) = payable(pool).call(data); if (!success) { assembly { revert(add(returnData, 32), mload(returnData)) } } if (returnData.length == 0 && pool.code.length == 0) revert InvalidTarget(); // Target and calldata Controllable

If a user directly authorizes Settler with ERC-20, the caller can fillpoolwith a token contract and compiledataintotoken.transferFrom(受害者, 自己, 金额)`. Settler initiates the call as itself, and the token will be executed according to this authorization. Historical replays also show that the contract has outstanding balances with the recipient potentially change; these two paths should be accounted for separately.

The table categorizes vulnerabilities according to their primary exploitation premises; "Vulnerabilities detected by scanning," "Confirmation through historical replay," and "Cross-verification of publicly disclosed events" are not at the same level of evidence.

These cases involve different types of evidence: some have historical transaction replays, while others only have source code or public reports. What the scanner can directly verify is whether changing the top-level controllable parameters can still direct funds to the test address under the corresponding historical conditions; other conclusions require separate annotation of the source and scope of evidence.

5.2 Summary of Vulnerability Records

The scanner aggregated over 400 vulnerability records on Ethereum and BSC, involving more than 300 addresses. The same address may correspond to multiple detection records, and the addresses also include the EIP-7702 delegated account.

Ethereum records are primarily concentrated in Maker Multicall2; BSC records are distributed across more addresses, with fewer records corresponding to a single address. Other records involve contracts such as CallDataExecutor, UniswapInterfaceMulticall, SquidMulticall, and 0xSettler. See Appendices A and B for a complete list of addresses.

5.3 Lynx: Trading Analysis and Simulation Platform

Lynx is our self-developed trading analysis and simulation platform, supporting Ethereum and BSC, and its interface is compatible with standard JSON-RPC. The replay verification and fund flow comparison in this article were performed using Lynx. The platform supportseth_callsimulation based on the historical state of archive nodes, allowing replacement of the initiator, modification of calldata, or overwriting of account balances.

Lynx obtains the call tree throughdebug_traceCalland the corresponding tracer, recording the call target, calldata, and return value for the scanner to trace the source of parameters; the interface also displays storage changes. The platform also generates fund flow diagrams for the original transaction and the simulated transaction respectively, comparing the source, destination, and amount of assets. Figures 6 and 7 in Section 4.1 show the differences in the call process and fund flow, respectively, and Figure 8 shows the call tree interface.

Each simulation result is saved with a unique number, which can be reviewed by the number.

Conclusion

This paper scanned over one hundred vulnerable contracts from 2.1 billion historical transactions, covering infrastructure, cross-chain routers, payment gateways, and utility contracts. Some of these vulnerabilities were confirmed through historical state replay; Seneca and thirdweb provided independent public events for cross-validation.

In the reproduced cases, the authorized limit may still exist after the balance changes; therefore, monitoring the existing authorized limit can supplement balance event monitoring. This conclusion cannot be extrapolated to all cases.

Defense recommendations:

Users: Revoke authorization after use, or switch to an authorization scheme that supports expired signatures (such as Permit2). Before authorization, confirm that the sender corresponds to the expected execution entry point of the protocol; if the protocol is forwarded through a proxy or Permit2, also verify the actual sender, target contract, and quota.

Protocol developers: Any external call entry point should restrict the target and selector/data; the signature forwarding entry point should bind the signature content to the caller and receiver. Audit all call paths when patching; historical patches for THORSwap only excluded one target, other targets still need to be checked.

Industry applications: Authorized stock can be included in continuous monitoring, recording changes in the sender, authorizer, block status, and balance. This article demonstrates historical replay; continuous tracking is not within the scope of this article. (GCSA Web3 Labs ZkSec)

Appendix A: Ethereum Vulnerability Records and Corresponding Addresses

Appendix B: Partial List of BSC Vulnerability Log Addresses

For the full appendix, please see:https://web3labs.gcsa.com/blog/historical-transaction-replay-vulnerability-scanning

Copyright Notice: This report and related technical analysis are exclusively published by the GCSA Global Cybersecurity Alliance. For reprint permission, please retain the official GCSA source and original link in full, and do not maliciously alter the core viewpoints of the report.

Source:media.gcsa.com/news-3730122

GCSA Twitter: x.com/GCSAHK

GCSA Official Telegram Channel: t.me/GCSAofficial

Source:Global Cybersecurity Alliance (GCSA)
Website:www.gcsa.org