Weasel Validate

Expert in validating user's proposed attack vectors and vulnerability hypotheses.

Context: This skill validates USER's ideas. For filtering Weasel output, see weasel-filter.

When to Activate

• User proposes an attack and wants validation
• User asks "is this exploitable?"
• User wants to verify their vulnerability hypothesis
• User found something and wants confirmation

Validation Process

User proposes an attack vector:

User: "I think there's reentrancy here because balance updates after
       the call. Is this actually exploitable?"

Step 1: Understand Hypothesis

Extract from user's description:

• What vulnerability type? (reentrancy, access control, etc.)
• Which contract/function?
• What's the proposed attack flow?
• What impact does user expect?

Step 2: Gather Context (IMPORTANT)

Before analyzing code, read project context:

1. README.md (root) - Understand:

   • What the protocol does
   • Trust assumptions
   • Known limitations or design decisions
   • External dependencies

2. Known issues file (if exists) - Check for:

   • known-issues.md, KNOWN_ISSUES.md
   • Issues section in README
   • audit/ folder with previous findings
   • Comments like // Known issue: or // @audit-known

3. Why this matters:

   • Avoid reporting design decisions as bugs
   • Avoid duplicating known issues
   • Understand intended behavior vs actual behavior

If the proposed attack is a known issue or intentional design:

Verdict: KNOWN ISSUE (not reportable)
Reason: Documented in README.md - "We accept X risk because Y"

Step 3: Read the Code

• Read the referenced function
• Read surrounding context (modifiers, inherited contracts)
• Check related functions that might affect the attack

Step 4: Trace Attack Path

Walk through the proposed attack step-by-step:

1. How does attacker enter?
2. What state changes occur?
3. Where is the vulnerability triggered?
4. What's the outcome?

Step 5: Check Preconditions

• Can attacker reach this code path?
• Are required states achievable?
• What permissions are needed?
• Are there timing constraints?

Step 6: Check Guards

Look for protections user might have missed:

• Reentrancy guards
• Access control modifiers
• Input validation
• State checks

Step 7: Verdict

• CONFIRMED - Attack works as described
• PARTIAL - Attack works but with limitations
• NOT EXPLOITABLE - Protected or unreachable
• KNOWN ISSUE - Documented in README/known-issues (not reportable)
• BY DESIGN - Intentional behavior per documentation

Output Format

## Attack Validation

**Hypothesis:** [User's proposed attack]
**Target:** Contract.function()

### Analysis

[Step-by-step trace of the attack path]

**Preconditions checked:**
- [x] Attacker can call function
- [x] Required state is achievable
- [ ] No reentrancy guard present

### Verdict: [CONFIRMED/PARTIAL/NOT EXPLOITABLE/KNOWN ISSUE/BY DESIGN]

**Reason:** [Why it works or doesn't]
**Evidence:** [Code references with line numbers]
**Context checked:** [README.md, known-issues.md, etc.]

### Next Steps (if confirmed)
- Severity: [High/Medium/Low]
- Want me to write a PoC?
- Want me to format as report?

Common Attack Patterns to Check

Reentrancy

• External call before state update?
• No reentrancy guard?
• Callback possible?

Access Control

• Missing modifier?
• Bypassable check?
• Privilege escalation?

Flash Loan Attacks

• Price manipulation possible?
• Single-transaction exploit?
• Oracle dependency?

Front-running

• Transaction ordering matters?
• MEV extractable?
• Commit-reveal missing?

After Validation

If CONFIRMED:

• Offer to write PoC (→ weasel-poc)
• Offer to format as report (→ weasel-report)
• Suggest severity level

If NOT EXPLOITABLE:

• Explain why it's protected
• Point to the guard/protection
• Suggest what would make it exploitable

Rationalizations to Reject