Foreword

As the Web3 ecosystem continues to develop, smart contract security risks have expanded from traditional code defects tomultiple aspects such as protocol interaction, signature verification, account permissions, and on-chain and off-chain collaboration. Some seemingly minor implementation deviations may also pose actual asset risks under certain conditions.

In early November 2026, Web3Labs Agent, a member of the Global Cybersecurity Alliance (GCSA), conducted automated testing on smart contracts on multiple blockchains, including Ethereum, Asset Chain, PEPU L2, QIE, and Lens Chain, during routine security inspections. Combined with manual read-only review and local Anvil fork verification, nine representative vulnerabilities and risks were identified.

This issue of "GCSA Insights" covers multiple security scenarios, including callback authentication, ERC-4337 signature binding, duplicate reward collection, contract initialization, weak randomness, EIP-7702 delegated execution, and account access control. Some issues have been reproduced by transferring funds or reproducing business logic in a local fork environment, while others are limited by specific permissions, historical protocol states, or third-party components.

It should be noted that this study did not broadcast exploit transactions to the production chain. The findings reflect the technical state at the time of detection and verification, and do not indicate that the vulnerability has been actually exploited, nor do they mean that the relevant risks still exist at the time of publication.

The following is the original technical report.

Overview

Sub-item observation

1. PEPU PoolSwapper callback not authenticated.

The PoolSwapper (0xEfAb…2689) on PEPU L2, when implementing the uniswapV3SwapCallback, unconditionally treats msg.sender as a trusted Uniswap V3 pool, while simultaneously decoding the payer address from an untrusted data field, rendering both security boundaries ineffective. Any third-party contract can simply have its token0() return the target token address, then actively call the callback and specify an authorized user as the payer, allowing PoolSwapper to transfer the victim's tokens as its own sender. The entire process requires the victim to be online or to perform any new interactions.

Figure 1: PoolSwapper callback function, msg.sender and payer are not validated.

The attack has been reproduced end-to-end on a local fork in the current production state: The attacker deployed a fake pool contract, actively called the PoolSwapper callback, and successfully transferred tokens from two legitimate authorized addresses as the PoolSwapper's sender. The victim addresses did not send any transactions throughout the process. The actual reachable range depends on the addresses that still retain valid allowances and hold the corresponding tokens, and changes in real time with user actions. It is recommended that the project team verify msg.sender through the factory getPool() in the callback, bind the payer to the outer swap context, and notify historical authorized users to revoke their allowances.

2. Particle Paymaster signature not bound to UserOperation

The Particle ERC-4337 Paymaster (0x4A0F…0266) on the Ethereum mainnet sponsors gas for users, but its signature digest only binds five fields: chainId, Paymaster address, senderNonce, validUntil, and validAfter. The sender, callData, three gas limits, and two fee parameters are omitted. An attacker can first obtain a legitimate sponsored signature for a low-cost operation, then tamper with the preVerificationGas value to an extremely high value, settling the gas compensation deducted from the Paymaster's deposit by EntryPoint to a beneficiary address under their control.

Figure 2: The Paymaster signature digest only binds to 5 fields, and all gas parameters are missing.

In the latest mainnet fork, the attacker tampered with the preVerificationGas to 45,000,000 and submitted handleOps. Paymaster, due to a weak digest, still accepted the original sponsorship signature. EntryPoint deducted gas compensation from the Paymaster deposit and sent it to the attacker's beneficiary. The deduction and the beneficiary increment were exactly equal, proving it was a direct value transfer from the deposit to the attacker's address rather than an estimation error. It is recommended to use the EntryPoint specification UserOperation hash or the full EIP-712 structure to sign all security-critical fields, and to suspend or withdraw EntryPoint deposits until this is fixed.

3. Manta TokenDistributor: Case-sensitive duplicate claims

The Manta reward API is case-insensitive for protocolType queries, but the on-chain TokenDistributor (0x04c7…a10d) uses the digest containing both uppercase and lowercase letters as the unique anti-duplicate key. For example, "symbiotic" has 512 uppercase and lowercase variants. The API treats these as the same protocol and returns the same signature, but the on-chain system treats them as 512 independent records. After the normal reward path is exhausted, the remaining 511 variant keys remain at 0, allowing for continued reward collection.

Figure 3: TokenDistributor uses digest as the unique key to prevent duplicate keys, and case variations generate independent records.

Verification of a historical EOA still active today: The canonical digest has received all rewards. After submitting protocolType="SYMBIOTIC", the API returned a valid signature of the same amount but a different digest. The eth_call succeeded, and a clean fork actually paid out the same amount. This address still has 511 unused variant keys. The contract provides batchClaimTokens and the signature has no deadline, allowing for batch completion. Attackers are limited to existing participants who still control the historical reward address; new addresses are currently ineligible for rewards. It is recommended that the API strictly normalize protocolType before digest construction, bind stable business identities to on-chain replay keys, and immediately suspend the Distributor or revoke the signer.

4. Asset Chain Moonpie/SafeLaunchV2 Clone Reinitialization

The `__initialize` method of the two initialized clones on Asset Chain lacks a one-time lock. Any EOA can overwrite key parameters such as `token`, `paymentToken`, and `owner`, but `totalTokensSold` will not be zeroed out. An attacker can change the token to a self-minted counterfeit coin while keeping the paymentToken as the real xRWA, allowing them to use the counterfeit coin to exchange for real assets in the clone via `sellTokens`. The Moonpie clone can also trigger `endBonding()` to create a pool by overwriting the owner, withdrawing the remaining balance via LP NFTs. Both paths have been reproduced end-to-end in the clean fork, ultimately exchanging for bridged USDT through an existing DEX pool. It is recommended that all clone initializers use a non-repeatable initialization lock and restrict calls to only trusted factories, and that old clones still holding assets be immediately paused or cleared.

Figure 4: __initialize has no one-time lock; token/paymentToken/owner can all be overwritten.

5. Ren 1.0 DarknodeID re-registration hijacking history rewards

Ren 1.0's DarknodeRegistry allowed refunded IDs to be re-registered by new addresses, with DarknodePayment.withdraw paying historical rewards according to the current operator. The Registry emptied the operator upon refund but did not settle old debts in the PaymentStore, creating a potentially preemptible identity key. The scanner enumerated 1,694 target IDs that had been refunded or were eligible for refunds and still had reward balances. A read-only production call confirmed that the register entry was not suspended and that withdrawing was paid according to the current operator. Ren officially announced the closure of Ren 1.0 in 2022; renAssets can no longer be redeemed for native tokens, and each ID requires a locked margin across multiple 28-day epochs before redemption.

Figure 5: Refund IDs can be re-registered; withdrawing will result in historical rewards being paid according to the current operator.

6. QIE Lottery Draw 42: Forced winning using weak random numbers.

The QIE mainnet's Lottery's `completeDraw` has no keeper restrictions, and its random number seed includes `block.timestamp`, `block.prevrandao`, `block.number`, and `msg.sender`. An attacker can use `CREATE2` to enumerate subcontract addresses within the same transaction, finding an address where the winning hash modulo equals their own participant's index. This subcontract then calls `completeDraw` within its constructor to complete the lottery. Since Grinder and Lottery read the same block variables within the same transaction, the search can be completed instantly on-chain. This has been reproduced in a clean fork: after joining the current period, the attacker uses `CREATE2` to find their own index, the winning transaction successfully pays the prize pool to the attacker, and the original participant does not receive any payment. It is recommended to use Chainlink VRF or commit-reveal mechanisms instead of on-chain predictable random numbers, and to add a keeper whitelist to `completeDraw`.

Figure 6: The random number seed includes msg.sender, and CREATE2 can enumerate the hit addresses.

7. BitMart error code EIP-7702: Account execution without authentication.

An Ethereum-based EIP-7702 delegated account (0x68b2…85F7) labeled "BitMart" by a browser has an exposed `execute((address,uint256,bytes)[],bytes)` function. This function lacks a caller whitelist and does not use a second signature parameter. Using any EOA as the `from` parameter, this account calls the token transfer function `eth_call`, which returns successfully; the amount exceeds the balance and is then rolled back, proving that the inner transfer was indeed executed. The "BitMart" label is from a third-party browser and not official attribution proof. The account currently has only a small amount of stablecoins remaining, but if funds are deposited later, the vulnerability will re-emerge as a real-time risk; continuous monitoring is recommended.

8. Lens Account execute-only Manager oversteps authority

The Lens Chain Account contract's `executeTransaction` has an accounting mismatch between `value` and `msg.value`: `_beforeExecuteTransaction` adds native tokens (allowance) to the execute-only manager when `msg.value > 0`, but the empty `calldata` branch only deducts allowance when `msg.value > 0`, and deducts `msg.value` instead of the actual value issued. When `msg.value = 0`, `data = 0x`, and `value = Account's total balance`, the allowance branch doesn't execute at all, but `target.call{value: value}` is still issued from the balance. Verification of `eth_call` for two real Accounts shows that the manager identity can simulate a full transfer, and random ordinary EOAs all roll back with `NotAllowed()`. However, `addAccountManager` and `updateAccountManagerPermissions` are both `onlyOwner`, meaning all currently related managers are uncoded EOAs, and ordinary outsiders cannot acquire this role independently.

Figure 7: When msg.value=0, allowance is not executed, but value is still issued from the balance.

9. Push Protocol Airdrop Leaf + Recipient Account EIP-7702 Dangerous Request

An unclaimed leaf recipient account of the Push Merkle Distributor delegates an unauthenticated call(address, uint256, bytes) via EIP-7702.

The Distributor correctly pays the legitimate recipient address according to the fixed Merkle leaf, and the permissionless claim itself is not problematic. The danger comes from third-party delegation implemented by the recipient address: any EOA can first collect the reward on behalf of the attacker, and then use the account's public call() to make the account itself transfer the tokens to the attacker. In a clean fork, both transactions succeed without requiring the recipient account's private key or privileges. Even if the Distributor adds the msg.sender == account check, outsiders can still use the account's public call() to make the account itself invoke the claim, therefore the root cause cannot be attributed to the Push Protocol.

Common observations

The following patterns repeatedly appeared in this batch of samples:

Initial authentication is missing. Moonpie/SafeLaunchV2's __initialize lacks a one-time lock—this is the most common and easily overlooked security boundary in clone mode. EIP-1167's minimal agent implementation cannot be changed once deployed, and the defects of the old clone will be permanently retained.

Callbacks and entry functions lack caller validation. PEPU PoolSwapper's uniswapV3SwapCallback and BitMart's tag account's execute function both fall into this category. The former is a classic pitfall in Uniswap V3 integration, while the latter represents a new attack surface in EIP-7702's delegation mode.

The signature or random number binding is incomplete. Particle Paymaster's signature digest is missing gas-related fields, Manta's backend case handling is inconsistent with the on-chain digest, and QIE Lottery's random number relies on on-chain predictable variables—these three correspond to three different scenarios: ERC-4337, signature distribution, and gambling, but the root cause is "the context that should be bound is not bound."

EIP-7702's delegation implementation lacks sufficient access control. Both the BitMart tagged account and the Push recipient account are exposed due to EIP-7702's delegation of an unauthenticated generic execution function. While EIP-7702 grants EOA contractual capabilities, it also means that any flaws in the delegation implementation directly affect all of EOA's assets.

Recommendations for project owners and researchers

For project stakeholders: Prioritize checking callback authentication (whether `msg.sender` has been validated by the factory), signature integrity (whether the digest is bound to all fields that determine the deduction), and initialization lock (whether the initializer modifier exists). Continuously monitor or upgrade contracts with confirmed primitives as soon as possible. EIP-7702 delegate implementations should adhere to the principle of least privilege to avoid exposing unauthenticated generic execution entry points.

For researchers: If a technical primitive has been verified on-chain, it is recommended to contact the project team responsibly, rather than disclosing complete exploit details. For projects where the protocol has been decommissioned or the attacker's scope is limited, simply retain the technical evidence.

Of the nine vulnerabilities listed above, some require attackers to have a specific role in the process, the protocol has been deprecated, or the root cause lies in a third-party component.

Conclusion

The nine vulnerabilities and risks discovered in this cross-chain security inspection, although involving different protocols and business scenarios, share certain common technical roots: insufficient identity authentication, incomplete signature binding, lack of initialization protection, and permission and state management issues in cross-component interactions.

These cases demonstrate that smart contract security relies not only on pre-deployment code audits but also on continuous monitoring, dynamic verification, and timely intervention during operation. Especially for contracts that cannot be upgraded, the primary consideration in vulnerability disclosure should be mitigating the actual financial risk to the old contract, rather than immediately disclosing all technical details. Even if a flawed contract remains permanently on the blockchain, the project team can still mitigate the risk by suspending affected functions, assisting users with exiting the process, migrating funds, or switching integrations, and then decide when to disclose the technical details based on the actual situation.

At the same time, technical flaws do not necessarily mean that an actual attack has occurred. For discoveries involving limited exploitation, decommissioned protocols, or third-party components, the scope of impact and attribution of responsibility should still be carefully assessed in light of the actual situation.

GCSA will continue to combine automated detection, manual analysis, and on-chain verification to promote verifiable security research and responsible vulnerability disclosure, providing professional security research and risk references for the Web3 ecosystem.

Copyright and Disclaimer

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.

This report is for reference only in cybersecurity research, technical exchange, and risk prevention. The analysis and conclusions are based on information and evidence available at the time of publication and do not constitute a final determination of liability to any organization or individual. GCSA reserves the right to update the conclusions based on new evidence.

Please follow GCSA on the following social media platforms; we will update you with the latest news as soon as possible.

GCSA X (Twitter):https://x.com/gcsa_com

GCSA Telegram:https://t.me/GCSAofficial

GCSA WeChat Official Account:https://mp.weixin.qq.com/s/-OzihtjA5NsZPwwWyNbM-w

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