@vigolium/piolium 0.0.1

package/skills/vuln-report/SKILL.md

@@ -0,0 +1,137 @@
+---
+name: vuln-report
+description: Draft a single-vulnerability report in GitHub advisory style from an audit finding, bug note, patch diff, PoC, or code review evidence. Use when Codex needs to turn one confirmed security issue into a clean disclosure-ready report with the fixed section set — Summary; Severity, Confidence, Vulnerability Type; Impact; Affected Component; Source to Sink Flow; Vulnerable Code; Proof of concept & Evidence; Preconditions; Remediation — with embedded code snippets, explanatory prose that points to the vulnerable code, and inline GitHub markdown links to source evidence.
+---
+
+# vuln-report.md
+
+## Overview
+
+Draft one disclosure-ready report for one confirmed bug. Keep the report evidence-driven, concrete, and concise. Prefer the section order and phrasing rules in [references/report-template.md](references/report-template.md).
+
+## Workflow
+
+1. Confirm the report is about one bug only.
+2. Extract the minimum facts needed to prove the issue:
+   - vulnerable component or behavior
+   - attacker-controlled input or missing validation
+   - preconditions and trust boundary
+   - exploit result
+   - practical impact
+   - strongest reproduction path
+   - decisive source locations and any relevant fix commit
+3. Separate demonstrated facts from inference. State assumptions explicitly.
+4. Draft the report using the required section order from [references/report-template.md](references/report-template.md).
+5. Always embed at least one fenced code snippet from the decisive code path, and explain what each snippet proves.
+6. Always convert repository file references and patch references into GitHub markdown links, and prefer embedding those links directly into the surrounding explanation instead of listing them separately.
+7. Keep the nine-section contract exactly; fold any enrichment (CWE/CVSS, preconditions, references) inside the relevant required section rather than adding new H2s.
+8. Save the final report as `report.md` inside a folder named with the bug's severity identifier (`C1`, `H1`, `M1`, etc.) followed by a lowercase hyphenated slug derived from the final report title. Use `C` for Critical, `H` for High, `M` for Medium, sequentially numbered if there are multiple bugs of the same severity. Example: `C1-cross-site-websocket-hijacking-re-enabled-by-allow-websocket/report.md`. Also, ensure the bug report title and internal references use this ID (e.g., '[C1] Cross-Site WebSocket Hijacking'). Do not write reports for Low severity findings — document them in the summary table only.
+9. Remove filler, hedging, and unproven claims before finalizing.
+
+## Required Sections
+
+The report begins with a single `# <Finding Title>` H1 (prefixed with the
+severity ID, e.g. `# [C1] SQL Injection in Login`), then exactly these H2
+sections, in this order, with these exact headings:
+
+1. `## Summary`
+2. `## Severity, Confidence, Vulnerability Type`
+3. `## Impact`
+4. `## Affected Component`
+5. `## Source to Sink Flow`
+6. `## Vulnerable Code`
+7. `## Proof of concept & Evidence`
+8. `## Preconditions`
+9. `## Remediation`
+
+This is a fixed contract — every report uses this exact set and order so the
+report-composer and downstream tooling can parse sections deterministically.
+Do **not** add a standalone `Details` or `Root Cause` section: the root-cause
+analysis is the closing paragraph of `## Source to Sink Flow`. Do not rename,
+reorder, merge, or drop any of the nine required sections even if a section is
+thin — write `None.` or `Not applicable.` rather than omitting it.
+
+## Evidence Rules
+
+- Include one or more fenced code snippets in the report, primarily in `Vulnerable Code` (and `Source to Sink Flow` where a snippet clarifies the path).
+- Use the smallest snippet that proves the bug.
+- Introduce each cited code location with a short explanation of why it matters; do not drop raw link lists without commentary.
+- Add GitHub markdown links for source files, line anchors, controllers, helpers, patch commits, or affected surfaces whenever the repository is on GitHub and the target URL is known or can be derived.
+- When constructing GitHub source links, use the latest commit SHA (from `git rev-parse HEAD` or the most recent commit visible in context) instead of a branch name such as `main` or `master`, so links remain stable after future commits.
+- Prefer embedding inline markdown links into explanatory sentences such as `The following code in [build_request](https://github.com/org/repo/blob/main/src/executor.rs#L10) reads attacker-controlled input without validation.`
+- Keep non-GitHub standards or spec citations as normal markdown links.
+
+## Self-Contained Rule
+
+`report.md` is a disclosure-ready artefact. The reader must understand the vulnerability, the trace, the impact, and the reproduction without opening any sibling working file (drafts, debate transcripts, review notes, internal metadata).
+
+- Do not write prose pointers such as `See draft.md`, `See debate.md`, `See adversarial-review.md`, `See metadata.json`, `See pN-NNN for full trace`, `See AP-NNN`, `Refer to the draft for impact analysis`, or `for the full trace see ...`. If that content is needed in the report, **inline it**.
+- Do not cite internal phase IDs (`pN-NNN`, `p10-NNN`, `AP-NNN`) — these are pipeline bookkeeping, not reader-facing references.
+- Sibling-file references are only allowed for runnable evidence artefacts shipped alongside the report (e.g. `poc.<ext>`, `evidence/<file>`), and only inside the `Proof of concept & Evidence` or `Impact` sections. Quote the decisive lines from logs inline rather than telling the reader to open them.
+- GitHub links to source code (pinned to a commit SHA) are external evidence, not deferred narrative — those are required, not banned.
+- Before finalizing, scan the draft for the banned phrasings above and rewrite any occurrence to inline the content.
+
+## Section Rules
+
+### Summary
+
+One short paragraph: the vulnerable behavior, the attacker control, and the outcome. Name the component only if it improves clarity.
+
+### Severity, Confidence, Vulnerability Type
+
+A compact block, not prose. State **Severity** (Critical/High/Medium with a one-line justification or CVSS vector), **Confidence** (how certain the finding is — e.g. `Confirmed (PoC executed)`, `Firm (code-traced, PoC theoretical)`, `Tentative`), and **Vulnerability Type** (the class, with `CWE-NNN` when known). This is the section that absorbs CWE/CVSS enrichment.
+
+### Impact
+
+Describe exploitability and consequence, not just severity labels: who is exposed, what the attacker gains, and which environments are most at risk. Distinguish observed impact (from `evidence/` logs) from inferred impact.
+
+### Affected Component
+
+Name the concrete component(s), service(s), endpoint(s), or module(s) in scope, with the primary file path(s). Keep it to the surface the bug lives on — not the full trace (that is the next section).
+
+### Source to Sink Flow
+
+Walk the path from attacker-controlled **source** to the dangerous **sink**: the exact entry point, the handlers/parsers/validation gates it passes, and where the protection is missing or bypassed. Name the specific branch, handler, or check. **Close this section with the root cause** — one or two sentences naming the design or implementation mistake in causal language (missing origin validation, unsafe trust in extension-derived MIME, policy enforced only in one execution mode, …). There is no separate Root Cause section; it lives here.
+
+### Vulnerable Code
+
+The smallest fenced code snippet(s) that prove the bug, each introduced by a one-line explanation of why it matters and accompanied by a GitHub markdown link pinned to the commit SHA. This is the decisive-snippet section — keep it tight.
+
+### Proof of concept & Evidence
+
+The shortest reliable reproduction: numbered steps and a runnable request/command/code block, with the expected result. If `poc.<ext>` exists, describe it in prose and reference its path; if `evidence/exploit.log` / `evidence/impact.log` exist, quote the decisive lines inline that prove the security effect. If there is no working PoC (theoretical/blocked finding), state that explicitly as `No working PoC — <PoC-Status>: <reason>` and fall back to the code-level evidence that establishes the bug.
+
+### Preconditions
+
+The conditions an attacker needs: authentication reality (`Auth-Required: yes/no` and which roles), attack vector / network position (remote vs local), non-default configuration, required state, and any exploit constraints. Absorbs the old "attack preconditions / authentication reality" enrichment.
+
+### Remediation
+
+The concrete fix: what to change and why it closes the source-to-sink gap. Include spec/guidance references or the fixing-commit metadata here when relevant. Prefer specific, actionable guidance over generic advice.
+
+## Enrichment Inside Required Sections
+
+There are no extra top-level sections. Anything that used to be an optional
+section now lives **inside** one of the nine required sections:
+
+- `CWE`, `CVSS` vector, and the vulnerability class → `## Severity, Confidence, Vulnerability Type`
+- authentication reality, non-default assumptions, exploit constraints, deployment qualifiers → `## Preconditions`
+- specification / guidance references, patch or fix-commit metadata → `## Remediation` (or inline in `## Source to Sink Flow` where it explains the gap)
+- affected surfaces / scope notes → `## Affected Component`
+
+Add this enrichment only when it is supported by evidence and improves triage.
+Never promote it to its own H2.
+
+## Quality Bar
+
+- Keep one bug per report.
+- Number bugs using severity prefixes (C1, H1, M1) and prefix both the report title and the folder name with this ID. Low severity findings are not reported individually.
+- Save each single-bug report to `<ID>-<title-slug>/report.md`.
+- Make the exploit story readable without external context — and explicitly without opening any sibling working file (`draft.md`, `debate.md`, `adversarial-review.md`, `metadata.json`). See the Self-Contained Rule.
+- No pointer prose to sibling narrative files or internal phase IDs (`pN-NNN`, `AP-NNN`). Inline the content.
+- Use exact file paths, endpoints, headers, options, or modes when they matter.
+- Distinguish observed behavior from likely impact.
+- Prefer measured severity language over inflated claims.
+- Preserve repository-specific terminology if the source material already uses it.
+- Include fenced code snippets and GitHub markdown links in every report.
+- End with a report that can be pasted into an advisory, audit finding, or maintainer issue with minimal cleanup.

package/skills/vuln-report/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "vuln-report"
+  short_description: "Draft single-issue GH advisory reports"
+  default_prompt: "Use $vuln-report to draft a GitHub advisory style vulnerability report from these findings."

package/skills/vuln-report/references/report-template.md

@@ -0,0 +1,135 @@
+# Report Template
+
+Use this template for a single confirmed (or theoretical) vulnerability. Remove placeholder notes before final output.
+
+## Required Shape
+
+Save the final report as `report.md` inside the finding directory (`<ID>-<slug>/report.md`). The H1 title is prefixed with the severity ID (e.g. `# [C1] ...`). The nine H2 sections below are a fixed contract — same set, same order, same headings, every time. Never add, rename, reorder, merge, or drop one; if a section is thin write `None.` / `Not applicable.` instead of omitting it.
+
+```md
+# [C1] <Finding Title>
+
+## Summary
+
+[One paragraph: vulnerable behavior, attacker control, outcome.]
+
+## Severity, Confidence, Vulnerability Type
+
+- **Severity:** Critical | High | Medium — [one-line justification or CVSS vector]
+- **Confidence:** Confirmed (PoC executed) | Firm (code-traced, PoC theoretical) | Tentative
+- **Vulnerability Type:** [class, e.g. SQL Injection] (`CWE-NNN`)
+
+## Impact
+
+[Who is affected, under what conditions, and what the attacker achieves. Separate observed impact (evidence/ logs) from inferred impact.]
+
+## Affected Component
+
+[Concrete component / service / endpoint / module in scope, with primary file path(s).]
+
+## Source to Sink Flow
+
+[Walk attacker-controlled source → dangerous sink: entry point, handlers/parsers/validation gates passed, where the protection is missing or bypassed. Name the exact branch/handler/check.]
+
+[Close with the root cause: one or two sentences naming the design or implementation mistake in causal language. There is no separate Root Cause section.]
+
+## Vulnerable Code
+
+[Why this snippet matters:] in [`path/to/file.ext`](https://github.com/org/repo/blob/<sha>/path/to/file.ext#L10):
+
+```language
+// Smallest decisive snippet from the vulnerable path
+```
+
+## Proof of concept & Evidence
+
+1. [Setup step]
+2. [Exploit step]
+3. [Observed or expected result]
+
+```bash
+# Minimal reproducible command or request
+```
+
+[If poc.<ext> exists, name it and quote the decisive evidence/exploit.log or evidence/impact.log lines inline. If there is no working PoC, write: `No working PoC — <PoC-Status>: <reason>` and give the code-level evidence that establishes the bug.]
+
+## Preconditions
+
+[Auth reality (Auth-Required: yes/no + roles), attack vector / network position (remote vs local), non-default config, required state, exploit constraints.]
+
+## Remediation
+
+[Concrete fix: what to change and why it closes the source-to-sink gap. Spec/guidance references or fixing-commit metadata go here when relevant.]
+```
+
+## Writing Rules
+
+### Global
+
+- Include fenced code snippets in every report (primarily in `Vulnerable Code`).
+- Use GitHub markdown links for repository files, line anchors, and commits, pinned to the commit SHA (`git rev-parse HEAD`), not a branch name.
+- Prefer linked file paths over bare URLs.
+- Store the finished report at `<ID>-<slug>/report.md`.
+
+### Summary
+
+- One paragraph. Mention the attacker-controlled input or missing validation and the resulting security effect.
+
+### Severity, Confidence, Vulnerability Type
+
+- A compact labelled block, not prose. This is where CWE/CVSS enrichment lives.
+- `Confidence` must reflect reality: `Confirmed (PoC executed)` only when a PoC actually ran.
+
+### Impact
+
+- Practical consequence first. Distinguish default exposure from non-default but realistic exposure. Distinguish observed from inferred.
+
+### Affected Component
+
+- The surface the bug lives on (component/endpoint/module + primary path) — not the full trace.
+
+### Source to Sink Flow
+
+- Walk from input to sink; name the exact branch, handler, parser, or validation gate.
+- End with the root cause: the fault, not the symptom, tied to the path just described.
+
+### Vulnerable Code
+
+- Smallest snippet(s) that prove the bug, each with a one-line "why it matters" lead-in and a SHA-pinned GitHub link.
+
+### Proof of concept & Evidence
+
+- Highest-confidence, deterministic reproduction. Say what result confirms success (`Expected result:` when not obvious).
+- Theoretical/blocked findings: explicitly state `No working PoC — <PoC-Status>: <reason>` then give code-level evidence.
+
+### Preconditions
+
+- Be specific about auth, network position/attack vector, and any non-default requirements.
+
+### Remediation
+
+- Specific, actionable fix tied to the root cause. No generic boilerplate.
+
+## Normalization Rules
+
+Normalize inconsistent source material into this shape:
+
+- Fold any `Details` / `Technical Details` narrative into `Source to Sink Flow`.
+- Fold any standalone `Root Cause` content into the closing paragraph of `Source to Sink Flow`.
+- Fold `Vulnerability Type` / `CWE` / `CVSS` into `Severity, Confidence, Vulnerability Type`.
+- Fold `Authentication Reality` / `Scope` / `Exploit Constraints` into `Preconditions`.
+- Fold `Affected Surfaces` into `Affected Component`.
+- Convert loose notes into concrete statements with actor, condition, and outcome.
+- Remove duplicate impact language repeated across sections.
+- Replace plain repository paths with SHA-pinned GitHub markdown links whenever possible.
+
+## Do Not Do This
+
+- Do not combine multiple bugs in one report.
+- Do not add, rename, reorder, or drop any of the nine required sections, or introduce extra H2s for enrichment.
+- Do not use bare repository paths when a GitHub markdown link is available.
+- Do not claim code execution, data exposure, or auth bypass unless the evidence supports it.
+- Do not claim `Confirmed (PoC executed)` unless a PoC actually ran.
+- Do not bury the main exploit condition inside a long background section.
+- Do not point the reader at sibling working files. Phrases like `See draft.md`, `See debate.md`, `See adversarial-review.md`, `See metadata.json`, `See pN-NNN for full trace`, `See AP-NNN`, `Refer to the draft for impact analysis`, or `for the full trace see ...` are banned. If the trace, hypothesis, impact, or adversarial review outcome is needed, inline it. The only sibling files a `report.md` may reference are runnable evidence artefacts (`poc.<ext>`, `evidence/<file>`) shipped alongside it.
+- Do not cite internal audit phase IDs (`pN-NNN`, `p10-NNN`, `AP-NNN`) — these are pipeline bookkeeping, not reader-facing references.

package/skills/wooyun-legacy/SKILL.md

@@ -0,0 +1,367 @@
+---
+name: wooyun-legacy
+description: >-
+  Provides web vulnerability testing methodology distilled from 88,636
+  real-world cases from the WooYun vulnerability database (2010-2016). Use when
+  performing penetration testing, security audits, code reviews for security
+  flaws, or vulnerability research. Covers SQL injection, XSS, command
+  execution, file upload, path traversal, unauthorized access, information
+  disclosure, and business logic flaws.
+allowed-tools:
+  - Read
+  - Grep
+  - Glob
+  - Bash
+---
+
+# WooYun Vulnerability Analysis Knowledge Base
+
+Methodology and testing patterns extracted from 88,636 real-world
+vulnerability cases reported to the WooYun platform (2010-2016).
+
+---
+
+## When to Use
+
+> All testing described here must be performed only against systems you
+> have written authorization to test.
+
+- Penetration testing web applications
+- Security code review (server-side or client-side)
+- Vulnerability research against web targets you have explicit authorization to test
+- Building security test cases or checklists
+- Assessing web application attack surface
+- Reviewing remediation effectiveness
+- Training or education in authorized security testing contexts
+
+## When NOT to Use
+
+- Network infrastructure testing (firewalls, routers, switches)
+- Mobile application binary analysis
+- Malware analysis or reverse engineering
+- Compliance-only assessments (PCI-DSS, SOC2 checklists without testing)
+- Physical security assessments
+- Social engineering campaigns
+- Cloud infrastructure misconfigurations (IAM, S3 buckets) — these
+  require cloud-specific tooling, not web vuln patterns
+
+## Rationalizations to Reject
+
+These shortcuts lead to missed findings. Reject them:
+
+- "The WAF will catch it" — WAFs are bypass-able; test the application
+  logic, not the middleware
+- "It's an internal app, so auth doesn't matter" — internal apps get
+  compromised via SSRF, lateral movement, and credential reuse
+- "We already use parameterized queries everywhere" — check for ORM
+  misuse, stored procedures with dynamic SQL, and second-order injection
+- "The framework handles XSS" — template engines have raw output modes,
+  JavaScript contexts bypass HTML encoding, and DOM XSS lives
+  entirely client-side
+- "File uploads are safe because we check the extension" — extension
+  checks are bypassed via null bytes, double extensions, parser
+  discrepancies, and race conditions
+- "We validate on the frontend" — client-side validation is a UX
+  feature, not a security control
+- "Nobody would guess that URL" — security through obscurity fails
+  against directory bruteforcing, referrer leaks, and JS source analysis
+- "Low severity, not worth reporting" — low-severity findings chain
+  into critical attack paths
+
+---
+
+## Core Mental Model
+
+```
+Vulnerability = Expected Behavior - Actual Behavior
+             = Developer Assumptions + Attacker Input -> Unexpected State
+
+Analysis chain:
+1. Where does data come from?  (Input sources)
+   -> GET/POST/Cookie/Header/File/WebSocket
+2. Where does data flow?       (Data path)
+   -> Validation -> Processing -> Storage -> Output
+3. Where is data trusted?      (Trust boundaries)
+   -> Client / Server / Database / OS / External service
+4. How is data processed?      (Processing logic)
+   -> Filter / Escape / Validate / Execute
+5. Where does data end up?     (Output sinks)
+   -> HTML / SQL / Shell / Filesystem / Log / Email
+```
+
+---
+
+## Attack Surface Mapping
+
+```
+              +-------------------------------------------+
+              |         Application Attack Surface         |
+              +-------------------------------------------+
+                                  |
+          +-----------------------+-----------------------+
+          |                       |                       |
+     +----v----+            +-----v-----+           +-----v-----+
+     |  Input  |            | Processing|           |  Output   |
+     +---------+            +-----------+           +-----------+
+     | GET     |            | Input     |           | HTML page |
+     | POST    |    ->      | validation|    ->     | JSON resp |
+     | Cookie  |            | Biz logic |           | File DL   |
+     | Headers |            | DB query  |           | Error msg |
+     | File    |            | File op   |           | Log entry |
+     | Upload  |            | Sys call  |           | Email     |
+     +---------+            +-----------+           +-----------+
+```
+
+---
+
+## SQL Injection
+
+**Cases:** 27,732 | **Reference:** [sql-injection.md]({baseDir}/references/sql-injection.md)
+| **Checklist:** [sql-injection-checklist.md]({baseDir}/references/checklists/sql-injection-checklist.md)
+
+High-risk parameters: `id`, `sort_id`, `username`, `password`, `search`,
+`keyword`, `page`, `order`, `cat_id`
+
+Injection point detection:
+- String terminators: `'  "  )  ')  ")  --  #  /*`
+- DB fingerprint: `@@version` (MSSQL), `version()` (MySQL),
+  `v$version` (Oracle)
+
+Bypass techniques:
+- Whitespace: `/**/  %09  %0a  ()`
+- Keywords: `SeLeCt  sel%00ect  /*!select*/`
+- Equals: `LIKE  REGEXP  BETWEEN  IN`
+- Quotes: `0x` hex, `char()`, `concat()`
+
+Core defense: parameterized queries (PreparedStatement / ORM binding).
+
+---
+
+## Cross-Site Scripting (XSS)
+
+**Cases:** 7,532 | **Reference:** [xss.md]({baseDir}/references/xss.md)
+| **Checklist:** [xss-checklist.md]({baseDir}/references/checklists/xss-checklist.md)
+
+Output points: user profile fields (nickname, bio), search reflections,
+file metadata (filename, alt text), email content (subject, body)
+
+Bypass techniques:
+- Tag mutation: `<ScRiPt>  <script/x>  <script\n>`
+- Event handlers: `onerror  onload  onmouseover  onfocus`
+- Encoding: HTML entities, JS Unicode, URL encoding
+- Protocol handlers: `javascript:  data:  vbscript:`
+
+Core defense: context-aware output encoding + Content Security Policy.
+
+---
+
+## Command Execution
+
+**Cases:** 6,826 | **Reference:** [command-execution.md]({baseDir}/references/command-execution.md)
+| **Checklist:** [command-execution-checklist.md]({baseDir}/references/checklists/command-execution-checklist.md)
+
+Entry points: system command wrappers (ping, traceroute, nslookup),
+file operations (compress, decompress, image processing), code eval
+(`eval`, `assert`, `preg_replace(/e)`), framework vulnerabilities
+(Struts2, WebLogic, JBoss)
+
+Command chaining:
+- Linux: `;  |  ||  &&  \`  $()`
+- Windows: `&  |  ||  &&`
+
+Bypass techniques:
+- Whitespace: `${IFS}  $IFS$9  %09  <  <>`
+- Keywords: `ca\t  ca''t  c$@at  /???/??t`
+- Encoding: `$(printf "\x63\x61\x74")`,
+  `` `echo Y2F0|base64 -d` ``
+
+Core defense: avoid shell invocation; use `execFile` over `exec`,
+allowlist acceptable inputs.
+
+---
+
+## File Upload
+
+**Cases:** 2,711 | **Reference:** [file-upload.md]({baseDir}/references/file-upload.md)
+| **Checklist:** [file-upload-checklist.md]({baseDir}/references/checklists/file-upload-checklist.md)
+
+Bypass detection:
+- Client-side validation: modify JS or send request directly
+- Content-Type: `image/gif` header + PHP code body
+- Extension: `.php5  .phtml  .pht  .php.  .php::$DATA`
+- Content inspection: `GIF89a` + `<?php` or image-based webshell
+- Parser discrepancy: `/upload/1.asp;.jpg` (IIS 6.0)
+
+Parser-specific vulnerabilities:
+- IIS 6.0: `/test.asp/1.jpg`, `test.asp;.jpg`
+- Apache: `.php.xxx` (unknown extension fallback)
+- Nginx: `/1.jpg/1.php` (`cgi.fix_pathinfo`)
+- Tomcat: `test.jsp%00.jpg`
+
+Core defense: allowlist extensions, rename uploads, store outside
+webroot, validate content type server-side.
+
+---
+
+## Path Traversal
+
+**Cases:** 2,854 | **Reference:** [path-traversal.md]({baseDir}/references/path-traversal.md)
+| **Checklist:** [path-traversal-checklist.md]({baseDir}/references/checklists/path-traversal-checklist.md)
+
+High-risk parameters: `file`, `path`, `filename`, `url`, `dir`,
+`template`, `page`, `include`, `download`
+
+Traversal payloads:
+- Basic: `../../../etc/passwd`
+- Encoded: `%2e%2e%2f`, `..%252f`, `%c0%ae%c0%ae/`
+- Null byte: `../../../etc/passwd%00.jpg`
+- Windows: `..\..\..\windows\win.ini`
+
+Target files (Linux): `/etc/passwd`, `/etc/shadow`,
+`/proc/self/environ`, `/var/log/apache2/access.log`
+
+Core defense: resolve canonical paths, validate against allowlisted
+directories, never use user input in file paths directly.
+
+---
+
+## Unauthorized Access
+
+**Cases:** 14,377 | **Reference:** [unauthorized-access.md]({baseDir}/references/unauthorized-access.md)
+| **Checklist:** [unauthorized-access-checklist.md]({baseDir}/references/checklists/unauthorized-access-checklist.md)
+
+Access types:
+- Admin panel exposure: `/admin`, `/manager`, `/console`
+- API without authentication: missing token validation, predictable
+  tokens
+- Exposed services: Redis (6379), MongoDB (27017),
+  Elasticsearch (9200), Memcached (11211), Docker (2375)
+- IDOR: horizontal privilege escalation via ID enumeration
+
+Core defense: authentication + authorization on every endpoint,
+session management, principle of least privilege.
+
+---
+
+## Information Disclosure
+
+**Cases:** 7,337 | **Reference:** [info-disclosure.md]({baseDir}/references/info-disclosure.md)
+| **Checklist:** [info-disclosure-checklist.md]({baseDir}/references/checklists/info-disclosure-checklist.md)
+
+Disclosure sources: error messages with stack traces, exposed `.git`
+or `.svn` directories, backup files (`.bak`, `.sql`, `.tar.gz`),
+configuration files, debug endpoints, directory listings
+
+Core defense: custom error pages, disable directory listing, remove
+debug endpoints in production, audit publicly accessible files.
+
+---
+
+## Business Logic Flaws
+
+**Cases:** 8,292 | **Reference:** [logic-flaws.md]({baseDir}/references/logic-flaws.md)
+| **Checklist:** [logic-flaws-checklist.md]({baseDir}/references/checklists/logic-flaws-checklist.md)
+
+Vulnerability patterns:
+- Password reset: verification code in response body, step skipping,
+  controllable reset tokens
+- Authorization bypass: horizontal (ID enumeration), vertical (role
+  escalation)
+- Payment logic: amount tampering, quantity manipulation, coupon
+  stacking
+- CAPTCHA: not refreshed, reusable, brute-forceable, client-side only
+
+Testing approach:
+1. Map the business flow -> draw state transition diagram
+2. Identify critical checks -> which parameters determine outcomes
+3. Attempt bypass -> modify parameters / skip steps / replay / race
+4. Verify impact -> prove the scope of harm
+
+Core defense: server-side validation of all business-critical logic.
+
+---
+
+## Additional Categories
+
+These categories are derived from case data without full reference
+documents. Each has a testing checklist extracted from real cases.
+
+| Category | Checklist |
+|----------|-----------|
+| CSRF | [csrf-checklist.md]({baseDir}/references/checklists/csrf-checklist.md) |
+| SSRF | [ssrf-checklist.md]({baseDir}/references/checklists/ssrf-checklist.md) |
+| Weak Passwords | [weak-password-checklist.md]({baseDir}/references/checklists/weak-password-checklist.md) |
+| Misconfiguration | [misconfig-checklist.md]({baseDir}/references/checklists/misconfig-checklist.md) |
+| Remote Code Execution | [rce-checklist.md]({baseDir}/references/checklists/rce-checklist.md) |
+| XML External Entity (XXE) | [xxe-checklist.md]({baseDir}/references/checklists/xxe-checklist.md) |
+
+> **Note:** The RCE checklist covers deserialization, OGNL injection, and
+> framework-specific remote code execution — distinct from the OS command
+> injection focus of the Command Execution reference above.
+
+---
+
+## Methodology Case Studies
+
+Real-world penetration testing methodology examples (anonymized):
+
+| Case Study | Description |
+|------------|-------------|
+| [bank-penetration.md]({baseDir}/references/bank-penetration.md) | Multi-stage attack chain against a financial institution |
+| [telecom-penetration.md]({baseDir}/references/telecom-penetration.md) | Infrastructure penetration of a telecom carrier |
+
+These demonstrate how individual vulnerabilities chain together into
+full compromise scenarios.
+
+---
+
+## Testing Priority Framework
+
+### High Priority (test first)
+
+1. **SQL Injection** — direct data access, highest case count (27,732)
+2. **Command Execution** — OS-level compromise
+3. **File Upload** — arbitrary code execution via webshell
+
+### Medium Priority
+
+4. **Unauthorized Access** — second-highest case count (14,377)
+5. **Business Logic Flaws** — application-specific, hard to automate
+6. **XSS** — session hijacking, phishing
+
+### Lower Priority (but still important)
+
+7. **Path Traversal** — file read, sometimes write
+8. **Information Disclosure** — reconnaissance value, enables chaining
+9. **CSRF/SSRF/XXE** — context-dependent severity
+
+---
+
+## Defense Quick Reference
+
+| Vulnerability | Core Defense | Implementation |
+|---------------|-------------|----------------|
+| SQL Injection | Parameterized queries | PreparedStatement / ORM |
+| XSS | Output encoding | Context-aware escaping + CSP |
+| Command Execution | Avoid shell | `execFile` not `exec`, allowlist |
+| File Upload | Strict validation | Allowlist ext, rename, isolate |
+| Path Traversal | Canonical paths | Resolve + validate against allowlist |
+| Unauthorized Access | Access control | AuthN + AuthZ + session mgmt |
+| Logic Flaws | Server-side checks | Validate all business logic server-side |
+| Info Disclosure | Minimize exposure | Custom errors, no debug in prod |
+
+---
+
+## Key Insight
+
+All 88,636 vulnerabilities in this database share a common root cause:
+the gap between what developers assumed and what attackers actually
+provided. Effective security testing means systematically challenging
+every assumption at every trust boundary.
+
+Four principles from the data:
+1. **Boundary thinking** — all vulnerabilities occur at trust boundaries
+2. **Data flow tracing** — follow data from input to output completely
+3. **Assumption challenging** — question every "obvious" validation
+4. **Chain composition** — individual low-severity findings combine
+   into critical attack paths