The deployUpgradeableProxy
function in the TadleFactory
contract allows the guardian to deploy a new upgradeable proxy and store its address in the relatedContracts
mapping. However, it lacks a check to ensure the index is not already set, which can lead to accidental overwriting of existing contract addresses with not Related Contracts for the given index.
if TadleFactory::guardian
accidently overwrite a index in relatedContracts
mapping without paying attention, then whenever we use RelatedContractLibraries
contract getter functions inside our core
contracts, the protocol will not work as expected and this will cause issues.
as it's stated in TadleFactory
Contract, the 1
index from relatedContracts
mapping, should return SystemConfig
and 4
index should return CapitalPool
, Can TadleFactory::guardian
accidently mess this up? yes.
lets overwrite the 1
index of relatedContracts
mapping with CapitalPool
proxy address.
run the test with following command:
we successfully overwrite 1
index of relatedContracts
mapping and set it to capitalPoolProxy
address.
Add a check to ensure the given index
is not already in use:
This ensures existing addresses are not overwritten, maintaining data integrity and security.
The following issues and its duplicates are invalid as admin errors/input validation/malicious intents are1 generally considered invalid based on [codehawks guidelines](https://docs.codehawks.com/hawks-auditors/how-to-determine-a-finding-validity#findings-that-may-be-invalid). If they deploy/set inputs of the contracts appropriately, there will be no issue. Additionally admins are trusted as noted in READ.ME they can break certain assumption of the code based on their actions, and
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.