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.