algorand-vulnerability-scanner
A security audit tool for detecting 11 common vulnerabilities in Algorand smart contracts.
Install
mkdir -p .claude/skills/algorand-vulnerability-scanner && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/5921" && unzip -o skill.zip -d .claude/skills/algorand-vulnerability-scanner && rm skill.zipInstalls to .claude/skills/algorand-vulnerability-scanner
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Scans Algorand smart contracts for 11 common vulnerabilities including rekeying attacks, unchecked transaction fees, missing field validations, and access control issues. Use when auditing Algorand projects (TEAL/PyTeal).Key capabilities
- →Scan TEAL and PyTeal code for vulnerabilities
- →Identify 11 specific security patterns
- →Provide remediation code fixes
- →Run static analysis with Tealer
How it works
It performs static analysis on Algorand smart contracts to detect platform-specific security flaws against a defined vulnerability database.
Inputs & outputs
When to use algorand-vulnerability-scanner
- →Auditing Algorand smart contracts
- →Reviewing TEAL assembly code
- →Validating security fixes for Algorand apps
- →Pre-audit security assessment
About this skill
Algorand Vulnerability Scanner
1. Purpose
Systematically scan Algorand smart contracts (TEAL and PyTeal) for platform-specific security vulnerabilities documented in Trail of Bits' "Not So Smart Contracts" database. This skill encodes 11 critical vulnerability patterns unique to Algorand's transaction model.
2. When to Use This Skill
- Auditing Algorand smart contracts (stateful applications or smart signatures)
- Reviewing TEAL assembly or PyTeal code
- Pre-audit security assessment of Algorand projects
- Validating fixes for reported Algorand vulnerabilities
- Training team on Algorand-specific security patterns
3. Platform Detection
File Extensions & Indicators
- TEAL files:
.teal - PyTeal files:
.pywith PyTeal imports
Language/Framework Markers
# PyTeal indicators
from pyteal import *
from algosdk import *
# Common patterns
Txn, Gtxn, Global, InnerTxnBuilder
OnComplete, ApplicationCall, TxnType
@router.method, @Subroutine
Project Structure
approval_program.py/clear_program.pycontract.teal/signature.teal- References to Algorand SDK or Beaker framework
Tool Support
- Tealer: Trail of Bits static analyzer for Algorand
- Installation:
uv tool install tealer(ensure uv's tool bin dir is on PATH) - Usage:
tealer contract.teal --detect all
4. How This Skill Works
When invoked, I will:
- Search your codebase for TEAL/PyTeal files
- Analyze each file for the 11 vulnerability patterns
- Report findings with file references and severity, above them a coverage table carrying a verdict for every pattern
- Provide fixes for each identified issue
- Run Tealer (if installed) for automated detection
5. Example Output
When vulnerabilities are found, you'll get a report like this:
=== ALGORAND VULNERABILITY SCAN RESULTS ===
Project: my-algorand-dapp
Files Scanned: 3 (.teal, .py)
Vulnerabilities Found: 2
Coverage: 11/11 patterns reported
1 Rekeying Attack ................... found approval.py:45
2 Unchecked Transaction Fee ......... n/a stateful app, fees paid by sender
3 Closing Account ................... clear Assert(Txn.close_remainder_to() == Global.zero_address())
... one row per pattern, all 11 present ...
---
[CRITICAL] Rekeying Attack
File: contracts/approval.py:45
Pattern: Missing RekeyTo validation
Code:
If(Txn.type_enum() == TxnType.Payment,
Seq([
# Missing: Assert(Txn.rekey_to() == Global.zero_address())
App.globalPut(Bytes("balance"), balance + Txn.amount()),
Approve()
])
)
Issue: The contract doesn't validate the RekeyTo field, allowing attackers
to change account authorization and bypass restrictions.
6. Vulnerability Patterns (11 Patterns)
I check for 11 critical vulnerability patterns unique to Algorand. For detailed detection patterns, code examples, mitigations, and testing strategies, see VULNERABILITY_PATTERNS.md.
Pattern Summary:
- Rekeying Attack ⚠️ CRITICAL - Unchecked RekeyTo field
- Unchecked Transaction Fee ⚠️ HIGH - Fee not validated in smart signatures
- Closing Account (CloseRemainderTo) ⚠️ CRITICAL - Unchecked CloseRemainderTo drains the account
- Closing Asset (AssetCloseTo) ⚠️ CRITICAL - Unchecked AssetCloseTo drains the asset holding
- Group Size Check ⚠️ HIGH - No
Global.group_size()validation on atomic groups - Time-Based Replay Attack ⚠️ MEDIUM - No lease or round-range bound
- Access Controls ⚠️ CRITICAL - Update/delete and privileged calls unprotected
- Asset ID Verification ⚠️ HIGH - Asset ID not validated in asset operations
- Denial of Service (Asset Opt-In) ⚠️ MEDIUM - Push transfers strand on un-opted accounts
- Inner Transaction Fee ⚠️ MEDIUM - Inner fee not explicitly set to 0
- Clear State Transaction ⚠️ HIGH - Clear state program cannot reject, state left inconsistent
For complete vulnerability patterns with code examples, see VULNERABILITY_PATTERNS.md.
7. Scanning Workflow
Step 1: Platform Identification
- Confirm file extensions (
.teal,.py) - Identify framework (PyTeal, Beaker, pure TEAL)
- Determine contract type (stateful application vs smart signature)
- Locate approval and clear state programs
Step 2: Static Analysis with Tealer
# Run Tealer on contract
tealer contract.teal --detect all
# Or specific detectors
tealer contract.teal --detect unprotected-rekey,group-size-check,update-application-check
Step 3: Manual Vulnerability Sweep
For each of the 11 vulnerabilities above:
- Search for relevant transaction field usage
- Verify validation logic exists
- Check for bypass conditions
- Validate inner transaction handling
Step 4: Transaction Field Validation Matrix
Create checklist for all transaction types used:
Payment Transactions:
- RekeyTo validated
- CloseRemainderTo validated
- Fee validated (if smart signature)
Asset Transfers:
- Asset ID validated
- AssetCloseTo validated
- RekeyTo validated
Application Calls:
- OnComplete validated
- Access controls enforced
- Group size validated
Inner Transactions:
- Fee explicitly set to 0
- RekeyTo not user-controlled (Teal v6+)
- All fields validated
Step 5: Group Transaction Analysis
For atomic transaction groups:
- Validate
Global.group_size()checks - Review absolute vs relative indexing
- Check for replay protection (Lease field)
- Verify OnComplete fields for ApplicationCalls in group
Step 6: Access Control Review
- Creator/admin privileges properly enforced
- Update/delete operations protected
- Sensitive functions have authorization checks
8. Reporting Format
Coverage Table
Report on every pattern in §6, whether or not it turned anything up. Emit this table above the findings, with all 11 rows present:
| # | Pattern | Verdict | Evidence |
|---|---|---|---|
| 1 | Rekeying Attack | found | approval.py:45 -- no Txn.rekey_to() assertion on the payment branch |
| 2 | Unchecked Transaction Fee | ||
| 3 | Closing Account (CloseRemainderTo) | ||
| 4 | Closing Asset (AssetCloseTo) | ||
| 5 | Group Size Check | ||
| 6 | Time-Based Replay Attack | ||
| 7 | Access Controls | ||
| 8 | Asset ID Verification | ||
| 9 | Denial of Service (Asset Opt-In) | ||
| 10 | Inner Transaction Fee | ||
| 11 | Clear State Transaction |
Each verdict is one of:
found— citefile:lineand write the finding up in full below.clear— the pattern applies to this contract and the contract handles it. Name the field, opcode, or check you searched for, so a reader can repeat the search.n/a— the pattern cannot apply here. Give the reason in one clause ("no inner transactions in this contract"). Not having looked is notn/a.
A table with fewer than 11 rows is an incomplete scan and must be reported as one. A row whose Verdict cell is empty is incomplete in the same way: row 1 above is filled in to show the shape, and every row is filled in the same way before the report is done. Eleven clear verdicts is
a result a reader can act on. A report that covers four patterns and says nothing about the other seven reads
exactly like a clean contract, and that is the failure this table exists to prevent.
Finding Template
## [SEVERITY] Vulnerability Name (e.g., Missing RekeyTo Validation)
**Location**: `contract.teal:45-50` or `approval_program.py:withdraw()`
**Description**:
The contract approves payment transactions without validating the RekeyTo field, allowing an attacker to rekey the account and bypass future authorization checks.
**Vulnerable Code**:
```python
# approval_program.py, line 45
If(Txn.type_enum() == TxnType.Payment,
Approve() # Missing RekeyTo check
)
```
**Attack Scenario**:
1. Attacker submits payment transaction with RekeyTo set to attacker's address
2. Contract approves transaction without checking RekeyTo
3. Account authorization is rekeyed to attacker
4. Attacker gains full control of account
**Recommendation**:
Add explicit validation of the RekeyTo field:
```python
If(And(
Txn.type_enum() == TxnType.Payment,
Txn.rekey_to() == Global.zero_address()
), Approve(), Reject())
```
**References**:
- building-secure-contracts/not-so-smart-contracts/algorand/rekeying
- Tealer detector: `unprotected-rekey`
9. Priority Guidelines
Critical (Immediate Fix Required)
- Rekeying attacks
- CloseRemainderTo / AssetCloseTo issues
- Access control bypasses
High (Fix Before Deployment)
- Unchecked transaction fees
- Asset ID validation issues
- Group size validation
- Clear state transaction checks
Medium (Address in Audit)
- Inner transaction fee issues
- Time-based replay attacks
- DoS via asset opt-in
10. Testing Recommendations
Unit Tests Required
- Test each vulnerability scenario with PoC exploit
- Verify fixes prevent exploitation
- Test edge cases (group size = 0, empty addresses, etc.)
Tealer Integration
# Add to CI/CD pipeline
tealer approval.teal --detect all --json > tealer-report.json
# Fail build on critical findings
tealer approval.teal --detect all --fail-on critical,high
Scenario Testing
- Submit transactions with all critical fields manipulated
- Test atomic groups with unexpected sizes
- Attempt access control bypasses
- Verify inner transaction fee handling
11. Additional Resources
- Building Secure Contracts:
building-secure-contracts/not-so-smart-contracts/algorand/ - Tealer Documentation: https://github.com/crytic/tealer
- Algorand Developer Docs: https://developer.algorand.org/docs/
- PyTeal Documentation: https://pyteal.readthedocs.io/
12. Quick Reference Checklist
Before completing Algorand audi
Content truncated.
When not to use it
- →Non-Algorand smart contract projects
- →General web application security audits
Prerequisites
Limitations
- →Limited to 11 defined vulnerability patterns
- →Requires manual review for complex logic
How it compares
It focuses on Algorand-specific transaction model vulnerabilities rather than generic smart contract security checks.
Compared to similar skills
algorand-vulnerability-scanner side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| algorand-vulnerability-scanner (this skill) | 1 | 3mo | Review | Advanced |
| secure-workflow-guide | 3 | 3mo | No flags | Advanced |
| audit-prep-assistant | 1 | 3mo | Review | Intermediate |
| xss-testing | 1 | 8mo | Review | Advanced |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by trailofbits
View all by trailofbits →You might also like
secure-workflow-guide
trailofbits
Guides through Trail of Bits' 5-step secure development workflow. Runs Slither scans, checks special features (upgradeability/ERC conformance/token integration), generates visual security diagrams, helps document security properties for fuzzing/verification, and reviews manual security areas.
audit-prep-assistant
trailofbits
Prepares codebases for security review using Trail of Bits' checklist. Helps set review goals, runs static analysis tools, increases test coverage, removes dead code, ensures accessibility, and generates documentation (flowcharts, user stories, inline comments).
xss-testing
Ed1s0nZ
XSS跨站脚本攻击测试的专业技能
idor-vulnerability-testing
davila7
This skill should be used when the user asks to "test for insecure direct object references," "find IDOR vulnerabilities," "exploit broken access control," "enumerate user IDs or object references," or "bypass authorization to access other users' data." It provides comprehensive guidance for detecting, exploiting, and remediating IDOR vulnerabilities in web applications.
web3-testing
wshobson
Test smart contracts comprehensively using Hardhat and Foundry with unit tests, integration tests, and mainnet forking. Use when testing Solidity contracts, setting up blockchain test suites, or validating DeFi protocols.
smart-contract-engineer
jw3b-dev
Expert in Solidity, Foundry, EVM security. Specializes in gas optimization, upgradeable patterns, and fuzz testing.