6.1 EIP-7702 delegation allows front-running attack on account initialization
The JustanAccount contract is designed as an implementation template for an Externally Owned Account (EOA) to use via EIP-7702 delegation. This mechanism allows the EOA to execute the contract's logic in its own context, including the initialize(...) function which is used to set the initial owners of the account.
The initialize(...) function has external visibility and is intended to be called only once when the account logic is first used to set the owners. The only restriction on who can call it is a check that the account is not already initialized ( nextOwnerIndex() == 0).
function initialize(bytes[] calldata owners) external payable virtual {
//
if (nextOwnerIndex() != 0) {
revert JustanAccount_AlreadyInitialized();
}
_initializeOwners(owners);
}
In an EIP-7702 flow, the EOA first signs a delegation tuple, which is then submitted to the network.
A malicious actor can observe the EOA's delegation tuple and/or the transaction initializing the contract in the mempool. If they submit a transaction to the EOA's address, calling the delegated initialize(...) function with the attacker's address as the owner, and this transaction is mined before the EOA's intended initialization, the attacker can successfully front-run the EOA.
Once the attacker's transaction is executed, they become the owner of the EOA's account logic in the EOA's context. The attacker can then call privileged functions, such as execute(...), to drain all Ether and ERC-20 tokens held by the victim EOA. This allows an attacker to seize control and steal all funds from any EOA that attempts to use the JustanAccount for EIP-7702 delegation.
Recommendation
Consider restricting the caller of the initialize(...) function to ensure that only the EOA being initialized can set its own owners in case of use of EIP-7702, or the factory contract for ERC4337.
Resolution
We've successfully addressed the front-running vulnerability in the initialize() function. Our solution restructures the deployment architecture: the JustanAccountFactory now deploys the JustanAccount implementation in its constructor and passes its own address as an authorized factory parameter. The initialize() function is now restricted to only accept calls from the authorized factory address, completely preventing unauthorized initialization attempts. For EIP-7702 EOAs, users add owners via self-calls to addOwnerAddress() or addOwnerPublicKey(), which are protected by the existing ownership checks that permit msg.sender == address(this).
6.2 Gas griefing via WebAuthn signatures
The JustanAccount contract is an ERC-4337 compliant smart contract account that validates UserOperations through its validateUserOp(...) function. The signature validation logic supports multiple schemes, including WebAuthn for owners with registered public keys. When a signature does not match the format of a standard ECDSA signature, it is processed as a potential WebAuthn signature.
The validation path for WebAuthn signatures is susceptible to a gas griefing attack. The core of the issue lies in the use of the WebAuthn.tryDecodeAuth(...) function , which is used to parse the WebAuthnAuth struct from the signature data. This decoding function successfully parses the struct even if arbitrary data is appended to a valid encoded payload. It does not enforce that the entire input byte array is consumed during the decoding process.
This allows an attacker to take a valid WebAuthn signature for a UserOperation and append a large amount of arbitrary data to it. When this bloated signature is submitted to the ERC-4337 EntryPoint, the account's validation logic will succeed because tryDecodeAuth(...) correctly decodes the valid portion of the signature while ignoring the appended data. By increasing the size of the signature field, the attacker forces the account owner or their paymaster to incur higher gas costs. This can be used to drain the account's gas deposit.
Recommendation
Consider adding a validation step to ensure that the length of the signatureData corresponds to a reasonably encoded WebAuthnAuth struct without extraneous data.
Resolution
We acknowledge this gas griefing vulnerability where a malicious bundler could append arbitrary data to a valid WebAuthn signature. However, the practical impact is inherently limited by ERC-4337's verificationGasLimit field, which caps the maximum gas consumption during signature verification.
6.3 Stuck nonce can break cross-chain replayability
The JustanAccount contract implements a cross-chain replayability feature through the executeWithoutChainIdValidation(...) function. This functionality allows owner management operations to be executed across multiple chains with a single signature. To manage the nonces for these special operations, a constant key, REPLAYABLE_NONCE_KEY, is used. The validateUserOp(...) function checks if a UserOperation targets executeWithoutChainIdValidation(...) and ensures that the REPLAYABLE_NONCE_KEY is used for its nonce.
The ERC-4337 EntryPoint, which acts as a nonce manager, enforces strict sequential ordering for nonces associated with the same key. This means that for the REPLAYABLE_NONCE_KEY, UserOperations must be processed in the exact order of their sequence number (e.g., 0, 1, 2, ...).
The problem arises when a replayable UserOperation fails on one chain but succeeds on others. For instance, a user might broadcast a transaction to remove an owner across three different chains. If the account on one of those chains is in a state where the removal is invalid (e.g., the owner was never added on that chain, or it's the last owner), the UserOperation will revert. As a result, the EntryPoint will not increment the nonce for the REPLAYABLE_NONCE_KEY on that specific chain.
This creates a permanent desynchronization. All subsequent replayable operations with higher nonces will fail on the affected chain because the EntryPoint will reject them as being out of order. This effectively breaks the cross-chain synchronization feature for that account on that chain. This can be fixed by manually crafting and sending a separate transaction to call incrementNonce(...) on the EntryPoint contract.
Recommendation
Consider documenting this possibility and explaining the best practices to follow when doing owner management on JustanAccount contracts. Also document how to fix this scenario in case it is reached.
6.4 getUserOpHashWithoutChainId() uses unhashed name and version for domain separator
The getUserOpHashWithoutChainId(...) function is intended to compute a hash for a UserOperation that is valid across multiple chains by omitting the chainId from the EIP-712 domain separator . This allows for the replay of specific transactions, such as owner management, across different networks .
The function constructs the domain separator using the raw strings "ERC4337" and "1" for the name and version fields, respectively . This implementation deviates from the EIP-712 standard, which specifies that the string components of the EIP712Domain struct should be keccak256 hashed before being included in the final domain separator hash. The EIP712 contract inherited by EntryPoint correctly follows this standard by hashing the name and version when building its own domain separator .
This inconsistency means that any off-chain signer or wallet that correctly implements the EIP-712 specification will compute a different userOpHash than the one generated on-chain by getUserOpHashWithoutChainId(...). As a result, signatures may fail validation when processed by the JustanAccount contract for cross-chain operations, undermining the intended functionality.
function getUserOpHashWithoutChainId(PackedUserOperation calldata userOp) public view virtual returns (bytes32) {
bytes32 overrideInitCodeHash = Eip7702Support._getEip7702InitCodeHashOverride(userOp);
// @audit-issue The name "ERC4337" and version "1" are passed as raw strings instead of their keccak256 hashes.
return MessageHashUtils.toTypedDataHash(
keccak256(abi.encode(TYPE_HASH, "ERC4337", "1", 0, address(entryPoint()))),
userOp.hash(overrideInitCodeHash)
);
}
Recommendation
Consider aligning the implementation of getUserOpHashWithoutChainId(...) with the EIP-712 standard by hashing the name and version strings before encoding them into the domain separator.
Resolution
The implementation has been corrected to properly comply with the EIP-712 standard by hashing the name and version string fields before encoding them into the domain separator.
