Cube3

Resonance SecurityRepository, no commit named

Resonance Security reviewed Cube3 on 14 Aug 2024: 6 findings, 0 critical; 3 marked fixed, 3 open.

No open critical findings
Open the reportOpen Cube3’s security record
Report stored on IPFS. Content hash QmcWzqdt7v4qfBSFiUMMM8vqsYMSH4ZwbcYtfofSPvWQSX

Trustblock does not review code.

Findings6

Statuses are the security firm’s own, from its report.

SeverityOpenAcknowledgedFixed
Critical000
High000
Medium000
Low303
LowMissing ERC165 Validation Via supportsInterface()Open

In several places across the codebase, contracts reference addresses of other contracts. A validation is performed that simply verifies whether these addresses are equal to the zero-address. This assures calling only an existing address in the blockchain, however, it does not ensures that this address is able to properly receive the call. Such validation is performed via ERC165's supportsInterface() function which makes sure that a given address implements an expected interface. Additionally, such a validation indirectly asserts that the the given address is a not a zero-address.

LowNo Usage of OpenZeppelin's PausableUpgradeable ContractOpen

OpenZeppelin implements several standards used all across blockchain development, especially in Solidity and the Ethereum Virtual Machine. These standards primary goal is to unify and normalize development patterns so that the entire blockchain may be more understandable and readily usable.The Cube3 smart contracts implement source code that mimics or is very similar to components already implemented by OpenZepellin, and could therefore, be switched with the more the standard well-known approach. Such source code is included in:RouterStorage.sol contract pausability features, can be substituted with OpenZeppellin's implementation of PausableUpgradeable.It should be noted that the usage of bigger libraries does not constitute an overuse of gas, since only the functions that are used are included on the bytecode of the smart contract.

LowPossibility Of Bypassing Revoked Integration Status Using Registered IntegrationOpen

It was observed that in certain scenarios it is possible to bypass one REVOKED integration status via another REGISTERED one. The scenario is as follows:Suppose there are two integrations connected to the protocol, one of them is REGISTERED and another one is REVOKED.The malicious owner of a REVOKED integration colludes with the corruptible owner of a REGISTERED integration.The REGISTERED integration calls the function routeToModule directly, however using the arguments received from the REVOKED integration.This results in a REGISTERED integration using the Cube3 protocol for the REVOKED one's benefit effectively bypassing the REVOKED status.It should be noted that any future modules that do not make use of msg.sender will be more impacted by this finding.

Contracts in scope

No deployed address is recorded for this audit.

The report names a repository or files. Open the report to see its scope.

Part of Cube3’s security record

Cube3
Audits2 audits by 1 firmLast audit Aug 2024, by Resonance Security.
Critical findingsNo open critical findingsAcross 2 reports.
Open Cube3’s security record

Security firm

Resonance Security

18 projects reviewed · 25 reports · latest Aug 2025

See Resonance Security’s audits

Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.

Tell us