poc-lab 补丁验证：确认你的系统中近期高危漏洞是否已修复，覆盖 Chrome CSSFontFeatureValuesMap UAF、NGINX Rift、Dirty Frag、Fragnesia

poc-lab 是一个面向近期高严重性漏洞的 PoC 与复现脚本仓库，重点收集新披露、有影响力的 CVE 复现材料。项目覆盖范围包括 Linux 内核、Windows、macOS、容器、服务组件和浏览器相关漏洞。

从仓库定位看，它更像是一个安全研究资料库，而不是面向普通用户的一键工具合集。每个漏洞目录通常会包含 PoC 脚本、构建文件和说明文档，用来帮助研究人员理解漏洞影响、复现条件和参考资料。

项目主要内容

仓库当前按照漏洞编号或漏洞名称组织目录。已经列出的完整漏洞名称包括：

• CVE-2026-2441：Chrome CSSFontFeatureValuesMap use-after-free，简称 Chrome CSSFontFeatureValuesMap UAF。
• CVE-2026-27623：Pre-Authentication Denial of Service from malformed RESP request，即畸形 RESP 请求导致的预认证拒绝服务漏洞。
• CVE-2026-31429：Slab Cross-Cache，Linux 内核 slab 跨缓存利用方向漏洞。
• CVE-2026-31431：Copy Fail，Linux 内核相关漏洞。
• CVE-2026-31635：DirtyDecrypt，系统安全边界相关漏洞。
• CVE-2026-42945：NGINX Rift，NGINX 相关高危漏洞。
• CVE-2026-43284：Dirty Frag，Linux 内核相关漏洞。
• CVE-2026-43494：PinTheft，权限或凭据安全边界相关漏洞。
• CVE-2026-43500：Dirty Frag，Linux 内核相关漏洞。
• CVE-2026-46300：Fragnesia，Linux 内核相关漏洞。
• CVE-2026-46333：SSH Keysign pwn，SSH keysign 安全边界相关漏洞。

这些名称可以看出，项目关注的不只是单一平台，而是横跨浏览器、Linux 内核、服务端组件和系统安全边界。对做漏洞分析、补丁验证、检测规则编写和安全课程实验的人来说，这类资料有一定参考价值。

目录结构

项目 README 中说明，每个漏洞目录会尽量保持一致结构。常见文件包括：

• exploit.py 或 exploit.sh：PoC 脚本
• README.md：漏洞信息、影响版本、复现步骤和参考资料
• build 或相关构建文件：用于编译或准备复现环境

仓库结构大致如下：

1
2
3
4
5
6
7
8
9

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

如果漏洞已经分配 CVE 编号，目录会优先使用 CVE 命名；如果还没有 CVE，则可能使用公开漏洞名称。

适合哪些场景

这类仓库更适合以下用途：

• 安全研究人员复现漏洞触发条件。
• 企业安全团队验证补丁是否生效。
• 检测工程师编写 IDS、EDR、WAF 或日志检测规则。
• 安全课程或内部培训中构建隔离实验环境。
• 研究人员对比不同漏洞的利用前提和防护思路。

它不适合直接用于生产环境扫描，也不应该用于未授权系统。PoC 的价值在于帮助理解风险和验证防护，而不是扩大攻击面。

使用时需要注意什么

第一，必须在隔离环境中测试。漏洞复现可能触发崩溃、权限变化、文件损坏或服务不可用，不应在办公机、生产服务器或第三方系统上直接运行。

第二，要先阅读每个漏洞目录内的 README.md。不同 PoC 的依赖、目标版本、触发条件和风险不同，只看根目录说明远远不够。

第三，要确认授权边界。即便只是运行公开 PoC，只要目标系统不属于自己或没有明确授权，就可能带来法律和合规风险。

第四，复现完成后应回到防护层面。包括确认补丁版本、补充检测规则、检查暴露面、更新资产清单和沉淀应急流程。

为什么这类仓库值得关注

近年来，高危漏洞从披露到出现公开利用细节的时间越来越短。对防守方来说，只有安全公告和 CVE 描述通常不够，还需要理解漏洞在真实环境中的触发条件、利用限制和检测信号。

poc-lab 这类仓库的意义在于，把分散的高危漏洞复现材料按目录整理起来，让研究者能更快完成风险验证。它不替代官方公告、厂商补丁和安全基线，但可以作为补丁验证和检测工程的补充资料。

不过也要看到风险：公开 PoC 会降低复现门槛。如果组织内部没有及时补丁管理和资产梳理能力，公开复现材料可能会放大暴露窗口。因此，对企业安全团队来说，关注这类项目的同时，更重要的是建立快速评估和修复流程。

小结

poc-lab 是一个近期高危漏洞 PoC 与复现脚本集合，覆盖 Linux 内核、浏览器、服务组件和系统安全相关问题。它适合安全研究、补丁验证和检测规则开发，但必须放在授权、隔离和负责任披露的边界内使用。

对普通读者来说，关注这类项目的重点不是“怎么运行 PoC”，而是理解一个事实：高危漏洞公开后的验证和利用节奏正在加快，安全团队需要更快完成资产识别、补丁评估、检测补充和风险闭环。

参考资料：

• GitHub 项目：https://github.com/Unclecheng-li/poc-lab/tree/main
• 中文 README：https://github.com/Unclecheng-li/poc-lab/blob/main/README.zh-CN.md