poc-lab Patch Verification: Confirm Whether Recent High-Severity Vulnerabilities Are Fixed, Including Chrome CSSFontFeatureValuesMap UAF, NGINX Rift, Dirty Frag, and Fragnesia

Fri, 22 May 2026 23:13:24 +0800

poc-lab is a repository of PoCs and reproduction scripts for recently disclosed high-severity vulnerabilities. It focuses on fresh and impactful CVE reproduction material across Linux kernel, Windows, macOS, containers, service components, and browser-related vulnerabilities.

From its positioning, the repository is closer to a security research knowledge base than a one-click toolkit for general users. Each vulnerability directory usually includes PoC scripts, build files, and documentation, helping researchers understand impact, reproduction conditions, and references.

Main project contents

The repository is currently organized by vulnerability identifier or public vulnerability name. The full listed vulnerability names include:

CVE-2026-2441: Chrome CSSFontFeatureValuesMap use-after-free, also listed as Chrome CSSFontFeatureValuesMap UAF.
CVE-2026-27623: Pre-Authentication Denial of Service from malformed RESP request.
CVE-2026-31429: Slab Cross-Cache, a Linux kernel slab cross-cache exploitation direction.
CVE-2026-31431: Copy Fail, a Linux kernel related vulnerability.
CVE-2026-31635: DirtyDecrypt, a system security boundary related vulnerability.
CVE-2026-42945: NGINX Rift, a high-severity NGINX related vulnerability.
CVE-2026-43284: Dirty Frag, a Linux kernel related vulnerability.
CVE-2026-43494: PinTheft, a permission or credential security boundary related vulnerability.
CVE-2026-43500: Dirty Frag, a Linux kernel related vulnerability.
CVE-2026-46300: Fragnesia, a Linux kernel related vulnerability.
CVE-2026-46333: SSH Keysign pwn, an SSH keysign security boundary related vulnerability.

These names show that the project is not limited to one platform. It spans browsers, the Linux kernel, server components, and operating system security boundaries. For people working on vulnerability analysis, patch validation, detection rule writing, and security training labs, this kind of material can be useful reference material.

Directory structure

The project README says each vulnerability directory is intended to follow a consistent structure. Common files include:

exploit.py or exploit.sh: PoC script
README.md: vulnerability information, affected versions, reproduction steps, and references
build or related build files: used to compile or prepare the reproduction environment

The repository structure roughly looks like this:

poc-lab/
├── CVE-2026-XXXXX/
│   ├── exploit
│   ├── build
│   └── README.md
├── VULN-NAME/
│   ├── exploit.sh
│   └── README.md
└── ...

If a vulnerability already has a CVE identifier, the directory usually uses that CVE name. If there is no assigned CVE yet, it may use the public vulnerability name.

Suitable use cases

This type of repository is more suitable for the following purposes:

Security researchers reproducing vulnerability trigger conditions.
Enterprise security teams verifying whether patches are effective.
Detection engineers writing IDS, EDR, WAF, or log detection rules.
Security courses or internal training that build isolated lab environments.
Researchers comparing exploitation prerequisites and defensive ideas across vulnerabilities.

It is not suitable for direct production scanning, and it should not be used against unauthorized systems. The value of a PoC is to help understand risk and verify defenses, not to expand attack surface.

What to pay attention to when using it

First, testing must happen in an isolated environment. Vulnerability reproduction may trigger crashes, privilege changes, file corruption, or service outages. It should not be run directly on office machines, production servers, or third-party systems.

Second, read the README.md inside each vulnerability directory first. Different PoCs have different dependencies, target versions, trigger conditions, and risks. Reading only the root README is not enough.

Third, confirm the authorization boundary. Even if a PoC is public, running it against a system you do not own or have explicit permission to test can create legal and compliance risk.

Fourth, after reproduction, return to the defensive workflow. That includes confirming patched versions, adding detection rules, checking exposed assets, updating asset inventories, and documenting incident response procedures.

Why this kind of repository matters

In recent years, the time between high-severity vulnerability disclosure and public reproduction details has become shorter. For defenders, advisories and CVE descriptions are often not enough. Teams also need to understand trigger conditions, exploitation limits, and detection signals in realistic environments.

The value of repositories such as poc-lab is that they organize scattered high-severity vulnerability reproduction material by directory, helping researchers complete risk validation more quickly. It does not replace official advisories, vendor patches, or security baselines, but it can serve as supporting material for patch verification and detection engineering.

There is also risk. Public PoCs lower the reproduction threshold. If an organization does not have timely patch management and asset inventory capabilities, public reproduction material can widen the exposure window. For enterprise security teams, tracking these projects matters, but building a rapid assessment and remediation process matters even more.

Summary

poc-lab is a collection of PoCs and reproduction scripts for recent high-severity vulnerabilities, covering Linux kernel, browsers, service components, and operating system security issues. It is suitable for security research, patch verification, and detection rule development, but it must be used within authorization, isolation, and responsible disclosure boundaries.

For general readers, the point is not “how to run a PoC.” The more important lesson is that after high-severity vulnerabilities become public, verification and exploitation move faster. Security teams need to complete asset identification, patch assessment, detection updates, and risk closure more quickly.

References:

GitHub project: https://github.com/Unclecheng-li/poc-lab/tree/main
Chinese README: https://github.com/Unclecheng-li/poc-lab/blob/main/README.zh-CN.md