poc-lab organizes 32 high-severity CVE reproductions with root cause, PoC, and fix

What the repository collects

poc-lab, maintained by Unclecheng-li and written largely in C and Python under the MIT license, is a themed collection of proof-of-concept reproductions for high-severity vulnerabilities. The badge count is 32 PoCs, and the coverage list spans Linux kernel privilege escalation, KVM virtualization escapes, web applications and panels, databases, web servers and protocols, browsers, AI infrastructure, and desktop client applications.

Every CVE enters from public disclosure channels: NVD, vendor advisories, and Qihoo 360's QVD among them. The repository's organizing promise is a reproducible chain per vulnerability, stated in three steps at the top of the README: root cause, then PoC, then fix. That last step is what separates a research collection from an exploit dump, and the repository's structure enforces it.

The CopyFail template

Each vulnerability lives in its own directory following what the project calls the CopyFail template, a uniform layout of README.md, exploit/, build/, and env/. The README.md must carry eleven sections: vulnerability overview, affected scope, root cause analysis, exploitation mechanism, PoC analysis, reproduction steps, remediation, detection and investigation, timeline, references, and a disclaimer.

build/ holds compilation artifacts for kernel-class vulnerabilities, and env/ holds a docker-compose.yml reproduction environment for web-class ones. The uniformity is the point. When every entry answers the same eleven questions in the same order, comparing two kernel bugs or triaging a new advisory against an existing entry becomes mechanical. The project also documents its intake process: new disclosures get a directory from the template, an eleven-section README, an exploit with first-hand source links where possible, and a push to main.

Coverage by category

The category table shows where the collection concentrates. The DeepSeek Harness series covers six CVEs in an AI agent framework: configuration loading RCE, read-only sandbox leakage, VM sandbox escape, chained escape RCE, Host header unauthorized RCE, and a macOS local privilege escalation. Web applications contribute three, covering cPanel2Shell, Nezha Monitoring, and wp2shell against WordPress. Databases contribute two: Redis RESTORE RCE and a Valkey RESP denial of service. Web servers add NGINX Rift and HTTP2 Bomb. Browsers contribute a Chrome CSSFontFeatureValuesMap use-after-free and a Firefox IonStack JIT bug. AI infrastructure has a LiteLLM authorization chain escalation, and desktop applications contribute a Notepad++ RCE and PixelSmash, an FFmpeg MagicYUV issue.

The largest single category is the Linux kernel with fourteen entries, which gets its own breakdown.

The Linux kernel series

The kernel collection splits into three groups. The first is a Dirty Cow family of page-cache pollution privilege escalations: CopyFail, Dirty Frag, DirtyCBC, DirtyDecrypt, Fragnesia, and act_pedit. Tracing a single bug class across six variants, each with its own root cause and fix, is the kind of structured study that vulnerability research usually loses in scattered write-ups.

The second group covers standalone LPE and heap exploitation entries: Slab Cross-Cache, PinTheft, GhostLock, CIFSwitch, and SSH Keysign. The third covers KVM virtualization escapes with Januscape and Zapscape, the class of bugs where a guest escapes to the host, the highest-consequence failure mode in multi-tenant infrastructure. Grouping LPE, heap, and escape work separately signals that the maintainer understands these are different research skills with different reproduction requirements.

Reproducing safely

The quick-start block in the README shows the intended workflow, reading before running:

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 order is deliberate: read the reproduction guide first, run the PoC second. For web-class vulnerabilities the env/ directory provides docker-compose environments, so reproduction happens against a disposable target rather than a production system. Kernel reproduction requires compiled artifacts, which the build/ directory provides per entry.

The repository's disclaimer is explicit: it exists for security research and education, running these PoCs against systems you do not own or lack authorization to test is prohibited, the author accepts no liability for misuse, and responsible disclosure norms apply. That framing is consistent with how the entries themselves are written, with remediation and detection sections given equal weight to exploitation mechanics.

Why the fix and detection sections matter

The eleven-section template puts remediation and detection on the same footing as root cause and exploitation. For defenders, those sections are the valuable half. A root cause write-up tells a patch reviewer what the fix must change. A detection section tells a security team what the exploitation attempt looks like in logs, which is the difference between reading about a vulnerability and being able to say whether it was used against you.

The timeline and references sections serve a different audience: researchers tracing disclosure windows and first-hand sources. Since every entry links to NVD, vendor advisories, or QVD records, the repository doubles as a curated index into primary documentation. The Chinese-language analysis with an English README makes the write-ups accessible to both audiences, and the related projects listed, VulnClaw and DeepSec, extend the same research program into AI-assisted auditing and authorized testing platforms.

Where it fits

poc-lab is not a substitute for official advisories, vendor patches, or a feed of automated exploitation. Its value is the middle layer those sources skip: a uniform, readable reproduction chain for each bug, in one place, grouped so that related bugs can be studied as a family.

For security teams, it works as triage training content and as a reference when a new advisory lands in a familiar category. For researchers, the template lowers the cost of adding the next CVE and keeps quality consistent across contributors. The consistent structure, the docker-compose environments, and the explicit authorization boundaries make it a reasonable example of what public vulnerability education looks like when it is done with discipline.

Editorial conclusion

poc-lab applies software engineering discipline to vulnerability education: one directory per CVE, an eleven-section template that gives root cause, exploitation, fix, and detection equal weight, docker-compose environments for web bugs, and grouped series that let readers study bug classes instead of isolated incidents. The 32 entries span kernel, KVM, browsers, and AI infrastructure, and the licensing and authorization rules are stated plainly. For defenders and researchers alike, the fix-and-detection half of each entry is where the lasting value sits.

Frequently asked questions

Official sources

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