# Pentest

> Static-analysis penetration test that hunts for exploitable vulnerabilities with proof-of-concept payloads and fix code.

- Skill: `tinh2/pentest-2` (Agent Skill)
- Install (CLI): `npx skillmds@latest add tinh2/pentest-2`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tinh2/pentest-2/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: tinh2 (https://skillmd.com/u/tinh2)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/tinh2/pentest-2

---


You are in AUTONOMOUS MODE. Do NOT ask questions. Hunt for exploitable vulnerabilities methodically.

TARGET:
$ARGUMENTS

If no arguments provided, perform a full code-level penetration test of the project in the current working directory. If arguments specify a scope (e.g., "auth module", "API routes"), focus the analysis on that area.

============================================================
PHASE 0: RECONNAISSANCE
============================================================

Map the application's attack surface:

TECH STACK:
- Detect framework, language, database, auth mechanism
- Identify entry points (HTTP routes, WebSocket handlers, CLI commands, queue consumers)
- Map middleware chain (auth, validation, rate limiting, logging)

ROUTE INVENTORY:
- List ALL defined routes/endpoints with their HTTP methods
- Note which routes have authentication middleware
- Note which routes accept user input (body, query, params, headers, files)
- Flag routes that perform privileged operations

DATA FLOW MAPPING:
- Trace user input from entry point through processing to output/storage
- Identify where input is validated, sanitized, or escaped
- Identify where input reaches dangerous sinks (database, shell, filesystem, HTML)

Record the full attack surface map before beginning targeted analysis.

============================================================
PHASE 1: SQL / NOSQL INJECTION
============================================================

Hunt for injection points in database interactions:

SQL INJECTION:
- Search for string concatenation in SQL: `"SELECT * FROM " + table`
- Search for template literals in SQL: `` `SELECT * FROM ${table}` ``
- Search for format strings in SQL: `"SELECT * FROM %s" % table`
- Check ORM raw query methods for unsanitized input
- Check stored procedures called with dynamic parameters
- Verify parameterized queries are used consistently

NOSQL INJECTION:
- MongoDB: Search for `$where`, `$regex`, `$gt`, `$ne` with user input
- MongoDB: Check for object injection via `JSON.parse(userInput)` in queries
- Firestore: Check for user-controlled field paths in queries
- Redis: Check for user input in command strings

For each finding:
- **Location:** file:line
- **Severity:** Critical
- **Proof-of-concept:** Example malicious input that would exploit the flaw
- **Fix:** Parameterized query replacement code

============================================================
PHASE 2: CROSS-SITE SCRIPTING (XSS)
============================================================

Hunt for XSS vectors:

REFLECTED XSS:
- User input reflected in HTML responses without encoding
- Search parameters displayed on results pages
- Error messages containing user input
- URL path segments rendered in page content

STORED XSS:
- User-generated content (comments, profiles, messages) rendered without escaping
- File names displayed without sanitization
- User-uploaded HTML/SVG files served inline

DOM-BASED XSS:
- `document.write()` with URL fragments or query parameters
- `innerHTML` assignment with user-controlled data
- `eval()` or `Function()` with user input
- `location.href` / `window.open()` with user-controlled URLs
- jQuery `.html()` with unescaped data

TEMPLATE INJECTION:
- Server-side template injection (SSTI): user input in template strings
- Client-side: `dangerouslySetInnerHTML`, `v-html`, `[innerHTML]`, `{!! !!}`
- Missing auto-escape: `<%- %>` (EJS), `| safe` (Jinja2), `{{{ }}}` (Handlebars)

For each finding:
- **Location:** file:line
- **Severity:** High-Critical
- **Proof-of-concept:** `<script>alert(1)</script>` or context-specific payload
- **Fix:** Proper encoding/escaping code

============================================================
PHASE 3: AUTHENTICATION BYPASS
============================================================

Hunt for authentication weaknesses:

MISSING AUTH:
- Routes handling sensitive data without auth middleware
- Admin endpoints accessible without admin role check
- API endpoints that should require auth but do not
- WebSocket connections without authentication handshake

AUTH LOGIC FLAWS:
- JWT verification that can be bypassed (algorithm confusion, missing expiry check)
- Session tokens predictable or not cryptographically random
- Password reset tokens reusable or long-lived
- OAuth state parameter missing (CSRF on OAuth flow)
- Remember-me tokens without proper validation

CREDENTIAL ATTACKS:
- No rate limiting on login endpoint
- No account lockout after failed attempts
- User enumeration via different error messages (valid vs invalid email)
- Timing attacks on authentication (measurably different response times)

For each finding:
- **Location:** file:line or route definition
- **Severity:** Critical-High
- **Proof-of-concept:** Steps to bypass authentication
- **Fix:** Middleware addition or logic correction

============================================================
PHASE 4: AUTHORIZATION FLAWS
============================================================

Hunt for privilege escalation:

HORIZONTAL PRIVILEGE ESCALATION:
- Accessing other users' resources by changing ID parameters
- Missing ownership checks: `findById(req.params.id)` without `where: { userId: req.user.id }`
- Batch endpoints that do not filter by the requesting user
- File access without ownership verification

VERTICAL PRIVILEGE ESCALATION:
- Admin functions accessible by regular users
- Role changes possible without admin authorization
- Missing role checks on mutation endpoints (only checked on read)
- Client-side-only role enforcement (no server-side check)

MASS ASSIGNMENT:
- Request body spread directly into database updates: `Model.update(req.body)`
- User can set `role`, `isAdmin`, `balance` via API request
- GraphQL mutations accepting arbitrary fields

For each finding:
- **Location:** file:line
- **Severity:** Critical-High
- **Proof-of-concept:** Example API call exploiting the flaw
- **Fix:** Authorization middleware or ownership check code

============================================================
PHASE 5: PATH TRAVERSAL AND FILE INCLUSION
============================================================

Hunt for file system attacks:

PATH TRAVERSAL:
- User input in `fs.readFile()`, `open()`, `File()` without path sanitization
- File download endpoints using user-supplied filenames
- Pattern: `path.join(baseDir, userInput)` without `../` prevention
- Image/document serving with user-controlled paths

FILE UPLOAD:
- Missing file type validation (only checking extension, not magic bytes)
- Missing file size limits
- Uploaded files stored in web-accessible directories
- Uploaded filenames not sanitized (may contain `../` or special chars)
- No virus/malware scanning on uploads

LOCAL FILE INCLUSION:
- Dynamic `require()` or `import()` with user input
- Template file paths from user input
- Configuration file paths from user input

For each finding:
- **Location:** file:line
- **Severity:** High-Critical
- **Proof-of-concept:** `../../etc/passwd` or equivalent payload
- **Fix:** Path sanitization code

============================================================
PHASE 6: COMMAND INJECTION
============================================================

Hunt for command injection:

DIRECT INJECTION:
- `child_process.exec()` with user input: `exec("convert " + filename)`
- `os.system()`, `subprocess.run(shell=True)` with user arguments
- `Runtime.exec()` with unsanitized parameters
- Backtick execution with user data

INDIRECT INJECTION:
- User input in environment variables passed to subprocesses
- User-controlled arguments in CLI tool invocations
- CRON job expressions from user input
- Git commands with user-supplied branch/repo names

For each finding:
- **Location:** file:line
- **Severity:** Critical
- **Proof-of-concept:** `; cat /etc/passwd` or `$(whoami)` payload
- **Fix:** Use array-form exec, escape arguments, or avoid shell execution

============================================================
PHASE 7: CSRF AND REQUEST FORGERY
============================================================

Hunt for CSRF vulnerabilities:

MISSING CSRF PROTECTION:
- State-changing POST/PUT/DELETE endpoints without CSRF tokens
- Missing `SameSite` cookie attribute
- CORS allowing credentials with broad origins
- Form submissions without anti-CSRF tokens

SSRF:
- User-supplied URLs passed to HTTP clients (fetch, axios, requests)
- URL redirects without origin validation
- Webhook URLs from user input fetched server-side
- Image/preview URLs fetched without allowlist

OPEN REDIRECTS:
- Redirect URLs from query parameters without validation
- Login redirect (`?next=` or `?redirect=`) without allowlist
- OAuth callback URLs not properly validated

For each finding:
- **Location:** file:line
- **Severity:** Medium-High
- **Proof-of-concept:** Example malicious URL or forged request
- **Fix:** CSRF token implementation, URL validation code

============================================================
PHASE 8: SECRETS AND CREDENTIALS
============================================================

Hunt for hardcoded secrets:

PATTERNS TO SEARCH:
- API keys: strings matching `[A-Za-z0-9_-]{20,}` near key-related variables
- AWS keys: `AKIA[0-9A-Z]{16}`
- Private keys: `-----BEGIN (RSA |EC |)PRIVATE KEY-----`
- JWT secrets: hardcoded strings in JWT sign/verify calls
- Database passwords: connection strings with embedded credentials
- OAuth client secrets: hardcoded in source (not env vars)
- Encryption keys: hardcoded byte arrays or strings used as keys

CHECK CONFIGURATION:
- `.env` files committed (not in `.gitignore`)
- Secrets in `docker-compose.yml` (not using Docker secrets)
- Secrets in CI/CD config files (not using secret variables)
- Secrets in client-side/frontend code (visible to users)

For each finding:
- **Location:** file:line
- **Severity:** Critical
- **Secret type:** [what kind of credential]
- **Fix:** Move to environment variable or secret manager

============================================================
PHASE 9: INSECURE DESERIALIZATION
============================================================

Hunt for deserialization attacks:

- `JSON.parse()` on untrusted input used to construct queries or commands
- `pickle.loads()` on user-supplied data (Python)
- `yaml.load()` without `SafeLoader` (Python)
- `unserialize()` on user input (PHP)
- `ObjectInputStream` with untrusted data (Java)
- `Marshal.load()` on untrusted data (Ruby)
- XML parsing without disabling external entities (XXE)

For each finding:
- **Location:** file:line
- **Severity:** High-Critical
- **Proof-of-concept:** Malicious serialized payload structure
- **Fix:** Safe deserialization method or input validation


============================================================
SELF-HEALING VALIDATION (max 2 iterations)
============================================================

After producing the security analysis, validate thoroughness:

1. Verify every category in the audit was actually checked (not skipped).
2. Verify every finding has a specific file:line location.
3. Verify severity ratings are justified by impact assessment.
4. Verify no false positives by re-reading flagged code in context.

IF VALIDATION FAILS:
- Re-audit skipped categories or vague findings
- Verify or remove false positives
- Repeat up to 2 iterations

============================================================
OUTPUT
============================================================

## Penetration Test Report (Code Analysis)

**Project:** [name]
**Stack:** [detected technologies]
**Scope:** [full project or specified scope]
**Date:** [date]

### Executive Summary

| Category | Critical | High | Medium | Low |
|----------|----------|------|--------|-----|
| Injection (SQL/NoSQL) | N | N | N | N |
| XSS | N | N | N | N |
| Auth Bypass | N | N | N | N |
| Authorization Flaws | N | N | N | N |
| Path Traversal | N | N | N | N |
| Command Injection | N | N | N | N |
| CSRF/SSRF | N | N | N | N |
| Hardcoded Secrets | N | N | N | N |
| Insecure Deserialization | N | N | N | N |
| **Total** | **N** | **N** | **N** | **N** |

### Findings

For each finding, in severity order:

#### [SEVERITY] — [Finding Title]

- **Category:** [e.g., SQL Injection]
- **Location:** `path/to/file.ts:42`
- **Description:** [What the vulnerability is]
- **Proof-of-concept:**
  ```
  [Example exploit payload or steps]
  ```
- **Impact:** [What an attacker could achieve]
- **Fix:**
  ```
  [Code showing the remediation]
  ```

### Attack Surface Summary
- **Total routes:** N
- **Unauthenticated routes:** N
- **Routes accepting user input:** N
- **Routes with dangerous sinks:** N

### Remediation Priority
[Ordered list: Critical findings first, with effort estimates]

============================================================
NEXT STEPS
============================================================

After reviewing the pentest report:
- "Fix all Critical findings immediately — these are exploitable."
- "Run `/owasp` for a systematic OWASP Top 10 compliance check."
- "Run `/encryption` to address cryptographic weaknesses."
- "Run `/dependency-scan` to fix vulnerable component findings."
- "Run `/secure` after remediation to verify the security posture improved."


============================================================
SELF-EVOLUTION TELEMETRY
============================================================

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:
- Look for the project path in `~/.claude/projects/`
- If found, append to `skill-telemetry.md` in that memory directory

Entry format:
```
### /pentest — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}
```

Only log if the memory directory exists. Skip silently if not found.
Keep entries concise — /evolve will parse these for skill improvement signals.

============================================================
DO NOT
============================================================

- Do NOT execute actual exploits — this is static code analysis only.
- Do NOT send network requests to test vulnerabilities.
- Do NOT expose full secret values — redact all but first 4 characters.
- Do NOT modify any code — report findings with suggested fixes only.
- Do NOT report theoretical vulnerabilities without code evidence — every finding must cite a specific file and line.
- Do NOT conflate "possible" with "confirmed" — clearly state confidence level.
- Do NOT skip any phase — even if the project seems small, check all categories.
- Do NOT install external tools — analyze the source code directly.