poc-lab: one directory per CVE, and a template whose slots depend on the category

Thirty-two entries across eight folders, and the kernel folder holds fourteen

The index gives a count per category, and adding them up describes the shape of the collection. DeepSeek Harness holds 6, Linux Kernel 14, Web Applications 3, Databases 2, Web Servers and Protocols 2, Browsers 2, AI Infrastructure 1, and Desktop and Client Apps 2, for 32 indexed entries. The Linux kernel folder is therefore close to half the repository on its own, which tells you where the maintainer's attention has been. The second-largest theme is not a product area but a deployment context: the DeepSeek Harness series plus the single LiteLLM entry make 7 of the 32, so roughly a fifth of everything here targets AI infrastructure rather than traditional server software. Every entry originates from a security advisory or a public disclosure, with NVD, vendor advisories and the Qi An Xin QVD named as sources, so the collection is downstream work rather than original research.

The quick start quotes every directory name because the categories contain spaces

The five-line quick start is a good map of how the repository is laid out.

git clone https://github.com/Unclecheng-li/poc-lab.git && cd poc-lab
cd "Linux Kernel"                 # 选一个分类
cat "CVE-2026-31431 Copy Fail"/README.md   # 先读复现指南
python3 "CVE-2026-31431 Copy Fail"/exploit/exp.py   # 再跑 PoC

The category directories are named with spaces and an ampersand, and each CVE directory carries both a number and a display name, so every path argument is quoted. The order the commands run in is the intended workflow: read the reproduction guide first, then run the exploit script. Note the sample entry. CopyFail is one of the page-cache pollution privilege escalations, and it is the same flaw the kernel folder uses as its naming template. There is also a separate English file, `README_EN.md`, tracked alongside `README.md` rather than generated from it, so the two translations are free to drift apart.

build/ and env/ are category-conditional, so the tree is not uniform

The stated layout promises consistency: one directory per CVE following a common template. The table underneath it qualifies that promise. `README.md` is universal and carries eleven sections, namely vulnerability overview, affected scope, root cause analysis, exploitation mechanism, PoC analysis, reproduction steps, fix, detection and troubleshooting, timeline, references, and a disclaimer. `exploit/` is universal too, but its contents vary by file type: `exp.py`, `exp.c`, `exp.html`, `lpe.sh`. `build/` is for compiled artifacts from kernel vulnerabilities, and `env/` holds a `docker-compose.yml` reproduction environment for web vulnerabilities. Neither is present for every entry. The practical consequence is that entries outside those two categories carry neither, so any automation that walks the tree looking for a uniform shape will find gaps. The quick start runs a Python script, which describes only one of those four PoC shapes.

Kernel entries are grouped by exploit family rather than by CVE number

Inside the Linux kernel folder the grouping is by technique, which is the most reusable view the repository offers. One branch holds the Dirty Cow family of page-cache pollution privilege escalations: CopyFail, Dirty Frag, DirtyCBC, DirtyDecrypt, Fragnesia, and act_pedit. A second branch holds independent local privilege escalations built on heap exploitation: Slab Cross-Cache, PinTheft, GhostLock, CIFSwitch, and SSH Keysign. A third is KVM virtualisation escape, with Januscape and Zapscape. Sorting by family rather than by identifier means the individual CVEs are secondary to the pattern, which is the right choice for audit work and the wrong one if you are looking up a specific advisory number. It also means the CopyFail template name refers to one member of a family rather than to a general convention, even though the repository uses it as the template for every directory regardless of category.

The AI infrastructure slice is the second-largest theme and the newest-looking

The DeepSeek Harness series covers six separate weaknesses in one agent framework, and reading them as a list shows what kind of bugs the maintainer considers high severity in agent tooling: configuration loading remote-code execution, a read-only sandbox leak, a virtual-machine sandbox escape, a chained escape leading to remote-code execution, and a Host header remote-code execution that skips authorization. The sixth is a macOS local privilege escalation, which is the odd one out in a list otherwise about the framework's own boundaries. Separately, the single AI Infrastructure entry is a LiteLLM authorization chain that yields privilege escalation. Taken together these seven entries are about trust boundaries in systems that execute model-generated or agent-generated code, where the interesting failures are in the sandbox and the configuration layer rather than in the model.

Adding a CVE means pushing to main, and there is nothing in the tree that checks you

The intake process is three manual steps: create a directory named for the CVE and its title following the template, write the eleven-section README plus an exploit script with first-hand source links where possible, then push to the remote main branch. Two observations follow from the repository layout. The top level contains only `.gitignore`, the `LICENSE`, `README.md`, `README_EN.md` and the eight category folders. There is no `.github/` directory, so no issue templates, no pull-request checks and no build workflow, and there is no `SECURITY.md` or `CONTRIBUTING.md`. There are also no GitHub releases and no tags. In practice this is a single-maintainer curation repository rather than a community contribution target, which is consistent with the disclaimer placing responsibility on the reader.

The non-kernel entries span panels, key-value stores, servers, browsers and desktops

The remaining categories are small but deliberately varied. Web Applications holds three: cPanel2Shell, the Nezha Monitoring panel, and wp2shell for WordPress. Databases holds two, Redis RESTORE remote-code execution and a Valkey RESP denial of service. Web Servers and Protocols holds NGINX Rift and HTTP2 Bomb. Browsers holds a Chrome use-after-free in CSSFontFeatureValuesMap and a Firefox IonStack JIT bug. Desktop and Client Apps holds a Notepad++ remote-code execution and PixelSmash, an FFmpeg MagicYUV bug. The spread across programming languages and privilege boundaries is the point: a browser JIT use-after-free and a Redis deserialization bug have nothing in common except severity, and putting them in one place is what makes the collection usable for someone triaging across a stack. The repository also links two sibling projects, VulnClaw as an AI-driven penetration testing framework and DeepSec as an audit and authorised-testing platform.

Editorial conclusion

poc-lab fits someone doing triage, code audit or follow-on research who wants the reproduction environment and the root cause in the same place as the exploit script. Four things to check before you rely on it. The optional directories are conditional, so a browser or database entry will have no build artifacts and a web panel entry may have no Docker environment; do not assume a uniform tree. The PoC languages differ, so the Python quick-start path does not describe a C kernel exploit and its compile step. Coverage is uneven by design, with the Linux kernel folder alone holding nearly half the entries, so absence of a CVE from this collection says nothing about whether it exists. And the whole repository is a single-maintainer push workflow with no releases, no tags and no automated checks, so pin the commit you audited rather than tracking the branch.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Unclecheng-li/poc-lab on GitHub