If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/Threekiii/Awesome-POC shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Missing license — unclear to depend on

• Last commit 2w ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ No license — legally unclear to depend on
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live Threekiii/Awesome-POC repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Threekiii/Awesome-POC.

What it runs against: a local clone of Threekiii/Awesome-POC — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in Threekiii/Awesome-POC | Confirms the artifact applies here, not a fork | | 2 | Default branch master exists | Catches branch renames | | 3 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 4 | Last commit ≤ 45 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Threekiii/Awesome-POC. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Threekiii/Awesome-POC.git
#   cd Awesome-POC
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of Threekiii/Awesome-POC and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "Threekiii/Awesome-POC(\\.git)?\\b" \\
  && ok "origin remote is Threekiii/Awesome-POC" \\
  || miss "origin remote is not Threekiii/Awesome-POC (artifact may be from a fork)"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "CMS漏洞/Discuz 3.4 最新版后台getshell.md" \\
  && ok "CMS漏洞/Discuz 3.4 最新版后台getshell.md" \\
  || miss "missing critical file: CMS漏洞/Discuz 3.4 最新版后台getshell.md"
test -f "CMS漏洞/Drupal Drupalgeddon 2 远程代码执行漏洞 CVE-2018-7600.md" \\
  && ok "CMS漏洞/Drupal Drupalgeddon 2 远程代码执行漏洞 CVE-2018-7600.md" \\
  || miss "missing critical file: CMS漏洞/Drupal Drupalgeddon 2 远程代码执行漏洞 CVE-2018-7600.md"
test -f "CMS漏洞/WordPress File Manager＜6.9 RCE CVE-2020-25213.md" \\
  && ok "CMS漏洞/WordPress File Manager＜6.9 RCE CVE-2020-25213.md" \\
  || miss "missing critical file: CMS漏洞/WordPress File Manager＜6.9 RCE CVE-2020-25213.md"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "CMS漏洞/CraftCMS 未授权远程代码执行漏洞 CVE-2023-41892.md" \\
  && ok "CMS漏洞/CraftCMS 未授权远程代码执行漏洞 CVE-2023-41892.md" \\
  || miss "missing critical file: CMS漏洞/CraftCMS 未授权远程代码执行漏洞 CVE-2023-41892.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 45 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~15d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/Threekiii/Awesome-POC"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Awesome-POC is a curated knowledge base of 1000+ vulnerability Proof-of-Concepts organized by vulnerability type (CMS, web frameworks, network services). It documents real exploitable flaws across Java, Python, and Dockerfile-based applications, with markdown files detailing CVE numbers, affected versions, vulnerability classifications (SQL injection, RCE, CSRF, XSS, file upload), and exploitation techniques—serving as a searchable security research reference. Flat directory structure: top-level folder 'CMS漏洞' (CMS Vulnerabilities) contains markdown files named by vulnerability pattern (e.g., 'DedeCMS 5.7 file_manage_control.php 文件包含 RCE CVE-2023-2928.md'). No subfolders visible in top 60 files—appears to be a single-folder taxonomy organized by CMS product name.

Security researchers, penetration testers, and bug bounty hunters who need to understand real vulnerability patterns in production systems. Specifically: developers auditing legacy CMS platforms (Discuz, DedeCMS, Drupal, Joomla), system administrators validating patch coverage, and security engineers building detection rules.

Actively maintained reference database with 1k+ documented vulnerabilities and recent CVE additions (CVE-2025-32432, CVE-2024-56145). No package.json or test framework visible—it's a documentation-heavy knowledge base rather than a software library. Appears production-ready as a knowledge source but lacks CI/CD infrastructure typical of runnable projects.

No dependency management risk as this is primarily markdown documentation. Single maintainer (Threekiii) creates update recency risk. The repo contains real working exploits which could aid malicious actors, making it sensitive; relies on users' legal and ethical judgment. Last-commit visibility needed to assess maintenance cadence.

Recent activity shows documentation of cutting-edge CVEs (Craft CMS CVE-2025-32432 and CVE-2024-56145 added), indicating active monitoring of zero-day and recent-disclosure vulnerabilities. Unknown if exploratory branches or new vulnerability categories are being added without commit history visible.

Clone the repo: git clone https://github.com/Threekiii/Awesome-POC.git && cd Awesome-POC. No build step required—markdown files are directly readable. Optionally search: grep -r 'CVE-2024' CMS漏洞/ to find recent vulnerabilities.

Daily commands: No build/run cycle—this is a reference database. Clone and cd CMS漏洞/ then open .md files in any text editor or GitHub viewer. Use find . -name '*.md' | wc -l to verify 1k+ files, or grep -l 'CVE-' CMS漏洞/*.md to filter to CVE-documented vulnerabilities.

• CMS漏洞/Discuz 3.4 最新版后台getshell.md — Documents one of the most prevalent CMS vulnerabilities; essential for understanding the knowledge base's scope and severity classification
• CMS漏洞/Drupal Drupalgeddon 2 远程代码执行漏洞 CVE-2018-7600.md — High-impact RCE vulnerability affecting major open-source CMS; critical reference for assessing vulnerability severity patterns
• CMS漏洞/WordPress File Manager＜6.9 RCE CVE-2020-25213.md — WordPress ecosystem vulnerability; demonstrates the knowledge base's coverage of plugin-based exploits
• README.md — Project disclaimer, navigation structure, and classification system; mandatory reading for understanding ethical scope and contribution guidelines
• CMS漏洞/CraftCMS 未授权远程代码执行漏洞 CVE-2023-41892.md — Recent zero-day type vulnerability; shows the knowledge base's currency and relevance to active threats
• CMS漏洞/DedeCMS 5.7 file_manage_control.php 文件包含 RCE CVE-2023-2928.md — Multi-stage exploitation chain (LFI→RCE); exemplifies complex vulnerability documentation patterns used throughout

• Markdown PoC Documents (Markdown, GitHub Flavored Markdown (GFM)) — Each .md file encapsulates a single vulnerability: description, affected versions, exploitation steps, payload code/HTTP requests, and remediation
  • Failure mode: Outdated/incorrect PoC steps lead to failed exploitation attempts; incomplete payload examples frustrate researchers
• README Navigation Index (Markdown with hyperlinks) — Hierarchical listing of CMS categories and individual vulnerabilities; entry point for browsing and discovery
  • Failure mode: Broken links or outdated category structure prevent access to documented vulnerabilities; missing entries reduce knowledge base utility
• Category Folders (CMS漏洞/) (GitHub file system directory structure) — Top-level organization by target CMS platform; enables rapid scoping when analyst targets specific software (WordPress, Drupal, Joomla, etc.)
  • Failure mode: Miscategorization or missing folder structure forces researchers to search entire repository; reduces usability
• Visual Evidence (images/ subdirectory) (PNG image files, GitHub image embedding) — Screenshot and diagram PNG files providing proof-of-exploitation and visual walkthrough of multi-step attack chains
  • Failure mode: Missing, corrupted, or stale screenshots reduce credibility of PoCs; researchers cannot visually verify exploitation feasibility
• Legal Disclaimer (Markdown with prominent formatting) — Clear terms of use and ethical scope defined in README.md; establishes authorized-use-only policy and links to Awesome-Laws reference
  • Failure mode: Absent or unclear disclaimer increases legal liability for maintainers; unclear scope invites misuse of repository

• Security Researcher → GitHub Repository README.md — Researcher browses project overview, disclaimer, and category index
• GitHub Repository README.md → CMS漏洞/ category folder — Navigation links direct researcher to target CMS type (e.g., WordPress, Drupal)
• CMS漏洞/ folder → Individual vulnerability .md file — Researcher selects specific CVE or vulnerability name to retrieve PoC details
• `` → undefined — undefined

Add a New CMS Vulnerability PoC

1. Create new Markdown file in CMS漏洞/ directory with naming pattern: '[CMS Name] [Version] [Vulnerability Type] [CVE].md' (CMS漏洞/[NewVulnerability].md)
2. Include exploitation prerequisites, vulnerability description, step-by-step PoC code/requests, and remediation guidance (CMS漏洞/[NewVulnerability].md)
3. Add embedded screenshots to CMS漏洞/images/ if demonstrating visual exploitation steps (CMS漏洞/images/[screenshot].png)
4. Update README.md section '项目导航' to link new vulnerability entry with category classification (README.md)

Document a Plugin-Based Vulnerability

1. Create markdown following format: '[CMS] [Plugin Name] [Vulnerable Function] [Exploit Type] [CVE].md' (CMS漏洞/[Plugin]_[CVE].md)
2. Highlight the plugin dependency and version range affected; include installation context (CMS漏洞/[Plugin]_[CVE].md)
3. Provide HTTP request payloads or code snippets demonstrating exploitation against default plugin configuration (CMS漏洞/[Plugin]_[CVE].md)

Add CVE Reference and Timeline

1. Include CVE identifier in filename and document discovery/public disclosure dates (CMS漏洞/[Vulnerability]_CVE-[ID].md)
2. Reference official NVP/CVE database links and affected version ranges (CMS漏洞/[Vulnerability]_CVE-[ID].md)
3. Document patch/upgrade version where vulnerability was remediated (CMS漏洞/[Vulnerability]_CVE-[ID].md)

• Markdown format (.md files) — Human-readable documentation that is version-control friendly, lightweight, and platform-agnostic; enables easy contribution and review via GitHub
• GitHub repository structure — Provides free distributed hosting, collaborative contribution workflow, issue tracking, and natural discoverability for security community
• Directory-based categorization by CMS type — Enables rapid vulnerability lookup by target platform; aligns with real-world penetration testing workflows where analysts work within specific CMS ecosystems
• Embedded PNG screenshots in /images subdirectory — Visual proof-of-concept aids understanding of multi-step exploitation chains and UI-based vulnerabilities without external dependencies

• Static Markdown documentation rather than interactive web platform

  • Why: Simplifies maintenance, reduces hosting costs, ensures content persistence independent of service availability, and leverages GitHub's native rendering
  • Consequence: Reduced discoverability compared to searchable database; no structured querying by vulnerability metadata (CVSS, date, severity)

• Flat file organization by CMS category rather than normalized database

  • Why: Enables offline access, version control diffs, and community pull requests without database schema coordination
  • Consequence: Difficulty detecting duplicates across vendors; limited cross-vulnerability analysis (e.g., all SQLi vulnerabilities globally)

• No code execution or live exploit hosting

  • Why: Minimizes legal liability and ensures platform is knowledge/documentation only, not weaponized tool distribution
  • Consequence: Users must independently research and implement PoCs; higher barrier to entry for less-experienced practitioners

• Does not provide automated exploit tool execution or scanning infrastructure
• Does not host live vulnerable applications for practice/lab environments
• Does not track remediation status or patching recommendations across vendor landscape
• Not a real-time vulnerability feed or threat intelligence platform
• Does not include source code analysis or binary decompilation tools
• Does not enforce license compliance or supply chain security analysis

No hidden traps for reading documentation. However: (1) All vulnerability content is in Chinese; contributors must be comfortable with Chinese file names and descriptions. (2) The repo explicitly disclaims liability for misuse—legal exposure if PoCs are used for unauthorized testing. (3) Real exploit code (Java/Python/Docker) is present but not shown in file listing; location of runnable exploits vs. documentation unclear. (4) No automated CVE tracking; new vulnerabilities must be manually researched and added.

• SQL Injection — Appears in ~15% of CMS vulnerabilities in this repo (DedeCMS, Ke361, OpenSNS); understanding parameterized queries vs. string concatenation is essential for secure CMS code review
• Remote Code Execution (RCE) — Most critical vulnerability class documented here (Drupal, CraftCMS, DedeCMS); separates high-severity exploits from defacement attacks
• Arbitrary File Upload — Common escalation vector in CMS platforms (OpenSNS, OKLite, CmsEasy); enables shell deployment if combined with executable file type bypass
• Deserialization Attacks — High-impact Java-specific flaws (Liferay, Joomla, Craft CMS); unsafe unserialize() of untrusted data leads to RCE when gadget chains exist
• Cross-Site Request Forgery (CSRF) — Admin interface vulnerability class documented here (74cms, Anchor CMS); requires token validation to prevent unauthorized state changes
• Global Variable Override — Specific to legacy PHP (Discuz 7.x/6.x); register_globals and extract() can pollute variable namespace and bypass security filters
• [CVE/CNVD Numbering & Disclosure Timeline](https://cve.mitre.org/ and https://www.cnvd.org.cn/) — This repo uses both CVE (US-centric) and CNVD (Chinese) IDs; understanding disclosure responsibility windows and patch priority requires tracking multiple numbering systems

• PeiQi/PeiQi-WIKI-POC — Parallel Chinese vulnerability PoC knowledge base with similar CMS focus; shares audience of Chinese-speaking security researchers
• projectdiscovery/nuclei-templates — Community-driven vulnerability detection templates that automate testing for known CVEs; complementary tool for scanning systems against vulnerabilities documented here
• rapid7/metasploit-framework — Canonical exploit framework where many of these CVEs are already implemented; users cross-reference this repo to understand root causes before using MSF modules
• vulhub/vulhub — Docker-based vulnerable environment collection; often used in tandem with Awesome-POC to spin up test targets and validate PoCs locally
• Threekiii/Awesome-Laws — Companion repo providing legal/regulatory framework for responsible vulnerability research and disclosure in different jurisdictions

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Create a vulnerability metadata index and validation schema

The repo contains 100+ markdown files with inconsistent metadata formats (CVE numbers, vulnerability types, affected versions). A structured index file (JSON/YAML) with validation would enable automated testing, prevent duplicates, improve searchability, and allow tools to parse vulnerability data programmatically. This is critical for a knowledge base meant to be machine-readable.

• [ ] Create a schema file (e.g., vulnerability-schema.json) defining required fields: product_name, cve_id, vulnerability_type, affected_versions, poc_link, date_added
• [ ] Generate an index.json from all CMS漏洞/*.md files extracting metadata from frontmatter/headers
• [ ] Add a GitHub Action workflow (.github/workflows/validate-poc.yml) to lint and validate all markdown files against the schema on each PR
• [ ] Add a validation script (e.g., scripts/validate-metadata.js) to check for duplicates, malformed CVE numbers, and missing required fields

Add a searchable vulnerability catalog with filtering and statistics

Currently the repo is only browsable as a flat file structure. Adding a generated catalog (HTML/JSON API or via a simple GitHub Pages site) would greatly improve discoverability. Contributors and users could filter by CMS type, vulnerability class (SQLi, RCE, XSS, etc.), CVE, or year—driving more utility from the 1000+ entries already collected.

• [ ] Create a scripts/generate-catalog.js that parses all markdown files and extracts: product, vulnerability_type, cve_id, affected_versions, and description
• [ ] Output to docs/catalog.json with hierarchical structure (grouped by CMS vendor, then by vulnerability type)
• [ ] Add a simple docs/index.html with JavaScript to display an interactive table with filter dropdowns (by CMS, by vulnerability type, by CVE year)
• [ ] Add a GitHub Action to auto-regenerate docs/catalog.json and commit it on each PR that modifies CMS漏洞/*.md files

Standardize PoC file naming and add a file integrity check workflow

Current filenames are inconsistent in format (some have CVE numbers, some don't; encoding issues with Chinese characters in filenames may cause cross-platform problems). This introduces friction for scripting, linking, and automation. Enforcing a naming convention and detecting conflicts would improve maintainability and prevent broken references.

• [ ] Create a CONTRIBUTING.md with a strict naming convention: CMS漏洞/[ProductName][Version][VulnerabilityType]_[CVE-or-ID].md
• [ ] Add a linting script (scripts/check-filenames.js) that validates all filenames match the pattern and flags duplicates or encoding issues
• [ ] Integrate the script into a GitHub Action (.github/workflows/lint-filenames.yml) that runs on PR and blocks merges if filenames violate conventions
• [ ] Add a migration guide in docs/MIGRATION.md showing contributors how to rename non-compliant files during their PRs

• Translate top 20 CMS vulnerability markdown files from Chinese to English and create parallel /CMS_Vulnerabilities_EN/ folder to increase accessibility for non-Chinese-reading security researchers
• Create a machine-readable index (e.g., vulnerabilities.json) with fields: product, version, vulnerability_type, cve_id, cvss_score, affected_versions, and exploit_language—enabling automated filtering by severity or type
• Add explicit links and code examples to the Java/Python/Dockerfile exploit implementations referenced in the 2281/214 lines of code; currently markdown files reference exploits but don't link to them directly

This is a public vulnerability knowledge base intended for educational and defensive purposes. The primary security concerns are: (1) Unrestricted public access to detailed exploitation techniques for critical vulnerabilities, (2) Lack of validation and quality control on documented exploits, (3) Missing mitigation and secure coding guidance, (4) Absence of vulnerability lifecycle information (patched vs. active). While the disclaimer exists, the repository requires stronger controls to prevent misuse. The low security score reflects the nature of a public exploit database rather than a traditional application. Recommendations focus on adding validation frameworks, tiered access, and defensive security resources.

• High · Vulnerability Knowledge Base Without Exploit Validation — Repository root - all CMS漏洞/*.md files. This repository is a collection of PoC documentation for 1000+ vulnerabilities without apparent code review, validation, or security testing of the exploits themselves. Many documented exploits could contain malicious code, be outdated, or contain errors that could be exploited. Fix: Implement a peer-review process for all PoCs before inclusion. Add version validation, CVE cross-referencing, and regular updates. Include warnings about testing only in isolated/authorized environments.
• High · Absence of Input Validation Guidelines — CMS漏洞/ directory - all SQL injection and RCE related files. The repository documents numerous injection vulnerabilities (SQL injection, XSS, command execution) across CMS platforms without providing secure coding examples or mitigation patterns for developers. Fix: Create a 'Security Fixes' directory with remediation examples. Add secure coding guidelines for common CMS platforms (parameterized queries, input validation, output encoding).
• Medium · Unrestricted Access to Exploit Documentation — Repository root - README and all vulnerability files. The repository is publicly accessible with detailed PoC documentation for critical vulnerabilities (RCE, arbitrary file upload, authentication bypass) without access controls or authentication requirements. Fix: Add clear usage restrictions and access controls. Implement rate limiting if hosting a searchable interface. Add authentication for detailed exploit steps. Create tiered access levels (summaries vs. full PoCs).
• Medium · Missing Vulnerability Disclosure Timeline Information — CMS漏洞/*.md files - all vulnerability documents. Documentation lacks disclosure timelines, patch availability dates, and vendor response information. Users cannot determine if vulnerabilities are still active threats or already patched. Fix: Add metadata fields for: CVE publication date, patch release date, end-of-life status, affected versions range, and current mitigation status.
• Medium · No Dependency or Supply Chain Security Tracking — Repository structure - CMS entries like WordPress plugins, Drupal modules. The repository references CMS platforms and plugins with known vulnerabilities but provides no mechanism to track dependency chains or identify cascading security risks. Fix: Create a dependency graph for documented systems. Add SBOM (Software Bill of Materials) tracking. Link to security advisories and patch management resources.
• Low · Missing Security Context and Environment Details — CMS漏洞/*.md files. PoC documentation may lack information about required environment setup, prerequisite vulnerabilities, or conditions needed for exploitation, potentially leading to misuse. Fix: Standardize PoC format with sections: Prerequisites, Affected Versions, Environment Requirements, Mitigation, Detection Methods, and References.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.