The design of the Escrow.sol contract allows for its direct deployment bypassing the EscrowFactory. This poses a potential risk as the EscrowFactory safeguards the process by mandating the buyer as the contract deployer and ensuring buyer's funds are sent to the contract.
An ill-intentioned actor could exploit this by creating a contract, injecting a minimal amount of funds, and mimicking the deployment process of the factory. This would expose both the seller and the arbiter to unnecessary risk. Furthermore, the actor could maliciously attribute someone else's address as the buyer, thereby ensnaring unsuspecting users.
The presence of such rogue contracts could also be leveraged by bad actors to camouflage their illicit activities since these contracts are not managed by the factory.
This can expose both the seller and the arbiter to unnecessary risk, and also camouflage illicit activities since these contracts are not managed by the factory.
A detailed review of the code base was conducted to identify this issue.
Foundry testing
To mitigate this, a requirement could be added within the constructor to ensure that the msg.sender
is the address of the Factory.
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.