# Sui Move Security Review

> Use when auditing, reviewing, or hunting for vulnerabilities in Move code on Sui. Applies equally to source code (.move files) and to disassembly of compiled bytecode (on-chain packages). A checklist of invariants whose VIOLATION causes exploitable bugs: access control & capabilities, struct abilities & type safety, object lifecycle & ownership, shared-object and PTB attack surface, dynamic fields & collections, arithmetic & coins, init/OTW/package upgrades, hot-potato composability, time & on-chain randomness, and test-only code leakage. Trigger on "audit this Move code", "find vulnerabilities in this Sui contract", "security review", "is this package safe?", "I suspect there's a bug in X", "something is wrong with this contract", or when reasoning about whether a Move function can be abused.

- Skill: `mystenlabs/sui-move-security-review` (Agent Skill, multi-file: 11 files)
- Install (CLI): `npx skillmds@latest add mystenlabs/sui-move-security-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mystenlabs/sui-move-security-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: MystenLabs (https://skillmd.com/u/mystenlabs)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/mystenlabs/sui-move-security-review

---


# Move Security Review (on Sui)

> **Self-bootstrap (any AI agent):** this skill is bundled inside the `sui` binary. **For
> comprehensive audits, read every reference file in this bundle** — default to
> `sui prompt skill sui-move-security-review --all` for a one-shot load of all of them.
> Incremental loading is possible but should be the last resort. Even then, do not skip any files or rules to avoid creating blind spots. The detection heuristics, severity ratings, and exploit
> sketches live in those per-category files.
> This skill belongs to one or more categories — run `sui prompt categories` to see them
> and `sui prompt category <name>` to read the category's workflow. No filesystem install
> is required — the binary is self-contained.

> Offensive counterpart to the constructive Move skills — each rule = violated invariant
> with detection heuristic, severity, and exploit sketch.

> **Sources.** Per-rule citation `MystenLabs/skills → <file>`. **[+domain]** = established
> auditing practice not in upstream skills (high-yield, easy to miss — e.g. SM-A3, SM-B4).
> Verify on-chain facts against [docs.sui.io](https://docs.sui.io),
> [move-book.com](https://move-book.com), or framework source.

> **Representation.** The catalog is stated in Move semantics. Use `.move` files when
> the target is a source repository. Use disassembly (`.asm`) when the target is a
> deployed on-chain package: fetch bytecode with `sui-and-move-tools`, disassemble it,
> then walk rules with `auditing-bytecode.md` as the per-rule opcode-signal bridge.

## How to audit with this skill

1. **Map the attack surface first.** List every `public` and `entry` function (these are the only
   externally reachable entrypoints), every `*Cap`/witness/OTW type, every shared object, and
   every struct's ability set. PTB callers control argument order and supply arbitrary inputs —
   treat all entrypoints as adversarial.
2. **Walk the catalog by category** (A–M). For each rule, run the `Detect` heuristic
   against the code representation.
   - **A grep hit is a *candidate*, not a finding.** Confirm the invariant is actually
     broken before reporting.
   - **A grep miss is NOT proof of absence — walk the candidate set explicitly.** Many
     rules detect the *absence* of a guard, check, or invariant — either purely (SM-A2,
     A3, A6, B4, D1, E4, G2) or as confirmation on top of a candidate-presence check
     (SM-C1, C3, C4, F2, G1, M1). For these the bug shape is "X is missing where it
     should be"; an empty grep often means *"X is missing everywhere"*. Identify the
     rule's candidate set (privileged call sites for SM-A6; `&mut SharedT`-mutating
     `public`/`entry` fns for SM-A2; cap-gated fns for SM-A3; `dynamic_field::borrow*` /
     `bag::borrow*` / `table::borrow*` sites for SM-E4; `object::delete` sites for SM-C1;
     etc.) and for each candidate check whether the required guard is present — reason
     about dataflow, not the textual presence of `assert!` somewhere in the file.
3. **Report findings keyed to the rule ID** (e.g. `SM-A3`) with: severity, the offending
   location (`file:line`), why the invariant is violated, and the concrete exploit. Distinguish
   *exploitable* from *defense-in-depth*.
4. **Re-derive, don't trust naming.** A struct named `AdminCap` may be safe; an unnamed struct
   may be the real authority. Reason from abilities and from who can construct/obtain a value.

## Severity legend

- **Critical** — direct loss/theft of funds or objects, unlimited mint, total authority seizure, or permanent asset lock.
- **High** — privilege escalation, invariant bypass, or DoS of core functionality under realistic conditions.
- **Medium** — conditional/limited-impact issues, information disclosure, griefing, or contention DoS.

## Known system addresses (sanity references)

`0x1` std · `0x2` Sui framework · `0x6` `Clock` · `0x8` `Random` · `0x403` coin `DenyList`.