Vulnerability reference
This is the reference half of Smart Contract Security, which teaches what the eUTXO model protects you from and what it leaves to you. Here every failure is written up in full, so you can look one up while building or work through them while auditing.
Most entries carry an identifier, a property statement (what must hold for the protocol to be safe), a test that demonstrates the failure, and its impact. The identifiers are stable and are what audit reports cite.
Four deep dives
These come up most often, are the most subtle to get right, and each is a page of its own.
| Vulnerability | Identifier | Description |
|---|---|---|
| Double Satisfaction | double-satisfaction | Multiple UTxOs in one transaction, each validator sees the same outputs, so one payment satisfies all of them |
| Missing UTxO Authentication | missing-utxo-authentication | Anyone can create UTxOs at script addresses, so without authentication you cannot tell legitimate from fake |
| Time Handling | time-handling | Validators only see time intervals, not exact timestamps, and incorrect bound handling enables time manipulation |
| Token Security | token-security | Native tokens, validation tokens, dust attacks, and execution limit exploits |
Four classes
The rest group into four classes. Reading a class start to finish beats reading its entries separately: within a class the failures share a mechanism, and usually a defense.
Resource exhaustion
Something unbounded grows past a ledger limit, or many actors compete for one UTXO. Value stops being spendable, or the protocol stops making progress.
| Vulnerability | Identifier | Description |
|---|---|---|
| Unbounded Value | unbounded-value | Unlimited tokens in a UTxO cause size and execution limit failures, and funds become unspendable |
| Unbounded Datum | unbounded-datum | A datum growing without limits eventually exceeds resource constraints |
| Unbounded Inputs | unbounded-inputs | Too many UTxOs required simultaneously hits transaction size and resource limits |
| Cheap Spam | cheap-spam | Low-cost spam actions stall legitimate protocol operations |
| UTxO Contention | utxo-contention | Shared global state creates contention when multiple users need the same UTxO |
Unchecked inputs
The validator trusted something the transaction author chose. Anything it does not explicitly check is an attacker's free choice.
| Vulnerability | Identifier | Description |
|---|---|---|
| Arbitrary Datum | arbitrary-datum | Not validating a datum when locking allows invalid data that causes spend failures |
| Other Redeemer | other-redeemer | Logic expecting a specific redeemer is bypassed by using a different redeemer on the same script |
| Other Token Name | other-token-name | Minting policies not checking all token names allow unintended tokens under the same policy ID |
| Missed Input | missed-input | A redeemer index not bound to the spent input lets an unvalidated input slip past a global validator |
| Signature Domain Separation | signature-domain-separation | Off-chain signatures without a domain separator or nonce replay across protocols or repeatedly |
Staking and certificates
An address has two credentials. A validator that governs only the payment half leaves the staking half open.
| Vulnerability | Identifier | Description |
|---|---|---|
| Insufficient Staking Control | insufficient-staking-control | Missing staking credential checks allow reward redirection, franken addresses, and stake-key spoofing |
| Certificate Deregistration | certificate-deregistration | An unguarded staking-script certificate path lets anyone deregister the credential and halt a withdraw-zero protocol |
Evaluation and grinding
Determinism makes validation predictable for you and for an attacker, who can work out in advance which checks will run and what a hash will come out to.
| Vulnerability | Identifier | Description |
|---|---|---|
| Evaluation Order | evaluation-order | Short-circuiting boolean operators can skip a required check or a deferred failure |
| Hash Grinding | hash-grinding | Author-influenced on-chain hashes are grindable, biasing placement or selection |
Practice
Attack these yourself in the Cardano CTF, an interactive security game where you exploit vulnerable contracts.
Sources
Reference material:
- MLabs - Formal vulnerability framework
- Invariant0 - In-depth security analysis
- Mesh - Code examples