Possible Vulnerabilities :: Unofficial EVE Frontier Development Notes

1. Object Transfer Misuse

Wed, 26 Nov 2025 00:00:00 +0000

Overview Any address-owned object with key (especially combined with store) can be freely transferred using sui::transfer::transfer or public_transfer. This breaks assumptions about invariants, capability possession, and ownership that your contract may depend on. Risk Level High — Can lead to complete bypass of access control mechanisms. OWASP / CWE Mapping OWASP Top 10 MITRE CWE A01 (Broken Access Control) CWE-284 (Improper Access Control), CWE-275 (Permission Issues) The Problem In Sui, objects with key + store abilities can be transferred by their owner to any address. If your contract issues capability objects or admin tokens and assumes they will remain with the original recipient, an attacker can transfer these objects to themselves or others, bypassing your intended access control.

2. Object Freezing Misuse

Wed, 26 Nov 2025 00:00:00 +0000

Overview Objects with key + store abilities can be frozen by any holder using sui::transfer::public_freeze_object. Once frozen, an object becomes immutable and globally readable. This can be exploited to permanently disable critical protocol functionality or expose sensitive data. Risk Level High — Can permanently break protocol functionality with no recovery path. OWASP / CWE Mapping OWASP Top 10 MITRE CWE A01 (Broken Access Control) CWE-284 (Improper Access Control), CWE-732 (Incorrect Permission Assignment) The Problem When you expose an object by value (returning it from a function), the caller gains full control including the ability to freeze it. If that object is your protocol’s treasury, configuration, or any mutable state, freezing it permanently disables all mutations.

3. Numeric / Bitwise Pitfalls

Wed, 26 Nov 2025 00:00:00 +0000

Overview Move’s numeric and bitwise operations have specific semantics that differ from other languages. Arithmetic operations abort on overflow/underflow (rather than wrapping), while bitwise shifts beyond the type width silently produce zero. These behaviors can lead to unexpected results and security vulnerabilities. Risk Level Medium to High — Can cause denial of service or bypass access control checks. OWASP / CWE Mapping OWASP Top 10 MITRE CWE A06 (Vulnerable Components), A03 (Injection) CWE-681 (Incorrect Conversion), CWE-190 (Integer Overflow) The Problem Overflow/Underflow Behavior Move aborts on overflow rather than wrapping:

4. Ability Misconfiguration

Wed, 26 Nov 2025 00:00:00 +0000

Overview Move’s four abilities (copy, drop, store, key) control what operations can be performed on types. Misconfiguring these abilities can allow duplication of assets, unintended destruction of resources, wrapping of objects, or unauthorized global storage access. Risk Level Critical — Incorrect abilities can break fundamental economic invariants. OWASP / CWE Mapping OWASP Top 10 MITRE CWE A01 (Broken Access Control) CWE-284 (Improper Access Control), CWE-266 (Incorrect Privilege Assignment) The Problem Ability Overview Ability Allows Danger copy Duplicating values Assets can be infinitely copied drop Implicit destruction Resources can be silently discarded store Storing inside other objects Objects can be wrapped/transferred key Top-level object status Can be stored in global storage Common Mistakes Giving copy to assets — Allows infinite minting Giving drop to valuable items — Allows destroying value without proper handling Giving store to capabilities — Allows unauthorized transfer/wrapping Over-granting abilities — Default to minimal abilities Vulnerable Example module vulnerable::token { use sui::object::{Self, UID}; use sui::tx_context::TxContext; /// CRITICAL VULNERABILITY: Token with `copy` ability /// Anyone can duplicate tokens infinitely! public struct Token has copy, drop, store { value: u64, } /// VULNERABLE: Capability with `store` allows transfer public struct MintCap has key, store { id: UID, max_supply: u64, } public fun mint(cap: &MintCap, amount: u64): Token { Token { value: amount } } /// VULNERABLE: Ticket that can be dropped silently /// User might accidentally lose their ticket public struct EventTicket has key, drop, store { id: UID, event_id: u64, seat: u64, } } Attack: Infinite Token Duplication module attack::duplicate { use vulnerable::token::{Self, Token}; public fun exploit(): (Token, Token, Token) { let original = token::mint(cap, 1000); // Because Token has `copy`, we can duplicate it infinitely! let copy1 = copy original; let copy2 = copy original; let copy3 = copy original; // ... unlimited copies (original, copy1, copy2) } } Attack: Capability Transfer module attack::steal_cap { use vulnerable::token::MintCap; use sui::transfer; public entry fun steal(cap: MintCap) { // MintCap has `store`, so anyone who gets it can transfer it transfer::public_transfer(cap, @attacker); } } Secure Example module secure::token { use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; use sui::transfer; use sui::event; /// SECURE: No `copy` or `drop` — true asset semantics /// Must be explicitly created and explicitly consumed public struct Token has key, store { id: UID, value: u64, } /// SECURE: No `store` — only this module controls transfers public struct MintCap has key { id: UID, max_supply: u64, minted: u64, } /// SECURE: No `drop` — must be explicitly used or refunded public struct EventTicket has key { id: UID, event_id: u64, seat: u64, owner: address, } /// Event for ticket redemption public struct TicketRedeemed has copy, drop { ticket_id: object::ID, event_id: u64, seat: u64, } public fun mint( cap: &mut MintCap, amount: u64, recipient: address, ctx: &mut TxContext ) { assert!(cap.minted + amount <= cap.max_supply, E_EXCEEDS_SUPPLY); cap.minted = cap.minted + amount; transfer::transfer( Token { id: object::new(ctx), value: amount }, recipient ); } /// Tokens must be explicitly merged or split public fun merge(token1: Token, token2: Token, ctx: &mut TxContext): Token { let Token { id: id1, value: v1 } = token1; let Token { id: id2, value: v2 } = token2; object::delete(id1); object::delete(id2); Token { id: object::new(ctx), value: v1 + v2 } } /// Tickets must be explicitly redeemed — cannot be dropped public entry fun redeem_ticket(ticket: EventTicket, ctx: &TxContext) { let EventTicket { id, event_id, seat, owner } = ticket; // Verify caller is the ticket owner assert!(tx_context::sender(ctx) == owner, E_NOT_OWNER); event::emit(TicketRedeemed { ticket_id: object::uid_to_inner(&id), event_id, seat, }); object::delete(id); } /// Explicit refund path for tickets public entry fun refund_ticket( ticket: EventTicket, ctx: &mut TxContext ) { let EventTicket { id, event_id: _, seat: _, owner } = ticket; assert!(tx_context::sender(ctx) == owner, E_NOT_OWNER); object::delete(id); // ... refund logic } } Ability Selection Guidelines For Assets (Tokens, NFTs, Items) /// Minimal abilities for fungible-like assets public struct Asset has key, store { id: UID, value: u64, } /// For assets that should never leave the protocol public struct LockedAsset has key { id: UID, value: u64, } For Capabilities /// Capability that can only be transferred by your module public struct AdminCap has key { id: UID, } /// Witness pattern — one-time use, no abilities needed public struct WITNESS has drop {} For Receipts/Proofs /// Hot potato — must be consumed in same transaction public struct Receipt { amount: u64, } /// Cannot be stored, copied, or dropped — forces handling For Events /// Events should always have copy + drop public struct TransferEvent has copy, drop { from: address, to: address, amount: u64, } Recommended Mitigations 1. Start with Minimal Abilities /// Start with nothing, add only what's needed public struct MyType { } /// Then add based on requirements: public struct MyType has key { } // If it needs to be an object public struct MyType has key, store { } // If it needs transfer 2. Document Why Each Ability is Needed /// `key`: Required for object storage /// `store`: Required for marketplace listing (intentional risk accepted) /// NO `copy`: Asset must not be duplicable /// NO `drop`: Asset must be explicitly consumed public struct NFT has key, store { id: UID, // ... } 3. Use Wrapper Types for Different Contexts /// Internal representation — minimal abilities public struct TokenInner { value: u64, } /// Transferable version public struct TransferableToken has key, store { id: UID, inner: TokenInner, } /// Locked version — no `store` public struct LockedToken has key { id: UID, inner: TokenInner, unlock_time: u64, } Testing Checklist Verify no asset types have copy ability Verify valuable resources don’t have drop unless explicitly intended Verify capabilities lack store unless transfer is explicitly required Test that types without drop must be explicitly consumed Audit all has declarations against security requirements Related Vulnerabilities Object Transfer Misuse Object Freezing Misuse Capability Leakage

5. Access-Control Mistakes

Wed, 26 Nov 2025 00:00:00 +0000

Overview Access control mistakes occur when authorization checks are missing, incorrectly implemented, or rely on wrong assumptions about TxContext::sender(). These vulnerabilities allow unauthorized users to perform privileged operations. Risk Level Critical — Direct path to unauthorized access and fund theft. OWASP / CWE Mapping OWASP Top 10 MITRE CWE A01 (Broken Access Control) CWE-285 (Improper Authorization), CWE-639 (Authorization Bypass) The Problem Common Access Control Mistakes Missing authorization checks — Functions accessible to anyone Checking wrong sender — Confusing gas sponsor with transaction sender Hardcoded addresses — Addresses that cannot be updated or rotated Race conditions — Authorization state changes between check and use Inconsistent models — Mixing capability-based and address-based checks Vulnerable Example module vulnerable::vault { use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; use sui::coin::{Self, Coin}; use sui::sui::SUI; use sui::transfer; const ADMIN: address = @0xDEADBEEF; public struct Vault has key { id: UID, funds: Coin, admin: address, } public struct AdminCap has key, store { id: UID, } /// VULNERABLE: No access control at all! public entry fun withdraw_all( vault: &mut Vault, ctx: &mut TxContext ) { let amount = coin::value(&vault.funds); let withdrawn = coin::split(&mut vault.funds, amount, ctx); transfer::public_transfer(withdrawn, tx_context::sender(ctx)); } /// VULNERABLE: Hardcoded address cannot be updated public entry fun emergency_withdraw( vault: &mut Vault, ctx: &mut TxContext ) { // What if ADMIN key is compromised? No way to rotate! assert!(tx_context::sender(ctx) == ADMIN, E_NOT_ADMIN); // ... withdraw logic } /// VULNERABLE: Checks sender but ignores capability public entry fun update_admin( vault: &mut Vault, _cap: &AdminCap, // Cap is ignored! new_admin: address, ctx: &mut TxContext ) { // This checks sender even though cap is passed // If cap was transferred, wrong person might have access assert!(tx_context::sender(ctx) == vault.admin, E_NOT_ADMIN); vault.admin = new_admin; } /// VULNERABLE: Time-of-check to time-of-use issue public entry fun conditional_withdraw( vault: &mut Vault, amount: u64, ctx: &mut TxContext ) { let sender = tx_context::sender(ctx); // Check is performed... assert!(is_authorized(sender), E_NOT_AUTHORIZED); // ...but in a PTB, authorization might change before this executes let withdrawn = coin::split(&mut vault.funds, amount, ctx); transfer::public_transfer(withdrawn, sender); } } Secure Example module secure::vault { use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; use sui::coin::{Self, Coin}; use sui::sui::SUI; use sui::transfer; use sui::event; const E_NOT_ADMIN: u64 = 0; const E_ZERO_AMOUNT: u64 = 1; const E_INSUFFICIENT_FUNDS: u64 = 2; /// SECURE: No `store` — only this module controls the cap public struct AdminCap has key { id: UID, vault_id: ID, // Tied to specific vault } public struct Vault has key { id: UID, funds: Coin, } public struct WithdrawEvent has copy, drop { vault_id: ID, amount: u64, recipient: address, } fun init(ctx: &mut TxContext) { let vault = Vault { id: object::new(ctx), funds: coin::zero(ctx), }; let vault_id = object::id(&vault); // Create admin cap tied to this vault let admin_cap = AdminCap { id: object::new(ctx), vault_id, }; transfer::share_object(vault); transfer::transfer(admin_cap, tx_context::sender(ctx)); } /// SECURE: Capability-based access control public entry fun withdraw( cap: &AdminCap, vault: &mut Vault, amount: u64, recipient: address, ctx: &mut TxContext ) { // Verify cap is for this vault assert!(cap.vault_id == object::id(vault), E_NOT_ADMIN); assert!(amount > 0, E_ZERO_AMOUNT); assert!(coin::value(&vault.funds) >= amount, E_INSUFFICIENT_FUNDS); let withdrawn = coin::split(&mut vault.funds, amount, ctx); event::emit(WithdrawEvent { vault_id: object::id(vault), amount, recipient, }); transfer::public_transfer(withdrawn, recipient); } /// SECURE: Explicit admin transfer with cap consumption public entry fun transfer_admin( cap: AdminCap, new_admin: address, ctx: &mut TxContext ) { // Old cap is consumed, new one is created let AdminCap { id, vault_id } = cap; object::delete(id); transfer::transfer( AdminCap { id: object::new(ctx), vault_id, }, new_admin ); } /// SECURE: Multi-sig pattern for critical operations public struct MultiSigProposal has key { id: UID, action: vector, approvals: vector

, threshold: u64, vault_id: ID, } public entry fun approve_and_execute( proposal: &mut MultiSigProposal, cap: &AdminCap, ctx: &TxContext ) { let sender = tx_context::sender(ctx); // Add approval if not already present if (!vector::contains(&proposal.approvals, &sender)) { vector::push_back(&mut proposal.approvals, sender); }; // Execute if threshold reached if (vector::length(&proposal.approvals) >= proposal.threshold) { // ... execute action } } } Access Control Patterns Pattern 1: Pure Capability-Based /// Best for most cases — clear, composable public entry fun admin_action(cap: &AdminCap, ...) { // Whoever holds the cap can perform the action // No sender checks needed } Pattern 2: Capability + Sender Verification /// For soul-bound capabilities public struct SoulBoundCap has key { id: UID, owner: address, } public entry fun action(cap: &SoulBoundCap, ctx: &TxContext) { assert!(tx_context::sender(ctx) == cap.owner, E_NOT_OWNER); // Both cap possession AND sender match required } Pattern 3: Role-Based Access public struct RoleRegistry has key { id: UID, admins: vector

, operators: vector

, } public fun is_admin(registry: &RoleRegistry, addr: address): bool { vector::contains(®istry.admins, &addr) } public entry fun admin_action( registry: &RoleRegistry, ctx: &TxContext ) { assert!(is_admin(registry, tx_context::sender(ctx)), E_NOT_ADMIN); } Pattern 4: Time-Locked Operations public struct TimeLock has key { id: UID, operation: vector, execute_after: u64, } public entry fun execute_timelock( lock: TimeLock, clock: &Clock, ) { assert!(clock::timestamp_ms(clock) >= lock.execute_after, E_TOO_EARLY); let TimeLock { id, operation, execute_after: _ } = lock; object::delete(id); // ... execute operation } Recommended Mitigations 1. Choose One Authorization Model // GOOD: Consistent capability-based public entry fun action1(cap: &AdminCap, ...) { } public entry fun action2(cap: &AdminCap, ...) { } public entry fun action3(cap: &AdminCap, ...) { } // BAD: Mixed models public entry fun action1(cap: &AdminCap, ...) { } public entry fun action2(ctx: &TxContext) { // sender check assert!(sender(ctx) == ADMIN, 0); } 2. Tie Capabilities to Resources public struct VaultCap has key { id: UID, vault_id: ID, // Can only control this specific vault } 3. Implement Emergency Procedures public struct EmergencyConfig has key { id: UID, guardians: vector

, pause_threshold: u64, } public entry fun emergency_pause( config: &EmergencyConfig, signatures: vector>, // ... verify multi-sig ) { } Testing Checklist Every state-modifying function has explicit access control No hardcoded addresses without upgrade path Capabilities are tied to specific resources where appropriate No mixing of authorization models Emergency procedures exist for key rotation All access control paths are tested with unauthorized callers Related Vulnerabilities Object Transfer Misuse Sponsored Transaction Pitfalls Capability Leakage

6. Shared Object DoS

Wed, 26 Nov 2025 00:00:00 +0000

Overview Shared objects in Sui can be mutated by any transaction, leading to contention when many actors try to modify the same object simultaneously. This can cause performance degradation or complete denial of service (DoS) for protocols that rely heavily on shared state. Risk Level High — Can make protocols unusable during high-demand periods. OWASP / CWE Mapping OWASP Top 10 MITRE CWE A05 (Security Misconfiguration), A06 (Vulnerable Components) CWE-400 (Uncontrolled Resource Consumption), CWE-834 (Excessive Iteration) The Problem Sui processes transactions that touch the same shared object sequentially to maintain consistency. When many transactions contend for the same shared object:

7. Improper Object Sharing

Wed, 26 Nov 2025 00:00:00 +0000

Overview Accidentally exposing objects as shared via transfer::share_object enables global mutation by anyone. Once an object is shared, it cannot be unshared — this is a permanent, irreversible change to the object’s ownership model. Risk Level High — Shared objects are accessible to all, potentially exposing sensitive operations. OWASP / CWE Mapping OWASP Top 10 MITRE CWE A01 (Broken Access Control) CWE-284 (Improper Access Control), CWE-277 (Insecure Inherited Permissions) The Problem Ownership Models in Sui Type Created By Who Can Use Can Be Changed Address-owned transfer::transfer Only owner Yes (transfer) Shared transfer::share_object Anyone No (permanent) Immutable transfer::freeze_object Anyone (read) No (permanent) Why Sharing is Dangerous Global access — Any transaction can reference the shared object No revocation — Cannot convert back to address-owned Mutation exposure — All &mut entry functions become callable by anyone Contention — Performance issues from concurrent access Vulnerable Example module vulnerable::wallet { use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; use sui::transfer; use sui::coin::{Self, Coin}; use sui::sui::SUI; public struct Wallet has key { id: UID, funds: Coin, owner: address, } /// VULNERABLE: Wallet is shared instead of transferred! fun init(ctx: &mut TxContext) { let wallet = Wallet { id: object::new(ctx), funds: coin::zero(ctx), owner: tx_context::sender(ctx), }; // WRONG: This should be transfer(), not share_object()! transfer::share_object(wallet); } /// Because wallet is shared, ANYONE can call this! public entry fun withdraw( wallet: &mut Wallet, amount: u64, ctx: &mut TxContext ) { // This check is useless — attacker just passes their address let recipient = tx_context::sender(ctx); // Wait, the owner check is missing entirely! let withdrawn = coin::split(&mut wallet.funds, amount, ctx); transfer::public_transfer(withdrawn, recipient); } /// VULNERABLE: Even with owner check, sharing was wrong public entry fun withdraw_checked( wallet: &mut Wallet, amount: u64, ctx: &mut TxContext ) { // Owner check exists but... assert!(tx_context::sender(ctx) == wallet.owner, E_NOT_OWNER); // If owner's key is compromised, wallet is drained // With address-owned, owner could at least try to transfer first let withdrawn = coin::split(&mut wallet.funds, amount, ctx); transfer::public_transfer(withdrawn, wallet.owner); } } Attack Scenario // Attacker finds the shared wallet object module attack::drain_wallet { use vulnerable::wallet; use sui::tx_context::TxContext; public entry fun steal( wallet: &mut wallet::Wallet, ctx: &mut TxContext ) { // Because wallet is shared, attacker can reference it directly // If withdraw() lacks owner check, funds are gone wallet::withdraw(wallet, 1000000, ctx); } } Secure Example module secure::wallet { use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; use sui::transfer; use sui::coin::{Self, Coin}; use sui::sui::SUI; /// Wallet is address-owned — only owner can use it public struct Wallet has key { id: UID, funds: Coin, } /// SECURE: Transfer to user, not share fun init(ctx: &mut TxContext) { transfer::transfer( Wallet { id: object::new(ctx), funds: coin::zero(ctx), }, tx_context::sender(ctx) ); } /// Owner must possess the wallet to call this public entry fun withdraw( wallet: &mut Wallet, amount: u64, recipient: address, ctx: &mut TxContext ) { let withdrawn = coin::split(&mut wallet.funds, amount, ctx); transfer::public_transfer(withdrawn, recipient); } /// Only owner can transfer their wallet public entry fun transfer_wallet( wallet: Wallet, new_owner: address, ) { transfer::transfer(wallet, new_owner); } } When Sharing IS Appropriate module appropriate_sharing::examples { use sui::object::{Self, UID}; use sui::tx_context::TxContext; use sui::transfer; /// APPROPRIATE: Global configuration that needs to be readable by all public struct GlobalConfig has key { id: UID, fee_bps: u64, paused: bool, } /// APPROPRIATE: Order book that multiple parties interact with public struct OrderBook has key { id: UID, bids: vector, asks: vector, } /// APPROPRIATE: Liquidity pool for AMM public struct LiquidityPool has key { id: UID, reserve_a: Coin, reserve_b: Coin, } /// For shared objects, use capability-based access control public struct AdminCap has key { id: UID, config_id: ID, } public entry fun update_config( cap: &AdminCap, config: &mut GlobalConfig, new_fee: u64, ) { assert!(cap.config_id == object::id(config), E_WRONG_CONFIG); config.fee_bps = new_fee; } } Sharing Decision Checklist Ask these questions before using share_object:

Possible Vulnerabilities :: Unofficial EVE Frontier Development Notes

1. Object Transfer Misuse

2. Object Freezing Misuse

3. Numeric / Bitwise Pitfalls

4. Ability Misconfiguration

5. Access-Control Mistakes

6. Shared Object DoS

7. Improper Object Sharing

8. Dynamic Field Misuse

9. Sponsored Transaction Pitfalls

10. General Move Logic Errors

11. Capability Leakage

12. Phantom Type Confusion

13. Unsafe Object ID Usage

14. Dynamic Field Key Collisions

15. Event Design Vulnerabilities

16. Unbounded Child Growth

17. PTB Ordering Issues

18. PTB Refund Issues

19. Ownership Model Confusion

20. Weak Initializers

21. Oracle Validation Failures

22. Unsafe Option Authority

23. Clock Time Misuse

24. Transfer API Misuse

25. Unbounded Vector Growth

26. Upgrade Boundary Errors

27. Event State Inconsistency

28. Read API Leakage

29. Unsafe BCS Parsing

30. Unsafe Test Patterns

31. Unvalidated Struct Fields

32. Inefficient PTB Composition

33. Overuse of Shared Objects

34. Parent-Child Authority