Safe is a multi-signature smart contract wallet designed for collective management of digital assets. The wallet requires a predefined threshold of owner signatures before any transaction can be executed. To enhance functionality, Safe supports extensions through modules and fallback handlers.
Safe engaged Ackee Blockchain Security to perform a security review of Safe Smart Account with a total time donation of 20 engineering days in a period between April 14 and May 12, 2025. 6 engineering days were dedicated to manually-guided differential fuzzing using the Wake testing framework.
A second, fix review was performed between May 20 and May 27, 2025.
METHODOLOGY
We began our audit with a manual review of the codebase in parallel with manually-guided fuzzing using the Wake testing framework. For static analysis, we utilized Wake vulnerability and code quality detectors.
During the review, we focused on ensuring that:
- basic concepts of Safe (such as owners management and signature checking) remain implemented correctly;
- refactored assembly blocks labeled as memory-safe are indeed memory-safe;
- reentrancy and front-running attacks are not possible;
- standards such as ERC-165, ERC-1271 and EIP-712 are implemented correctly;
- integer overflows and underflows do not lead to security vulnerabilities;
- the contract is compatible with ERC-4337 smart accounts;
- backward compatibility is fully achieved through the
CompatibilityFallbackHandlercontract; and - common issues such as data validation are not present.
SCOPE
The audit was performed on the commit b115c4c in the safe-smart-account repository. The scope of the audit included all Solidity files in the contracts directory, excluding contracts/examples and contracts/test.
d89d156 was initially used as the target commit, but it was later updated to include changes in the CompatibilityFallbackHandler contract.
The second, fix review was performed on commit 5d26505 in the safe-smart-account repository.
FINDINGS
The classification of a security finding is determined by two ratings: impact and likelihood. This two-dimensional classification helps clarify the severity of individual issues. Issues which would be rated as medium severity, but which would be likely discovered only by the team, are typically decreased by the likelihood factor to the Warning or Informational severity ratings.
Our review resulted in 19 findings, ranging from Info to Medium severity. The most severe finding M1 was discovered through manually-guided fuzzing. The issue revealed a possibility of a front-running attack where an attacker could deploy a new Safe on behalf of a user without executing the intended callback. The issue sits in SafeProxyFactory, not the Safe account itself; it involves the (now-removed) createProxyWithCallback method, and no existing Safes are affected. The issue was not identified by earlier formal-verification checks and previous audits.
The M1 issue was found in already-deployed contracts of version 1.4.1 (and lower) across all supported chains. Ackee Blockchain Security initiated an immediate responsible disclosure over a secure channel as soon as the finding was identified to mitigate any possible risk. The validity of the finding was promptly acknowledged by the Safe team, according to whom the issue has never been exploited. A fix is scheduled for Safe’s upcoming v1.5.0 release.
The code is well documented, and possible caveats and security considerations are explained. There is room for improvements in terms of user experience (W1, W7, I4, I5). The reviewed version of Safe is incompatible with EIP-7702 smart accounts.
Critical severity
No critical severity issues were found.
High severity
No high severity issues were found.
Medium severity
M1: Front-running attack can bypass callback execution during Safe deployment
Low severity
L1: CompatibilityFallbackHandler does not provide full compatibility
L2: Strict calldata check on masterCopy call
Warning severity
W1: Misleading event emissions
W2: Use of precomputed msg.data
W3: Scratch space assumed zeroed out
W4: Safe setup may emit outdated information
W5: onlyNonceZero check can be bypassed
W6: Locked tokens possibility
W7: ProxyCreationL2 nonce value is not user-given argument
Informational severity
I1: Documentation issues
I2: Unnecessary typecasts to payable
I3: Code optimizations
I4: Factory initializer error not propagated
I5: No view function for FallbackManager handler address
I6: SafeStorage can be defined as abstract
I7: Missing L2-specific variant of createChainSpecificProxyWithNonce
I8: Interface type used for parameter that accepts zero address
I9: ChangedThreshold event is emitted unconditionally
TRUST MODEL
Owners of a Safe have full control over the Safe. Any attached modules must be trusted, as they can execute arbitrary transactions from the Safe. Attached fallback handler must be trusted as it can verify ERC-1271 signatures on behalf of the Safe.
Safe proxy factory may be trusted to provide a front-running protection when used correctly. I.e. it is guaranteed that a precomputed Safe address will belong to the intended owners as long as the Safe setup is performed as an initialization step of the proxy deployment.
CONCLUSION
Ackee Blockchain Security recommends Safe to:
-
document that the Safe account is not fully compatible with EIP-7702;
-
clearly mark files under contracts/examples as non-production code;
-
document functionalities that are not supported by
CompatibilityFallbackHandler; and -
address all identified issues.
Ackee Blockchain Security’s full Safe audit report can be found here.
We are always delighted to work with Safe’s world-class team and look forward to auditing them again in the future.
