CNumaToken.leverageStrategy() can be re-entered, causing all the vault funds to be moved to a cToken, crashing NUMA price.

The cToken exchange rate can be inflated to steal from the first depositor

OracleUtils.ethLeftSide() is not correct for some tokens, leading to incorrect nuAsset pricing

CF minimum can be bypassed when minting nuAssets

No RWAs have a chainlink feed in ETH, so RWAs cannot be minted as nuAssets

When calling `setModule`, a malicious executor can use malicious payload to steal 100% of the pool's liquidity

Incorrect handling of first deposit for new modules leads to all liquidity sent to vault manager

The expected price bounds are not passed in to alm.depositLiquidity(), allowing a sandwich attack

Due to incorrect rounding, a malicious user can cause the router to ALWAYS revert on adding liquidity

Through rebalance(), an executor can drain 100% of vault reserves by minting cheap shares

A malicious executor can delete the fees belonging to the owner of `ArrakisStandardManager`

Malicious users can exploit a flaw in `mintBatch()` to mint large amounts of tokens, with very little cost

Roles within any `Edition` contract can never be granted/revoked

Signature malleability- anyone can acknowledge or unacknowledge an edge from someone else's node

A malicious user can DoS the `acknowledgeEdge` and `unacknowledgeEdge` function by front-running

The excess funds sent to Edition will be lost, since `_refundExcess` has a logical flaw

`Edition.mintBatch()` will always revert due to using `msg.value` in a loop

GoatV1Pair does not work when fee-on-transfer tokens are used, leading to DoS of contract

V3Utils.execute() does not have caller validation, leading to stolen NFT positions from users

Owner of a position can prevent liquidation due to the 'onERC721Received' callback

AutoRange execution can be front-ran to avoid protocol fee, causing loss for protocol

Repayments and liquidations can be forced to revert by an attacker that repays miniscule amount of shares

Incorrect liquidation fee calculation during underwater liquidation, disincentivizing liquidators to participate

Complete DoS of every DVP's minting and burning, due to insufficient access controls within FeeManager::trackVaultFee.

The refunding feature in the PositionManager contract will always revert due to insufficient approval

Whenever swapPrice > oraclePrice, minting via PositionManager will revert, due to not enough funds being obtained from user.

A malicious user can bypass limit order trading fees via cross-function re-entrancy

During liquidation, global position data is updated with the wrong price

A user can bypass the locking of tokens in announced orders, by unlocking it in the LimitOrder contract

Incorrect underflow-prevention logic when updating `marginDepositedTotal` which can lead to underflow and brick the system