Move Smart Contract Security Guide: What the Language Guarantees and What It Doesn’t

Introduction

Move is often described as a secure-by-design smart contract language. That description is accurate…but incomplete.

As adoption accelerates across Sui, Aptos, and other Move-based blockchain, a new class of vulnerabilities has emerged: not memory-safety bugs, but protocol-level failures. In practice, Move smart contract security depends less on language guarantees and more on architectural correctness, capability boundaries, and economic invariants.

This series is a structured Move smart contract security guide (and audit checklist), built for protocol engineers, auditors, and security researchers working with Move-based systems. It distills lessons from real-world exploits, public audit reports, academic research, and production security reviews.

This series is a structured Move smart contract security guide (and audit checklist), built for protocol engineers, auditors, and security researchers working with Move-based systems. It distills lessons from real-world exploits, public audit reports, academic research, and production security reviews.

Across eight parts, we will cover:

• The limits of the Move security model
• Capability and access control vulnerabilities
• Arithmetic and economic attack patterns
• Chain-specific risks on Sui, Aptos (and Supra)
• Protocol-level issues involving upgrades, oracles, and cross-module interactions
• Modern vulnerability patterns identified in large-scale audit datasets

The goal of this series is not to explain Move basics. It is to provide a practical, vulnerability-first framework for reviewing and auditing Move smart contracts in production environments.

This guide was written by G2MU, Security Analyst, and Anastasiia Matviiva, Marketing Lead, at HackenProof, and is grounded in practical experience analyzing smart contract exploits, audit findings, and protocol design failures across multiple blockchain ecosystems.

Part 1 lays the foundation for secure Move development by examining what the language guarantees at the VM level and where security ultimately depends on protocol design.

Why Move Protocols Still Get Exploited

Move was designed from first principles to eliminate the vulnerability classes that drained billions from EVM-based protocols — no reentrancy, no silent asset duplication, no untracked resource destruction. And by most measures it succeeds: the language’s linear type system and resource model enforce properties at the bytecode level that Solidity cannot express at all.

But 2025 made one thing brutally clear: Move’s language-level guarantees do not eliminate exploits at the protocol level.

This is the central misconception in modern Move smart contract security. While the language prevents entire categories of low-level bugs, vulnerabilities in smart contracts continue to emerge in production across Sui, Aptos and other Move chains. These failures are not memory-safety bugs. They are architectural, economic, and access-control failures that only a rigorous smart contract review can uncover.

Three major incidents punctuated the point:

• Cetus Protocol, May 2025 (~$223M): An arithmetic overflow in a third-party math library (integer-mate) corrupted concentrated liquidity pool calculations. The specific bug: checked_shlw, a function that checked for 192-bit overflow in a wide-integer shift operation, used a flawed condition that passed for certain large inputs. An attacker supplied an extreme liquidity parameter with a tiny tick range ([300000, 300200]), causing the overflow check to pass when it should have aborted. Depositing 1 token yielded hundreds of millions in liquidity. About $162M was frozen by Sui validators and roughly $60M bridged out. Three audits by three different firms missed the bug — the library was either out of scope or considered low-risk. Critically: Move’s VM-level overflow protection does not cover left-shift operations. A detail explicitly documented in the Aptos Move security guidelines.
• Nemo Protocol, September 2025 (~ $2.4M-$2.6M): Post-incident reporting attributes the exploit to unaudited code being deployed and a flaw in a slippage-related function (get_sy_amount_in_for_exact_py_out). This pricing function vulnerability allowed asset valuation manipulation that allowed protocol-level design flaws (state change), rather than a language-level (VM/type-system) failure.
• Typus Finance, October 2025 (~$3.44M): A lack of authority checks in an oracle path for a specific contract component (TLP) enabled arbitrary/unauthorized price updates, enabling drain via mispriced swaps/collateral actions. Reporting and post-mortems stress that the affected module was unaudited/out of scope for earlier audits, underscoring audit-scope and deployment-process risk rather than language-level weakness.

The pattern is identical across all three incidents: the Move code was valid at the language level. The failures were in architectural assumptions, dependency trust, audit scope, and economic invariants — none of which the Move compiler enforces.

The Research Context: Move Smart Contract Vulnerabilities (2024–2026)

The academic and community security research base for Move has matured significantly in recent times, and this guide integrates three major sources of empirical data on it’s smart contract security.

1. MoveScan (Song et al., ISSTA 2024) remains the largest empirical study of Move smart contracts: 652 manually audited contracts from 92 projects, eight defect types identified (four previously unreported), and automated analysis applied to 37,302 deployed contracts on Aptos and Sui — finding 97,028 defects at 98.85% precision.A companion study, Analyzing and Detecting Four Types of Critical Security Vulnerabilities in Move Smart Contracts (Zhang et al., 2025), identified four additional critical vulnerability classes: TreasuryCap leakage, arbitrary minting, CoinStore confusion, and reference abuse. These were found from systematic audit report analysis, blogs, bounties and building detectors (on top of MoveScan), reporting up to 20,778 matches across the same 37,302-contract population, at ~98.82% overall precision (per the paper’s abstract).
2. MoveScanner (Luo, Li & Li, arXiv 2508.17964v3, revised Feb 2026) introduces a CFG/data-flow static analysis tool with cross-module call graph tracking, targeting five key vulnerability classes: resource leaks, permission defects (weak access control), arithmetic overflows, unchecked return values, and capability leaks. Across 137 modules from 20 open-source projects, MoveScanner detected 2,882 potential vulnerabilities — with missing arithmetic boundary checks and resource leaks as the most common. It also identified 12 new cross-module interaction vulnerability types, highlighting that cross-module risks are a dominant theme in Move protocol security.
3. Move Vulnerability Database (MVD) v3.0 aggregates 1,141 findings from 200+ public audit reports across 16 audit firms. Its 26 vulnerability categories spans business logic, input validation, calculation errors, access control, oracle issues, inflation attacks, and signature replay, and many more. It provides one of the most comprehensive empirical distribution of real-world Move audit findings currently available. The top five categories by finding count in the Move Vulnerability Database (MVD v3.0) are:

The top three categories — Business Logic, Input Validation, and Calculation Errors — account for more than 54% of all findings across audited Move smart contracts.

Lower-frequency but high-impact categories include:

• Oracle Issues (27 findings)
• Missing Version Checks (12)
• Inflation Attacks (5)
• Signature Replay (3)
• Collision Vulnerabilities (5)

This empirical distribution reinforces a critical point for security audits in Move: most vulnerabilities are not VM-level failures, but protocol-level design mistakes.

Zellic’s classic practical guides: Move Fast & Break Things, Part 1: Move Security (Aptos), Move Fast & Break Things, Part 2: A Sui Security Primer, Top 10 Most Common Bugs in Your Aptos Move Contract, documents some of the earliest and most frequently observed patterns from real engagements. Aptos maintains official Move Security Guidelines with canonical anti-patterns and chain-specific pitfalls (including integer/shift semantics, function values, and mem::swap risks). Sui’s security architecture documentation and Currency Standard security considerations provide the equivalent for Sui-specific patterns that map closely to recurring audit findings (capability handling: TreasuryCap, metadata capabilities, deny/permission capabilities, and shared-object access control).

What This Guide Is

• A vulnerability-first smart contract audit checklist for Move grounded in real findings from MVD, MoveScanner, MoveScan, and leading audit firms.
• A practical security guide for protocols building on Sui, Aptos, and other Move-based networks
• A technically precise breakdown of exploit patterns, architectural risks, and economic invariant failures

What This Guide Is Not

• A beginner introduction to Move
• A formal specification of MoveVM behavior
• A replacement for hands-on audit experience

Understanding the Move Smart Contract Security Model (Sui & Aptos)

Before conducting a security review, you must understand precisely what the Move language guarantees — and what it does not. Many production vulnerabilities arise not from language flaws, but from misunderstandings about the limits of it’s security.

What Move Enforces at the Language Level

Move was designed to provide strong safety guarantees at the VM level. These guarantees are foundational, but they are not sufficient to prevent protocol-level exploits.

• Linear resource semantics. Every resource type with the key ability must be explicitly moved, stored, or destroyed. It cannot be implicitly duplicated or silently discarded. This eliminates entire classes of double-spend vulnerabilities that were common in early ERC-20 implementations.
• Explicit ownership. Resources live under specific accounts (Aptos) or objects (Sui). Moving a resource from one context to another is a tracked, explicit operation (not an implicit side effect).
• Ability system. The four abilities (key, store, copy, and drop) determine what operations are legal on a type and are enforced by the verifier/VM. For examples, a struct without copy cannot be duplicated. In the same manner a struct without drop cannot be discarded.
• Bytecode verification. The Move VM’s security model relies critically on bytecode verification. All bytecode are verified by the VM before execution. Aptos Labs’ Securing Move blog describes the multi-team bytecode verifier audit process that included OtterSec, MoveBit, and Mysten Labs engineers, demonstrating the depth of VM-level security hardening.

These guarantees significantly reduce low-level implementation bugs but they do not eliminate vulnerabilities.

What Move Does NOT Protect Against

Understanding these limits is essential in any Move security review. Move provides zero protection against:

• Logic errors in protocol design. If the business logic is incorrect, the MoveVM will faithfully execute the wrong logic.
• Incorrect capability design. Exposing an admin capability to unintended callers is a design flaw, not a language flaw.
• Economic invariant violations. Move does not understand tokenomics, collateral ratios, or accounting invariants.
• External dependency bugs. Move’s safety guarantees stop at module boundaries. If a third-party dependency contains a vulnerability, it propagates into your protocol.
• Missing access control. public entry fun is callable by anyone. Move does not enforce authorization policies.
• Arithmetic precision loss. Integer division truncates. This is semantically correct Move behavior but frequently causes DeFi accounting vulnerabilities.
• Upgrade misconfiguration. A leaked UpgradeCap or governance misconfiguration is valid Move code — and a critical protocol-level vulnerability.

Mental model shift for Move auditors:
Move prevents memory corruption and resource safety violations.
It does not prevent architectural mistakes.
A Move audit focuses on protocol logic, capability boundaries, and economic invariants — not just syntax correctness.

Chain Architecture Differences That Affect Move Smart Contract Security

Although MoveVM semantics and “resource-oriented” ideas are shared, the security model differs across chains. A proper security review must account for these architectural differences.

Sui

Sui uses an object-centric model where every asset is an on-chain object with a unique ID and certain ownership rules. The Sui security model guarantees that only the object’s owner can authorize transactions on owned objects. However, as documented in the official architecture overview, shared and immutable objects can be accessed by anyone, placing full responsibility for access control on the application logic. This makes shared-object access control one of the most common sources of vulnerabilities in Sui.

The Sui Currency Standard security considerations outline risks around TreasuryCap handling, supply configuration, and regulatory state transitions, all of which are frequent audit findings. Sui package upgrades also introduce capability/key-risk: packages can be upgraded via UpgradeCap, or made permanently immutable by destroying that capability.

Aptos

Aptos uses an account-based resource model. Resources live under account addresses and are accessed through global storage operations (e.g. borrow_global and borrow_global_mut). The official Aptos Move Security Guidelines document common anti-patterns, including access control failures, arithmetic edge cases, and generics misuse. Incorrect address validation remains a high-frequency finding in audits.

Aptos transaction execution also relies on Block-STM execution engine for optimistic parallelization, which introduces additional considerations for state consistency and transaction ordering. Aptos code upgrades occur at package granularity and default to a “compatible” policy (unless made immutable), and the official documentation explicitly warns that even compatible upgrades can have hazardous effects — especially when depending on third-party code that can be upgraded.

Supra

Supra builds on MoveVM semantics but integrates native oracle feeds, distributed verifiable randomness (dVRF), automation, and cross-chain bridging. The official Supra documentation outlines these platform-level features. Because of these integrations, Supra expands the attack surface beyond standard Move modules, and these components must be included in any Supra security assessment.

Move Smart Contract Threat Model: What Attackers Can Actually Do

A sound Move smart contract review begins with a clearly defined threat model. In Move, attacker capabilities differ significantly from EVM, yet many security reviews fail because auditors unconsciously import EVM assumptions into Move-based systems.

Understanding the realistic attack surface is essential for accurate security analysis across Sui, Aptos, Supra and other related networks.

In a production environment, an attacker interacting with a Move protocol can:

• Call any public entry function: Every public entry fun is callable by any account with sufficient gas. Unlike Solidity, there is no implicit msg.sender trust model. Authorization must be implemented explicitly. Missing access control remains a common finding in Move security audits.
• Pass any object they own as an argument (Sui): Functions that accept Object<T> parameters will receive whatever object the caller supplies. The contract must verify ownership and object invariants explicitly. This is a frequent source of Sui smart contract vulnerabilities involving shared and owned objects.
• Pass arbitrary addresses as arguments (Aptos): Functions that call borrow_global<T>(addr) where addr is caller-supplied will attempt to access resources under that address. If addr is not validated, this becomes an access-control flaw which is one of the most common issues identified in Aptos Move audits.
• Compose multiple calls within a single transaction: Attackers can chain multiple function calls across modules within one transaction. Multi-step logic errors, incorrect state assumptions, and improperly ordered invariants can all be exploited within a single atomic execution.
• Trigger edge cases with boundary values: Zero deposits, maximum integer values, dust amounts, and empty vectors are valid inputs under the Move type system. Many production exploits in Move protocols originate from insufficient boundary validation rather than language-level flaws.
• Interact with shared objects under contention (Sui): Any account can transact with a shared object. Attackers can deliberately create transaction contention or spam interactions to trigger denial-of-service conditions, a chain-specific risk in Sui smart contract security.
• Use function values as callbacks (Move 2.x Aptos): As documented in the Aptos Security Guidelines §Function Values, Move 2.x supports first-class function values. These can be passed as callbacks that re-enter modules, creating reentrancy-like logical cycles. When combined with mem::swap, a malicious callback can substitute resources passed by mutable reference, expanding the Move attack surface beyond traditional expectations.
• Exploit abort paths: Move transactions are atomic, but abort paths must still be analyzed. If a function performs state changes before validation, or if the failure branch is economically favorable, attackers can deliberately trigger abort conditions for profit.

What an Attacker Cannot Do (Language-Level Guarantees)

While Move’s security guarantees do not prevent protocol-level mistakes, they do enforce strict VM-level invariants. An attacker cannot:

• Forge a resource type without the required abilities/bytecode rules
• Bypass the Move bytecode verifier to construct invalid state
• Duplicate a resource lacking the copy ability
• Trigger classical EVM-style reentrancy (though logical cycles may exist via function values in Move 2.x)

These guarantees significantly reduce memory corruption and resource duplication bugs, but they do not eliminate economic or architectural vulnerabilities in Move smart contracts.

Conclusion: Understanding the Limits of Move Security

Move fundamentally improves the safety baseline of smart contract development by enforcing resource safety and strict bytecode verification. But real-world exploits and audit data show that Move smart contract security is ultimately determined by protocol design, not VM guarantees. Most high-severity issues in production arise from access control failures, arithmetic and invariant mistakes, cross-module assumptions, and upgrade or governance misconfiguration. Move removes many memory-level risks, but it does not remove architectural risk. Understanding this distinction is the foundation of an effective Move security audit.

Up Next: Capability & Access Control Vulnerabilities

In Part 2, we focus on Capability & Access Control Vulnerabilities — how admin capabilities leak, how signer validation fails, and why authority boundaries remain one of the most common sources of critical findings across Sui and Aptos.

Reference Note on Statistics

Unless linked to a specific public source, frequency claims in this document are derived from the following:

1. Published posts and audit reports by firms including OtterSec, MoveBit, Zellic, Hacken, Spearbit/Cantina, Sherlock, and others.
2. MoveScan (Song et al., ISSTA 2024, ACM DL) — the first large-scale empirical Move smart contract security study, analyzing 652 manually audited contracts from 92 projects. This study reviewed 37,302 deployed contracts on Aptos and Sui, identifying 97,028 defects with 98.85% precision.
3. MoveScanner (Luo, Li & Li, arXiv 2508.17964v3, revised Feb 2026, arXiv) — a CFG/data-flow static analysis tool with cross-module call graph tracking. It identifies 5 key vulnerability classes and 12 new cross-module interaction vulnerability types with 88.2% detection accuracy, finding 2,882 potential issues across 137 modules from 20 open-source projects.
4. Move Vulnerability Database (MVD) v3.0 (movemaverick.github.io | GitHub) — a comprehensive community-driven database with 1,141 findings extracted from 200+ public audit reports across 16 audit firms. It includes 26 vulnerability categories with severity breakdowns.

Where statistics are generalized from practitioner observation rather than a specific study, this is noted.