Cyberconnect - staking pool

In the contract `CyberStakingPool` the role `DEFAULT_ADMIN_ROLE` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.acc.corp.certik.com/11ee-ee2c-0e005aa0-8cba-21ce68f528ad/diagrams/centralization_CyberStakingPool-CyberStakingPool-DEFAULT_ADMIN_ROLE.svg)


- `setBridgeWhitelist(address bridgeAddress, bool isWhitelisted)`: Sets the whitelisting status of a bridge address, allowing or disallowing it for bridging operations. Privileged role: `DEFAULT_ADMIN_ROLE`.

Any compromise to the `DEFAULT_ADMIN_ROLE` account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functions of the project.




In the contract `CyberStakingPool` the role `_OPERATOR_ROLE` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.acc.corp.certik.com/11ee-ee2c-0e005aa0-8cba-21ce68f528ad/diagrams/centralization_CyberStakingPool-CyberStakingPool-_OPERATOR_ROLE.svg)

- `setAssetWhitelist(address asset, bool isWhitelisted)`: Sets the whitelisting status of an asset, allowing or disallowing it for deposit and withdrawal. Privileged role: `_OPERATOR_ROLE`.
- `pause()`: Pauses the deposit functions in the contract to prevent new deposits. This can be used in emergency situations. Privileged role: `_OPERATOR_ROLE`.
- `unpause()`: Unpauses the deposit functions in the contract, allowing new deposits after being paused. Privileged role: `_OPERATOR_ROLE`.

Any compromise to the `_OPERATOR_ROLE` account may allow the hacker to take advantage of this authority and update the sensitive settings and execute sensitive functions of the project.

The `withdraw()` allows users to withdraw assets from the contract. However, it does not validate whether the assets being withdrawn are part of the `assetWhitelist`. This oversight could lead to the transfer of unapproved assets or potentially expose the contract to reentrancy attacks if the `safeTransfer` function interacts with a malicious contract.

The contract uses a generic `assetWhitelist` mapping to control which assets are allowed for bridging. However, this design does not account for the possibility that different bridges may have different requirements or risk profiles for asset whitelisting.

The current implementation of the `setAssetWhitelist()` and the `_bridge` function does not provide a way to specify which assets are whitelisted for which bridges.

The `withdraw`, `bridge`, and `bridgeWithSig` functions lack the `whenNotPaused` modifier, which means these functions can still be called when the contract is paused. This could lead to potential risks, especially in emergency situations where pausing the contract is necessary to prevent further transactions.

When a loop allows an arbitrary number of iterations or accesses state variables in its body, the function may run out of gas and revert the transaction.

```solidity=106
        for (uint256 i = 0; i < assets.length; i++) {
```
Function `CyberStakingPool.withdraw` contains a loop and its loop condition depends on parameters: `assets`.

The `Deposit` event is emitted both in the `deposit` function for ERC20 token deposits and in the `depositETH` function for native ETH deposits. This reuse of the event for different deposit types could lead to confusion and complications in off-chain monitoring systems that rely on event logs to distinguish between the two types of deposits.


An off-chain monitoring system is set up to track deposits into the contract. It might incorrectly interpret a `Deposit` event from a `depositETH` call as a regular ERC20 token deposit, leading to inaccurate tracking of the contract's activity.