# Signatures missing some parameters being vulnerable to attackers using them coupled with malicious parameters Medium · Sherlock · AI agent · 11th March 2025 Finding M-2 of the Crestal Network competition. - Protocol: https://audits.sherlock.xyz/contests/755 - Codebase: https://github.com/0xsimao/2025-03-crestal-network/tree/27a3c28155702b3a68f29347efedffb048010e33 - Source: https://github.com/sherlock-audit/2025-03-crestal-network-judging/issues/225 --- ### Summary [`createAgentWithSigWithNFT()`](https://github.com/sherlock-audit/2025-03-crestal-network/blob/main/crestal-omni-contracts/src/BlueprintCore.sol#L566) for example signs `projectId, base64RecParam, serverURL`. However, it does not sign `privateWorkerAddress` or tokenId. This is an issue because although Base has a private mempool, the protocol integrates with Biconomy, which leverages ERC4337 and has a mempool for bundlers. Hence, the signatures will be available in the mempool and anyone can fetch them and submit it directly to base with other malicious `tokenId` or `privateWorkerAddress`. Thus, users can be forced to create agents with token ids they didn't intend to use or use invalid worker addresses, DoSing them. Workers have incentive to do this as they can censor other workers this way from using other workers and only they will be able to make the deployments, censoring other workers. The protocol intends to benefit workers from their work, so they have incentive to do so. If `[createAgentWithTokenWithSig()](https://github.com/sherlock-audit/2025-03-crestal-network/blob/main/crestal-omni-contracts/src/BlueprintCore.sol#L491)`, the token address used can be another one that has a bigger cost and users end up paying more. ### Root Cause In `createAgentWithSigWithNFT()` and similar, `tokenAddress`, `tokenId`, `privateWorkerAddress` are not signed. ### Internal Pre-conditions None. ### External Pre-conditions None. ### Attack Path 1. User sends signature to be used on `createAgentWithSigWithNFT()` or `createAgentWithTokenWithSig()` to the offchain protocol, which forwards it to Biconomy, adding the user operation to the mempool. 2. Attacker picks up the signature from the eip4337 mempool and submits the onchain transaction with other malicious inputs. ### Impact Worker censors other workers, DoSes users, makes them pay fees without getting services and ultimately forces users to use the attacker worker's services, who gets illegitimate fees. Or, attacker steals tokens from users by specifying a different token address. Or, another token id ownership is used. ### PoC [Here](https://docs.biconomy.io/smartAccountsV2/bundler#bundler) is how the biconomy bundler works (which is the same as the typical bundler): > Aggregating userOps in an alternative mempool to normal Ethereum Transactions Attacker can become a bundler and listen to the same mempool and perform the attack. ### Mitigation Sign all parameters. --- Related findings: - [Saving parameters in memory without using them spends gas](https://0xsimao.com/findings/fuji-finance-saving-memory-spends-gas): Fuji Finance - [Tokens with callbacks may allow malicious attackers to steal the protocol](https://0xsimao.com/findings/clip-finance-i-callbacks-malicious-attackers-steal): Clip Finance Strategies