Exploit for autopentest-ai

Name: Exploit for autopentest-ai
Rating: 5 (171 reviews)
2026-02-11 | CVSS 6.7
## https://sploitus.com/exploit?id=94654A87-F9CF-57B2-A107-A38E3D74327F
# AutoPentest

**Automated web application penetration testing powered by Claude Code, MCP (Model Context Protocol), and the full OWASP Web Security Testing Guide.**

AutoPentest transforms Claude Code into an autonomous penetration tester that systematically discovers, validates, and exploits web application vulnerabilities — with structured quality gates, evidence-based findings, and professional reporting.

> **Think of it as:** A senior pentester's methodology encoded into an AI agent — 109 OWASP tests, 27 security tools, 7 testing phases, automated quality assurance, and a zero-context final review — all orchestrated through MCP.

---


  


## Table of Contents

- [Why AutoPentest?](#why-autopentest)
- [Architecture](#architecture)
- [Features](#features)
- [Quick Start](#quick-start)
- [Usage](#usage)
- [Testing Phases](#testing-phases)
- [Security Tools](#security-tools)
- [WSTG Knowledge Base](#wstg-knowledge-base)
- [Quality Assurance System](#quality-assurance-system)
- [Example Report](#example-report)
- [Configuration](#configuration)
- [Multi-Domain Testing](#multi-domain-testing)
- [Crash Recovery](#crash-recovery)
- [Project Structure](#project-structure)
- [Requirements](#requirements)
- [FAQ](#faq)
- [Disclaimer](#disclaimer)

---

## Why AutoPentest?

Manual penetration testing is thorough but slow. Automated scanners are fast but shallow. AutoPentest bridges the gap:

| Capability | Manual Pentest | Automated Scanner | AutoPentest |
|------------|:-:|:-:|:-:|
| Full OWASP WSTG coverage | Depends on tester | Partial | **109 tests** |
| Business logic testing | Yes | No | **Yes** |
| Multi-step exploitation | Yes | Limited | **Yes** |
| Vulnerability chaining | Yes | No | **Yes** |
| Evidence-based findings | Yes | Template output | **Reproducible curl commands** |
| Consistent quality | Varies | Yes | **Phase gates + Final Judge** |
| Speed | Days | Minutes | **Hours** |
| Cross-domain auth (SSO/OIDC) | Manual setup | Usually fails | **Automated handling** |

---

## Architecture

```
                         ┌──────────────────────────────────────────┐
                         │            Claude Code (Host)            │
                         │                                          │
                         │  Orchestrates testing, spawns parallel   │
                         │  subagents, manages engagement state     │
                         └────────┬─────────────┬──────────────┬───┘
                                  │             │              │
                    MCP Protocol  │             │  MCP Protocol│
                                  ▼             │              ▼
               ┌──────────────────────┐         │  ┌─────────────────────┐
               │  WSTG MCP Server     │         │  │  Playwright MCP     │
               │  (Python/FastMCP)    │         │  │  (Browser Testing)  │
               │                      │         │  │                     │
               │  - 109 WSTG tests    │         │  │  - DOM XSS proof    │
               │  - Finding mgmt      │         │  │  - Clickjacking     │
               │  - Coverage tracking │         │  │  - JS-rendered auth │
               │  - Quality gates     │         │  │  - Client-side tests│
               │  - Report generation │         │  └─────────────────────┘
               └──────────────────────┘         │
                                                │  docker exec
                                                ▼
                                  ┌──────────────────────────┐
                                  │  autopentest-tools       │
                                  │  (Docker Container)      │
                                  │                          │
                                  │  27 security tools:      │
                                  │  nuclei, sqlmap, dalfox, │
                                  │  katana, ffuf, nmap ...  │
                                  │                          │
                                  │  Burp proxy passthrough  │
                                  │  (HTTP_PROXY → host)     │
                                  └──────────────────────────┘
```

**How it works:**

1. **Claude Code** reads `CLAUDE.md` for the complete pentest methodology and orchestrates the 7-phase workflow
2. **WSTG MCP Server** provides OWASP test procedures, manages findings/coverage, enforces quality gates, and generates reports
3. **Docker Container** runs all 27 security tools — traffic optionally routes through Burp Suite for passive monitoring
4. **Playwright MCP** handles browser-based testing (DOM XSS, clickjacking, JS-rendered login pages)
5. **Parallel subagents** execute independent test pipelines concurrently for faster coverage

---

## Features

### Comprehensive OWASP Coverage
- **109 WSTG test cases** across 12 categories — from information gathering to API testing
- Each test includes step-by-step CLI procedures, context-specific payloads, detection criteria, and severity rubrics
- Tests are prioritized (MUST/SHOULD) with conditional triggers so nothing relevant is skipped

### 27 Pre-Configured Security Tools
- All tools pre-installed in a single Docker image — `make setup` and you're ready
- Tools organized by phase: discovery, injection testing, authentication, cryptography, API testing
- Automatic Burp Suite proxy integration for passive traffic monitoring

### Structured 7-Phase Workflow
- **Phase 0:** Application Discovery & Mapping
- **Phase 1:** Information Gathering & Reconnaissance
- **Phase 2:** Configuration & Deployment Testing
- **Phase 3:** Identity, Authentication, Authorization & Session Management
- **Phase 4:** Input Validation Testing (pipelined XSS/SQLi/SSRF pipelines)
- **Phase 5:** Error Handling, Cryptography, Business Logic, Client-Side & API Testing
- **Phase 6:** Coverage Verification & Reporting
- **Phase 7:** Final Judge Review & Remediation

### Quality Assurance System
- **Automated phase gates** — each phase must pass quality checks before proceeding
- **Quality Reviewer** subagent at every phase transition identifies gaps and suggests improvements
- **Final Judge** — a zero-context agent reviews the entire engagement cold, like an external QA reviewer
- **Exhaustion gates** — "not vulnerable" requires proof of sufficient testing effort (minimum techniques and bypass attempts)

### Evidence-Based Findings
- Every finding requires reproducible curl commands and full request/response evidence
- **Three-tier classification:** EXPLOITED (proven impact), POTENTIAL (blocked by control), FALSE_POSITIVE (control holds)
- **Anti-hallucination framework** — "no exploit = no finding" enforced at every level
- Evidence checklists per vulnerability class verified before any finding is logged

### Pipelined Exploitation (Phase 4)
- 3 independent pipelines run in parallel: XSS, Injection (SQLi/CMDi), SSRF/SSTI
- Each pipeline: discover → analyze → save deliverable → create exploitation queue → validate → exploit → log
- WAF intelligence shared across all pipelines
- Context-aware witness payloads for 13 sink types

### Multi-Domain Support
- Automatic SSO/OAuth/OIDC/SAML detection and handling
- Per-domain scope registration, crawling, and testing
- Cookie jar management for cross-domain session persistence
- 6-level authentication failure escalation (alternative grants → PKCE → headless browser → token extraction → user provision → unauthenticated)

### Crash-Safe Engagement Management
- Append-only `findings.md` and `progress.log` survive crashes
- Git workspace checkpointing with rollback capability
- Checkpoint/resume system for interrupted engagements
- Full audit trail of every MCP tool call with timestamps

### Professional Reporting
- Markdown reports with executive summary, findings by severity, test coverage matrix, and tool coverage
- Per-category coverage percentages and gap analysis
- Vulnerability chaining analysis documented
- Final Judge observations and quality notes included

---

## Quick Start

### Prerequisites

- [Docker](https://docs.docker.com/get-docker/) (Docker Desktop on macOS/Windows, Docker Engine on Linux)
- [Claude Code CLI](https://docs.anthropic.com/en/docs/claude-code) with an active Anthropic API key
- [uv](https://docs.astral.sh/uv/) (Python package manager for the MCP server)
- [Node.js](https://nodejs.org/) (for Playwright MCP server)
- **Optional:** [Burp Suite Professional](https://portswigger.net/burp/pro) for passive traffic monitoring

### Installation

```bash
# 1. Clone the repository
git clone https://github.com/bhavsec/autopentest-ai.git
cd autopentest-ai

# 2. Install Python dependencies for the MCP server
cd server && uv sync && cd ..

# 3. Build Docker image and start the tools container
make setup
```

That's it. All 27 security tools are now installed and ready inside the Docker container.

### Verify Installation

```bash
# Check all tools are installed
make verify-tools

# Expected output:
# [+] nuclei: installed
# [+] httpx: installed
# [+] katana: installed
# ... (27 tools total)
```

### Start Testing

```bash
# Launch Claude Code in the project directory
claude
```

Then tell Claude what to test:

```
Run a full WSTG assessment against https://target.example.com
```

---

## Usage

### Option A: Interactive Mode

Launch Claude Code and provide the target:

```
Run a full pentest against https://app.example.com

Credentials: admin / P@ssw0rd123
```

Claude will ask for any missing information (like credentials) and begin the 7-phase workflow.

### Option B: Config-Driven Mode (Recommended)

Create a YAML config file for repeatable, consistent assessments:

```yaml
# configs/my-target.yaml
target:
  url: https://app.example.com
  scope:
    - app.example.com
    - api.example.com
  exclude:
    - cdn.example.com

authentication:
  login_type: form
  login_url: https://app.example.com/login
  credentials:
    username: testuser@example.com
    password: secret123
  login_flow:
    - "Type $username into the email field"
    - "Type $password into the password field"
    - "Click the 'Sign In' button"
  success_condition:
    type: url_contains
    value: "/dashboard"

rules:
  avoid:
    - description: "Do not test logout"
      type: path
      url_path: "/logout"
  focus:
    - description: "Prioritize API endpoints"
      type: path
      url_path: "/api"

reporting:
  tester_name: "Security Team"
```

Then in Claude Code:

```
Load the config from configs/my-target.yaml and run the pentest
```

### Option C: Targeted Testing

Run specific WSTG tests against specific endpoints:

```
Run WSTG-INPV-05 (SQL Injection) against https://app.example.com/search?q=
```

```
Test https://app.example.com for CORS misconfiguration (WSTG-CONF-13)
```

```
Run all authentication tests (WSTG-ATHN) against https://app.example.com
```

### Option D: Resume an Interrupted Engagement

```
Resume engagement pentest-2026-02-11-myapp
```

---

## Testing Phases

### Phase 0: Application Discovery & Mapping

The critical foundation phase. Claude autonomously:

1. **Pre-flight checks** — verifies target reachability, detects redirects and cross-domain auth
2. **Launches 10+ background tools** in parallel (katana, ffuf, nuclei, whatweb, gau, nmap, feroxbuster, wapiti, httpx)
3. **Recursive crawling** — follows links to depth 2-3, parses HTML/JS for endpoints
4. **Directory brute-forcing** — common paths + technology-specific wordlists
5. **Tool result ingestion** — reads all background tool outputs and merges into unified endpoint map
6. **Builds structured endpoint inventory** with parameters, auth requirements, and priority rankings

**Output:** A complete endpoint map organized by domain, ready for systematic testing.

### Phase 1-2: Reconnaissance & Configuration

- Server fingerprinting, technology detection, metadata review
- Security header analysis (HSTS, CSP, CORS, X-Frame-Options)
- TLS configuration testing, admin interface discovery
- HTTP methods testing, file extension handling

### Phase 3: Authentication, Authorization & Session Management

- **Role/privilege lattice** built before testing (maps guards, middleware, and bypass tests)
- IDOR testing with multiple alternate IDs per endpoint
- CSRF testing on every state-changing endpoint
- Session fixation, hijacking, and token analysis
- JWT vulnerability testing (if applicable)
- OAuth/OIDC weakness testing (if applicable)

### Phase 4: Input Validation (Highest Impact)

Three independent pipelined agents run in parallel:

| Pipeline | Vulnerability Classes | Tools |
|----------|----------------------|-------|
| XSS Pipeline | Reflected XSS, Stored XSS, DOM XSS | dalfox, Playwright |
| Injection Pipeline | SQL Injection, Command Injection, NoSQL Injection | sqlmap, commix, nosqli |
| SSRF/SSTI Pipeline | SSRF, SSTI, Path Traversal | sstimap, ssrfmap |

Each pipeline independently: discovers → analyzes → creates exploitation queue → validates → exploits → logs findings.

### Phase 5: Error Handling, Crypto, Business Logic, Client-Side & APIs

- Stack trace and error message disclosure
- TLS/SSL testing via testssl.sh
- Business logic bypass (workflow circumvention, request forgery)
- Client-side testing (clickjacking, open redirects, DOM manipulation)
- GraphQL and REST API testing
- Vulnerability chaining analysis across all findings

### Phase 6: Reporting

- Coverage verification (test coverage + tool coverage)
- Finding deduplication and severity calibration
- Markdown report generation with executive summary, findings, coverage matrices

### Phase 7: Final Judge Review

A zero-context agent reviews the entire engagement cold — no knowledge of testing decisions or difficulties. It examines:

- **Coverage integrity** — rubber-stamped tests, missing endpoints
- **N/A cascade detection** — categories with excessive "not applicable" markings
- **Finding quality** — evidence completeness, severity consistency, chaining opportunities
- **Tool utilization** — tools run but output never reviewed, lazy skip reasons
- **Missed attack surface** — untested endpoints, untested parameters, untested domains

The verdict (PASS/CONDITIONAL_PASS/FAIL) triggers specific remediation actions before the report is delivered.

---

## Security Tools

### Discovery & Reconnaissance (Phase 0)

| Tool | Purpose | Key Flags |
|------|---------|-----------|
| **katana** | Web crawler with JS rendering | `-jc` for JavaScript crawling |
| **httpx** | HTTP probing, tech detection | `-tech-detect -status-code -title` |
| **ffuf** | Directory/parameter fuzzing | `-w wordlist -mc all -fc 404` |
| **feroxbuster** | Recursive directory enumeration | `--smart --auto-tune` |
| **nuclei** | Template-based vuln scanner | `-t cves/ -t misconfigurations/` |
| **nikto** | Web server misconfiguration | `-Tuning 1234567890` |
| **whatweb** | Technology fingerprinting | `--aggression 3` |
| **nmap** | Port and service scanning | `-sV -sC --top-ports 1000` |
| **gau** | Historical URL discovery | `--blacklist png,jpg,gif` |
| **subfinder** | Subdomain enumeration | `-silent -all` |

### Injection Testing (Phase 4)

| Tool | Purpose | Key Flags |
|------|---------|-----------|
| **sqlmap** | SQL injection (all techniques) | `--batch --risk 3 --level 5` |
| **dalfox** | XSS scanning & exploitation | `--skip-bav --deep-domxss` |
| **commix** | Command injection | `--batch --all` |
| **sstimap** | Server-Side Template Injection | `-u ` |
| **ssrfmap** | SSRF exploitation | `-r request.txt` |
| **nosqli** | NoSQL injection | `-u ` |
| **crlfuzz** | CRLF injection / HTTP splitting | `-u ` |
| **smuggler** | HTTP request smuggling | `-u ` |

### Authentication & Session (Phase 3)

| Tool | Purpose | Key Flags |
|------|---------|-----------|
| **hydra** | Credential brute-force | `-L users.txt -P pass.txt` |
| **jwt_tool** | JWT token analysis & exploitation | `-t  -M at` |

### Cryptography & APIs (Phase 5)

| Tool | Purpose | Key Flags |
|------|---------|-----------|
| **testssl.sh** | TLS/SSL configuration testing | `--severity HIGH --sneaky` |
| **graphql-cop** | GraphQL security testing | `-t ` |
| **websocat** | WebSocket testing | `ws://` |

### Infrastructure (Phase 2)

| Tool | Purpose |
|------|---------|
| **corscanner** | CORS misconfiguration scanning |
| **dnsreaper** | Subdomain takeover detection |

### Browser Automation

| Tool | Purpose |
|------|---------|
| **Playwright** | DOM XSS proof, clickjacking, JS-rendered login, client-side storage inspection |

---

## WSTG Knowledge Base

109 test cases across 12 OWASP categories, each with CLI-specific procedures:

| Code | Category | Tests | Examples |
|------|----------|:-----:|---------|
| **INFO** | Information Gathering | 10 | Search engine discovery, server fingerprinting, metadata review |
| **CONF** | Configuration & Deployment | 14 | Security headers, CORS, CSP, HSTS, admin interfaces |
| **IDNT** | Identity Management | 5 | Role definitions, registration, account enumeration |
| **ATHN** | Authentication | 11 | Default creds, lockout, auth bypass, MFA, password policy |
| **ATHZ** | Authorization | 5 | Directory traversal, auth bypass, privilege escalation, IDOR |
| **SESS** | Session Management | 11 | Cookie attributes, CSRF, session fixation/hijacking, JWT |
| **INPV** | Input Validation | 20 | XSS, SQLi, CMDi, SSTI, SSRF, path traversal, XXE, LDAP |
| **ERRH** | Error Handling | 2 | Error messages, stack traces |
| **CRYP** | Cryptography | 4 | TLS config, padding oracle, weak encryption |
| **BUSL** | Business Logic | 10 | Workflow bypass, request forgery, file upload, rate limits |
| **CLNT** | Client-Side | 14 | DOM XSS, clickjacking, open redirects, WebSockets, storage |
| **APIT** | API Testing | 3 | GraphQL, REST, SOAP |

Each test file includes:
- Step-by-step CLI procedures (curl commands, tool invocations)
- Payloads organized by bypass level (basic, intermediate, advanced)
- Detection criteria with severity assessment rubrics
- Remediation guidance with references

---

## Quality Assurance System

AutoPentest has a multi-layered QA system that prevents shallow testing:

### 1. Phase Gates (Automated)

After each phase, `phase_gate_check()` validates:
- All MUST-priority tests were executed
- Minimum coverage thresholds are met
- Tool coverage is adequate
- No critical gaps exist

**Blocked phases cannot proceed** until all issues are resolved.

### 2. Quality Reviewer (Per-Phase)

A subagent spawned at every phase transition that:
- Checks for 16 known anti-patterns (rubber-stamping, N/A cascades, finding inflation)
- Identifies untested endpoints and parameters
- Suggests vulnerability chaining opportunities
- Recommends alternative approaches for blocked tests

### 3. Final Judge (Post-Report)

A zero-context agent that reviews the completed engagement with fresh eyes:
- Analyzes coverage integrity across all domains
- Detects N/A cascades and their root causes
- Validates finding quality and evidence completeness
- Identifies missed attack surface
- Issues a verdict: **PASS**, **CONDITIONAL_PASS**, or **FAIL**

### 4. Exhaustion Gates

Marking a vulnerability as "not exploitable" requires proof of effort:

| Vuln Class | Min Techniques | Min Bypass Attempts |
|------------|:-:|:-:|
| XSS | 3 | 5 |
| SQL Injection | 3 | 5 |
| Command Injection | 3 | 5 |
| SSTI | 2 | 3 |
| SSRF | 3 | 5 |
| Path Traversal | 3 | 5 |

### 5. Evidence Checklists

Before logging any finding, evidence requirements are verified:
- Reproducible curl command
- Full HTTP request and response
- Proof of actual exploitation (not theoretical impact)
- Correct classification tier (EXPLOITED vs POTENTIAL)

---

## Example Report

A complete example report from a pentest against [PortSwigger's Gin & Juice Shop](https://ginandjuice.shop) (a deliberately vulnerable application) is included in the repository:

**[View Full Report](engagements/pentest-2026-ginandjuice/report.md)**

### What the Report Includes

The report demonstrates AutoPentest's output against a real target with 23 findings across all severity levels:

| Severity | Count | Examples |
|----------|:-----:|---------|
| Critical | 2 | UNION-based SQL injection with full data extraction, access control bypass via X-Original-URL header |
| High | 5 | Reflected XSS via JS string escape bypass, IDOR on order details, XXE with local file read, DOM XSS via prototype pollution |
| Medium | 6 | Missing security headers, no account lockout, missing CSP, CRLF injection, DOM-based open redirect |
| Low | 5 | Infrastructure info disclosure, EOL AngularJS, insecure ALB cookies, weak TLS config |
| Informational | 5 | Consolidated duplicates and secondary evidence for primary findings |

### Report Structure

```
1. Executive Summary         — Target scope, finding summary, domain architecture
2. Detailed Findings         — Each finding with description, evidence (curl commands), and remediation
3. Vulnerability Chaining    — Cross-finding analysis (e.g., XSS + no CSP = severity upgrade)
4. Test Coverage Matrix      — Per-category WSTG coverage (100% across 12 categories)
5. Tool Coverage Matrix      — 27/27 tools tracked, 8 actively run
```

### Sample Finding (SQL Injection)

From the report — a Critical SQL injection finding with full exploitation evidence:

```
FINDING-017: SQL Injection in /catalog category parameter — Full Data Extraction

Severity: Critical
WSTG Reference: WSTG-INPV-05

The category parameter is vulnerable to UNION-based SQL injection.
The attacker can:
  1. Inject a single quote to cause a 500 error (confirming injection)
  2. Use UNION SELECT with 8 columns to extract arbitrary data
  3. Enumerate tables: PRODUCTS, TRACKING, USERS
  4. Extract credentials from the USERS table

Evidence (reproducible curl command):
  curl -sk "https://ginandjuice.shop/catalog?category='+UNION+SELECT+1,USERNAME,PASSWORD,
  1,1,USERNAME,1,USERNAME+FROM+USERS+LIMIT+10--"
```

Every finding includes reproducible curl commands, full request/response evidence, and actionable remediation guidance.

---

## Configuration

### Engagement Config (YAML)

Config-driven pentests skip interactive questions and ensure consistency:

```yaml
target:
  url: https://app.example.com
  scope: [app.example.com, api.example.com]

authentication:
  login_type: sso                    # form | sso | api | manual | none
  login_url: https://app.example.com/login
  credentials:
    username: testuser
    password: secret123
  sso:
    provider: keycloak               # keycloak | auth0 | okta | azure_ad
    auth_domain: auth.example.com
    realm: myrealm
    client_id: my-app

rules:
  avoid:
    - { type: path, url_path: "/logout", description: "Skip logout" }
    - { type: endpoint, method: DELETE, url_path: "/api/admin/*", description: "No destructive admin ops" }
  focus:
    - { type: path, url_path: "/api", description: "Prioritize API" }

reporting:
  tester_name: "Security Team"
```

### MCP Server Configuration

The `.mcp.json` file registers two MCP servers:

```json
{
  "mcpServers": {
    "wstg-pentest": {
      "command": "uv",
      "args": ["--directory", "./server", "run", "server.py"]
    },
    "playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp"]
    }
  }
}
```

### Burp Suite Integration (Optional)

For passive traffic monitoring through Burp Suite Professional:

1. Start Burp Suite and enable the proxy on **all interfaces** (`0.0.0.0:8080`)
2. The Docker container automatically routes traffic through `host.docker.internal:8080`
3. All HTTP requests appear in Burp's proxy history for manual review

---

## Multi-Domain Testing

AutoPentest has first-class support for applications with multiple domains (e.g., a SPA frontend + API backend + SSO provider):

### Automatic Detection

During Phase 0, AutoPentest detects cross-domain authentication by following login redirects:

```
app.example.com → redirects to → auth.example.com/login
                 → after login → app.example.com/callback
```

All domains are automatically registered in scope with their type (app, auth_provider, api, cdn).

### Per-Domain Testing

Every WSTG test is evaluated per domain — not just the primary:

- Discovery tools (katana, ffuf, nuclei) run against **all** domains
- Input validation tools (sqlmap, dalfox) target endpoints on **every** domain with server-side processing
- A test is "not applicable" only when **no** domain has the tested feature

### Cross-Domain Authentication

Supported SSO protocols:
- **OAuth 2.0 / OIDC** (Authorization Code, PKCE, Password Grant, Client Credentials)
- **SAML** (SP-initiated flow)
- **Keycloak**, **Auth0**, **Okta**, **Azure AD**
- **Custom SSO** (redirect chain following with cookie jar)

Authentication escalation procedure (6 levels) ensures testing can proceed even with complex auth flows.

---

## Crash Recovery

AutoPentest is designed to survive interruptions:

### Automatic Checkpointing
- Phase gates auto-save checkpoints on PASS
- `git_checkpoint()` creates git snapshots of the engagement workspace
- Append-only logs (`findings.md`, `progress.log`) survive crashes

### Resume from Checkpoint

```
Resume engagement pentest-2026-02-11-myapp
```

This restores:
- All findings and test tracking data
- Coverage statistics and phase gate results
- Scope registrations and deliverables
- Instructions for what phase to continue from

### Manual Checkpoints

Save at any time:
```
Save a checkpoint before starting Phase 4 exploitation
```

### Rollback on Failure

If a phase produces bad results, roll back to the previous checkpoint:
```
Roll back the engagement to the last checkpoint
```

---

## Project Structure

```
autopentest-ai/
├── CLAUDE.md                          # Master pentest workflow (drives Claude Code)
├── .mcp.json                          # MCP server configuration
├── Dockerfile                         # Multi-stage Docker build (27 tools)
├── docker-compose.yml                 # Docker Compose alternative
├── Makefile                           # setup, start, stop, verify-tools, shell
│
├── server/
│   ├── server.py                      # FastMCP server (engagement mgmt, quality gates)
│   └── pyproject.toml                 # Python dependencies
│
├── knowledge-base/                    # OWASP WSTG knowledge base (109 test procedures)
│   ├── 01-information-gathering/      # 10 tests (WSTG-INFO-01 → 10)
│   ├── 02-configuration/              # 14 tests (WSTG-CONF-01 → 14)
│   ├── 03-identity-management/        # 5 tests  (WSTG-IDNT-01 → 05)
│   ├── 04-authentication/             # 11 tests (WSTG-ATHN-01 → 11)
│   ├── 05-authorization/              # 5 tests  (WSTG-ATHZ-01 → 05)
│   ├── 06-session-management/         # 11 tests (WSTG-SESS-01 → 11)
│   ├── 07-input-validation/           # 20 tests (WSTG-INPV-01 → 20)
│   ├── 08-error-handling/             # 2 tests  (WSTG-ERRH-01 → 02)
│   ├── 09-cryptography/              # 4 tests  (WSTG-CRYP-01 → 04)
│   ├── 10-business-logic/             # 10 tests (WSTG-BUSL-01 → 10)
│   ├── 11-client-side/                # 14 tests (WSTG-CLNT-01 → 14)
│   └── 12-api-testing/                # 3 tests  (WSTG-APIT-01 → 03)
│
├── templates/                         # Testing guides and procedures
│   ├── input-validation-guide.md      # Phase 4 step-by-step procedures
│   ├── testing-strategies.md          # Test matrices, chaining, parallel strategy
│   ├── cli-tools-guide.md             # Tool setup and Docker management
│   ├── tools.md                       # Per-tool command reference
│   ├── quality-gates.md               # Phase quality checklists and anti-patterns
│   ├── cross-domain-auth-guide.md     # SSO/OIDC/SAML procedures
│   ├── source-code-analysis.md        # Security-focused code review template
│   ├── pipelined-testing.md           # Phase 4 pipelined exploitation strategy
│   ├── shared/
│   │   ├── honesty-framework.md       # Anti-hallucination guardrails
│   │   ├── exploit-classification.md  # Three-tier finding classification
│   │   ├── reproducibility.md         # Evidence format requirements
│   │   └── scope-rules.md            # Avoid/focus rule templates
│   └── wordlists/                     # Tech-specific fuzzing wordlists
│
├── configs/
│   ├── example-config.yaml            # Example engagement configuration
│   └── config-schema.md               # YAML schema documentation
│
├── scripts/
│   ├── install-tools.sh               # Docker build + container start
│   ├── browser-auth.py                # Headless Chromium auth (JS-rendered logins)
│   ├── pkce-auth.py                   # OAuth 2.0 PKCE flow automation
│   └── status.sh                      # Engagement status dashboard
│
└── engagements/                       # Runtime output (git-ignored)
    └── /
        ├── findings.md                # Append-only findings log
        ├── progress.log               # Timestamped event log
        ├── report.md                  # Final pentest report
        ├── cookies.txt                # Cross-domain cookie jar
        └── tool-output/               # Raw CLI tool outputs
```

---

## Requirements

| Requirement | Version | Notes |
|-------------|---------|-------|
| Docker | 20.10+ | Docker Desktop on macOS/Windows |
| Claude Code | Latest | `npm install -g @anthropic-ai/claude-code` |
| uv | 0.1+ | `curl -LsSf https://astral.sh/uv/install.sh \| sh` |
| Node.js | 18+ | For Playwright MCP server |
| Python | 3.10+ | Managed by uv (no manual install needed) |
| Burp Suite Pro | Latest | **Optional** — for passive traffic monitoring |

**Supported platforms:** macOS (Apple Silicon & Intel), Linux (x86_64 & ARM64)

---

## FAQ

**Q: Does this replace a human penetration tester?**

No. AutoPentest automates the systematic, methodology-driven parts of a pentest. It excels at coverage (ensuring nothing is missed) and consistency (every test follows the same procedure). However, complex business logic, creative exploitation chains, and context-dependent risk assessment still benefit from human expertise. Think of it as a force multiplier.

**Q: How long does a full assessment take?**

It depends on the application's size and complexity. A typical medium-sized web app (50-100 endpoints) takes a few hours. Multi-domain applications with SSO take longer. The pipelined Phase 4 architecture parallelizes the most time-intensive testing.

**Q: Can I run this without Burp Suite?**

Yes. Burp Suite is optional and used only for passive traffic monitoring. All HTTP requests go through `docker exec curl` and all security tools run inside the Docker container. Without Burp, you lose the ability to review traffic in Burp's proxy history, but all testing functionality works.

**Q: How do I add custom wordlists or payloads?**

Place wordlists in `templates/wordlists/` and they'll be available inside the Docker container via the volume mount. The WSTG test files in `knowledge-base/` can also be customized with additional payloads.

**Q: Can I test applications behind a VPN?**

Yes. The Docker container inherits your host's network (on Linux with `--network host`) or reaches the host via `host.docker.internal` (on macOS/Windows). If your VPN is running on the host, the container can reach VPN-protected targets.

**Q: What about rate limiting?**

AutoPentest includes three-tier error classification (Transient/Rate Limit/Permanent) with automatic backoff. If the target rate-limits requests, tools automatically slow down. You can also set avoid rules in the config to skip specific endpoints.

---

## Disclaimer

**This tool is intended for authorized security testing only.** Only use AutoPentest against applications you have explicit permission to test. Unauthorized access to computer systems is illegal. The authors are not responsible for any misuse of this tool.

Always ensure you have:
- Written authorization from the application owner
- A clearly defined scope of what can and cannot be tested
- An understanding of the testing environment (production vs staging)
- Appropriate avoid rules configured for destructive or sensitive endpoints

---


  Built with Model Context Protocol and Claude Code