Low Findings
Scope of Paused Flag in Market
Severity: Low
Ecosystem: Sui
Protocol: Creek Finance
Auditor: MoveBit
Report: https://movebit.xyz/reports/Creek-Audit-Report-2025-12-30.pdf
Report Date: Dec 2025
Description:
In the current implementation of Market, The paused flag currently affects the following operations: borrow, deposit_collateral, borrow_flash_loan, repay, and withdraw_collateral. It does not affect mint_gusd and redeem_gusd.
Proposals get stuck in pending when criteria are changed during voting
Severity: Low
Ecosystem: Sui
Protocol: Aeon
Auditor: Asymptotic
Report: https://info.asymptotic.tech/aeon-audit-report#262c1aef2c7042b7816a0015ed4a0051
Report Date: Feb 2025
Description:
approve_proposal could result in the proposal being approved, rejected, but marked as still pending. A proposal can become rejected before the call to approve_proposal because of user deletion, or changes to the admin_quorum_threshold.
Worst case, this could lead to delays in rejecting proposals. The workaround from a user perspective would be to revote.
Missing Pause State Verification
Severity: Low
Ecosystem: Sui
Protocol: Momentum
Auditor: MoveBit
Report Date: Nov 2025
Description:
The sync_staking_pool and update_pool_reward_emission functions are public and do not verify whether the contract is paused.
initialize_reward And add_reward Can Be Executed When emergency_reward_pause
Severity: Low
Ecosystem: Sui
Protocol: Cetus DLMM
Auditor: CertiK
Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg
Report Date: Sep 2025
Description:
When emergency_reward_pause is set to true, operations related to the reward manager should be stopped, as mentioned in the comments. However, in the actual execution logic, this state is only checked in the reward_settle() function through a call to emergency_reward_pause(). Since initialize_reward() and add_reward() does not call the reward_settle function, they can still be executed when emergency_reward_pause is true, which violates the intended design.
Empty Bins Can Be Marked As Used
Severity: Low
Ecosystem: Sui
Protocol: Cetus DLMM
Auditor: CertiK
Report: https://drive.google.com/drive/u/0/folders/1d9nv3nJidsbQ0vDT8D1kEuR3rJzK2ULg
Report Date: Sep 2025
Description:
In pool.move, the open_position_on_bin function marks a bin as "used" through the add_bin_in_group_if_absent function without checking if the bin is empty or if both amount_a and amount_b are zeros. Therefore, an empty bin may be marked as "used". This might lead to unexpected corner cases in the project's operations.
Missing State Verification
Severity: Low
Ecosystem: Sui
Protocol: Drife Technologies
Auditor: OtterSec
Report:
https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Dec 2023
Description: driver_cancel_ride, rider_cancel_ride, and admin_cancel_ride lack the verification of the current ride state. This absence of state verification may result in a driver canceling a ride even after the rider has already canceled the same ride via rider_cancel_ride, or vice versa. This may allow rider or driver to falsely set the on_ride value to false. Additionally, an admin may cancel a ride at any point, regardless of its current state.
Transaction Failure due to Race Condition
Severity: Low
Ecosystem: Sui
Protocol: Recrd
Auditor: OtterSec
Report:
https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Apr 2024
Description: Before the buy transaction is completed the state of the seller changes from ON_SALE to RETAINED. However, due to the assertion needing seller == ON_SALE, transaction will always fail.
Improper Validator Management
Severity: Low
Ecosystem: Sui
Protocol: Solend Liquid Staking
Auditor: OtterSec
Report:
https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Oct 2024
Description:
In the current implementation of the protocol, there is no logic to remove validators from the list of validator_infos . It is possible to remove an existing validator, which will only mark it as inactive.
Failure to Update Last Used Timestamp of Vault Cap
Severity: Low
Ecosystem: Sui
Protocol: Aftermath Market Making
Auditor: OtterSec
Report:
https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Jan 2025
Description:
Due to the failure to update last_used_timestamp_ms after successfully modifying the vault parameters, the recorded last-used timestamp in the VaultOwnerCap remains unchanged, allowing additional updates to bypass the cool-down check. As a result, it will be possible to continuously update these parameters to extremely low or high values, destabilizing the system.
Lack of Synchronization Between Bank and LendingMarket
Severity: Low
Ecosystem: Sui
Protocol: Solend Steamm
Auditor: OtterSec
Report:
https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Feb 2025
Description:
The vulnerability arises from the lack of full integration between bank and LendingMarket features. It is possible for the LendingMarketOwnerCap to create additional ObligationOwnerCap instances. This implies that a new obligation may be created without requiring interaction with the Bank module, which should ideally have control over such state changes. Furthermore, claim_rewards_and_deposit allows for the claim of rewards and automatic deposit of CTokens , which increases the obligation’s CTokens balance. As this feature operates outside the control of bank, it will not account for these changes in its tracking system.
Failure to Update Default Group
Severity: Low
Ecosystem: Sui
Protocol: Mysten Republic Security Token
Auditor: OtterSec
Report:
https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Apr 2025
Description:
Within remove_address_from_group in group_holder_config , the specified address is removed from its current group (old group), and the address_info for the address is updated, setting its group_id to DEFAULT_GROUP. However, it does not add the address to the holders list of the default group in config.groups. By setting address_info.group_id to DEFAULT_GROUP, the function intends to reassign the address to the default group.
However, without updating the DEFAULT_GROUP in Group.holders, the reassignment will be incomplete. This will result in an inconsistency, as the address will appear to belong to the default group based on address_info, but it will not be listed as a holder within the actual DEFAULT_GROUP in config.groups.
Don't Transfer Zero Coin
Severity: Low
Ecosystem: Sui
Protocol: Fluidity
Auditor: MoveBit
Report: https://movebit.xyz/reports/Fluidity-Final-Audit-Report.pdf
Report Date: Feb 2024
Description:
After calling redeem , if redeemed_coin_amount is 0, the protocol will transfer zero coin to the user, which will lead to more useless objects under the address, it is recommended to call destroy_zero in the contract to destroy coin with a zero value.
pause and resume Functions Should Check States First
Severity: Low
Ecosystem: Sui
Protocol: Random-Vault
Auditor: MoveBit
Report: https://movebit.xyz/reports/Random-Vault-Final-Audit-Report.pdf
Report Date: Feb 2024
Description:
The lottery.move, pause, and resume functions are used in emergencies to pause the protocol and resume it. However, typically it should be checked if it's already paused or unpaused first. And the related event would be emitted as well.
The Value Of able_to_remove_bid May Be The Same
Severity: Low
Ecosystem: Sui
Protocol: Typus Finance
Auditor: MoveBit
Report Date: May 2023
Description:
When updating the value of able_to_remove_bid, it is not judged whether it is the same as the original value, resulting in the value of able_to_remove_bid not being updated. In this case, no event should be emitted.
Missing Last Modifier Update
Severity: Low
Ecosystem: Aptos
Protocol: Aptos Labs Securitize
Auditor: OtterSec
Report: https://ottersec.notion.site/Sampled-Public-Audit-Reports-a296e98838aa4fdb8f3b192663400772
Report Date: Oct 2024
Description:
set_attribute currently does not update the last_updated_by field in the investor’s record, which may result in outdated tracking of who last modified the investor’s attributes.
Collateral flag for liquidator can be overridden by cached user config when self liquidating
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
- The liquidation_logic::liquidation_call keeps a cached user_config_map for the violator throughout the function.
- In the middle of the function, the liquidate_a_token call can set the collateral flag to true of the liquidator (which is also the user when self-liquidating).
- Afterwards, burn_bad_debt ! burn_debt_token is called which users the cached user config user_config_map that does not have the collateral flag set. If outstanding_debt == 0, it turns off the borrowing for the reserve and sets the entire user config again - overwriting the collateral flag from liquidate_a_tokens.
update_state is not updating the cache
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
The pool_logic::update_state function, which computes the new indexes, takes a &mut ReserveCache but does not update its timestamp. Functions that take a &mut ReserveCache should perform the code based on the values in the reserve cache and return an updated reserve cache.
Repaying with the AToken does not turn off the use-as-collateral flag when the user use the whole AToken balance
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
Users can repay their debt by using the corresponding AToken instead of the debt's underlying. If the user consumes the whole AToken balance and the AToken was used as collateral, the system should update the user's using_as_collateral flag to false for such asset. By not turning it to false, the system creates an inconsistency between the user's balance state and the config's state which could lead to unexpected behaviors given that such a flag is widely used both directly and indirectly across the protocol's logic.
Liquidation does not turn off the use-as-collateral flag when the liquidator seize the whole borrower's collateral
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
During the liquidation process, the liquidator could have seized the whole borrower's collateral. In such case, the protocol must update the borrower's user config and turn off the use-as-collateral flag for the collateral token. The Aptos codebase is not performing such operation that could lead to unexpected behavior for the borrower.
validate_set_use_reserve_as_collateral edge case handling
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Spearbit
Report Date: Jun 2025
Description:
The current implementation of the validate_set_use_reserve_as_collateral will always revert if the user_balance is equal to zero. There could be edge case scenarios where the protocol has failed to turn-off automatically (rounding down errors, logic errors and so on) the use-as-collateral flag for the asset in the user's config and the user would like to manually turn that flag to false.
LTV could be mistakenly reset due to missing set_reserve_freeze() check
Severity: Low
Ecosystem: Aptos
Protocol: AAVE v3.0.2 Core
Auditor: Certora
Report: https://github.com/aave/aptos-aave-v3/blob/main/audits/Certora Aave Aptos Core V3.0.2 Report.pdf
Report Date: Apr 2025
Description:
The function set_reserve_freeze() is not checking if freeze is different from the current frozen state, which could lead to resetting the current or pending ltv accidentally. set_reserve_freeze() is supposed to work as a toggle for freezing/unfreezing reserves. However, if we perform the same action twice, for example, unfreezing and then unfreezing again, the set_reserve_freeze() functionality goes beyond toggling and undermines the configuration set by the configure_reserve_as_collateral() function.
Underconfigured state is possible
Severity: Low
Ecosystem: Aptos
Protocol: Propbase
Auditor: Hacken
Report: https://hacken.io/audits/propbase/sca-propbase-staking-feb2024/
Report Date: Feb 2024
Description:
State resources such as StakePool, StakeApp, RewardPool are not initialized atomically. This means there is a possibility for the state to be underconfigured when it is being used. Setting/updating some of the fundamental fields is optional but the validity of the state is mandatory.
Incomplete storage cleanup on full withdrawal
Severity: Low
Ecosystem: Sui
Protocol: Elixir
Auditor: Pashov Audit Group
Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf
Report Date: Aug 2025
Description:
In the locked_funds.move function update_user_collateral_coin_types() when users
withdraw all tokens of a specific type, the tracking list is updated, but the underlying
BalanceStore
Ghost members in ACL causing potential storage bloat
Severity: Low
Ecosystem: Sui
Protocol: Elixir
Auditor: Pashov Audit Group
Report: https://github.com/pashov/audits/blob/master/team/pdf/Elixir-security-review_2025-08-17.pdf
Report Date: Aug 2025
Code: N/A
Description:
The bug occurs in remove_role and set_roles functions in acl.move, where members with all roles revoked (roles=0) remain in the roles_by_member LinkedTable without automatic removal, leading to accumulation of useless entries via repeated add/clear operations; this bloats storage and increases gas costs/iteration time in get_members , degrading performance over time.