文章总结： 本文是一篇CVE申请实战指南，作者分享从资产选择、复现文档撰写到提交渠道的完整流程。核心要点包括：CVE编号由CNA联盟分配而非MITRE直接受理，应优先选择有明确CNA归属的产品；复现文档需结构化且PoC最小化；提交渠道有VulDB、GitHubSecurityAdvisories和厂商CNA三种；提交后需耐心跟进。文章提供具体操作步骤和避坑建议，可操作性强，并附有免责声明。
综合评分： 82
文章分类： 漏洞分析,实战经验,漏洞预警
手把手教你拿到人生第一个CVE编号：从找资产到提交，避坑全指南
原创
klsec.com
klsec.com
昆仑AI安全实验室
2026年9月20日 00:20
广东
在小说阅读器读本章
去阅读
在公众号小说中沉浸阅读
去年这个时候，我拿到了人生第一个CVE编号。从发现漏洞到编号公开，前后花了不到三周。但在这之前，我走了整整两个月的弯路——提交被拒、资产不属于CNA范围、复现文档没人看得懂。
今天我把整个流程从头到尾拆一遍。不是那种“去MITRE官网填表”的泛泛之谈，是每一步都有具体操作、具体工具、具体坑的实战指南。
读完你会知道：什么时候该找VulDB，什么时候该用GitHub Security Advisories，什么时候该直接发邮件给厂商，以及为什么你辛辛苦苦挖的洞可能根本拿不到CVE。
一、先搞清楚：CVE到底是什么，以及“谁说了算”
CVE全称Common Vulnerabilities and Exposures，是公开披露的网络安全漏洞列表。每个漏洞按CVE-2024-XXXXX的格式编号，这个编号是识别漏洞的唯一标识符。
但“谁有权分配CVE编号”这件事，很多人搞错了。MITRE确实是CVE项目的管理者，但它不是唯一的受理入口。CVE项目建立了一个叫CNA（CVE Numbering Authority）的联盟体系——遍布全球的软件厂商、安全公司和研究机构，被授权在各自范围内分配CVE编号。
目前CNA涵盖五类成员：MITRE本身（兜底）、软件/设备厂商（如Apple、Google，占80%以上）、研究机构（如Airbus）、漏洞奖金项目（如HackerOne），以及国家级/行业级CERT（如CNNVD）。
这对你意味着什么？ 意味着你发现一个漏洞后，第一步不是去MITRE官网填表，而是找到负责这个产品的CNA。找对了CNA，审核速度可能是一两周；直接扔给MITRE，等几个月是常事。
二、第一步：找什么资产，去哪里找
不是所有漏洞都能拿CVE。CVE的定位是“通用漏洞”——影响广泛使用的软件、系统、协议。小公司自己开发的内部系统、个人项目，CNA一般不收。
最稳妥的切入点：开源CMS和通用型软件。
去GitHub搜cms，筛选语言，下载源码。目标软件要有一定的用户基数（Star数、下载量、被引用次数），这样CNA才认可它的“通用性”。
另一个渠道是国内的源码下载站，比如站长之家、源码之家、JEECG等。下载后做代码审计或黑盒测试，找到漏洞后确认该软件是否已有CNA覆盖。
优先选择有明确CNA归属的产品。 比如WordPress有专门的CNA，Apache项目有Apache CNA，Red Hat有Red Hat CNA。这些产品的漏洞提交流程最规范，审核最快。
三、第二步：写一份“CNA能看懂”的复现文档
CNA审核员每天要看几十份报告。如果你的复现文档写得像草稿，他根本没有耐心去理解你发现了什么。一份合格的复现文档要包含以下要素，我建议直接按这个结构在GitHub上建仓库：
仓库结构参考：
CVE-XXXX-XXXXX/├── README.md # 漏洞概述：产生原因、漏洞位置、危害、影响版本、相关链接├── docker-compose.yml # 一键搭建漏洞环境（或源码下载指引）├── poc.py # 最小化PoC，只证明漏洞存在，不扩大利用├── report.md # 漏洞复现报告：环境搭建步骤、PoC运行方式、预期结果、截图└── nuclei/ └── CVE-XXXX-XXXXX.yaml # Nuclei检测模板（可选，但能加分）
这个结构来自一个开源POC仓库的实践，它的设计逻辑很清晰：让任何人在任何环境下，都能按照你的文档复现出同样的结果。README写清楚漏洞是什么，docker-compose让环境搭建自动化，poc.py是证据，report.md是完整的叙事，nuclei模板是给后续检测用的。
关键细节：
PoC要“最小化”。 只证明漏洞存在即可。如果是SQL注入，只读一行数据，不要dump整个表。如果是RCE，只执行whoami，不要反弹Shell。CNA审核的是“漏洞是否真实存在”，不是“你能造成多大破坏”。
截图是必需品。 环境搭建的截图、PoC运行的截图、结果输出的截图。CNA审核员不一定有精力自己搭建环境跑一遍，截图是说服他的最快方式。
四、第三步：选对提交渠道——VulDB vs GitHub Security Advisories
这是最关键的一步。选错了渠道，你的漏洞会被转来转去，最后石沉大海。
渠道一：VulDB（适合通用型漏洞，审核快）
VulDB是一个活跃的CNA成员，也是国内研究者拿CVE编号最常用的渠道。它的覆盖范围是“所有未包含在其他CNA范围内的开源和闭源软件”。
操作流程：
注册VulDB账号 → 访问https://vuldb.com/?id.add → 填写漏洞信息。Vendor写产品厂商名，Product写产品名，其他字段按实际情况填。
VulDB的“坑”：
VulDB对漏洞的“通用性”要求比较高。小公司的内部系统、没有明确版本号的软件、危害级别不够的漏洞（比如需要用户交互才能触发的XSS），VulDB通常不收。被拒时它会建议你提交到CVE官方平台，但那边的审核周期更长。
VulDB的优势：
审核速度快，一般1-2周就能出结果。如果你发现的是SQL注入、文件上传、RCE这类通用型高危漏洞，VulDB是首选。
渠道二：GitHub Security Advisories（适合开源项目，首选）
如果你发现的漏洞在GitHub上的开源项目里，走GitHub Security Advisories是最顺的路径。这是GitHub官方提供的私密漏洞报告通道，内置了CVE请求机制。
操作流程：
进入目标仓库的Security标签页 → 点击“Report a vulnerability” → 填写Advisory表单。
表单内容包括：Summary（一句话描述）、Description（详细技术说明）、Affected versions（受影响版本范围）、Severity（CVSS评分）、Proof of Concept（PoC）。
优势： 私密通道，公开前只有你和维护者能看到；内置CVE请求机制，维护者可以在Advisory界面直接请求CVE编号；时间线追踪是内置的，你随时能看到进展。
实测数据： OpenWrt社区在oss-security邮件列表里反馈过，用GitHub Security Advisories“几天内就拿到了CVE编号”。
渠道三：直接找厂商CNA（适合大厂产品）
如果你发现的漏洞影响的是Microsoft、Google、Apache、Red Hat这些有自己CNA的大厂产品，直接找他们的安全响应中心是最快的。
每个大厂都有安全报告页面。微软是MSRC，Google是Bug Hunters，Apache是[email protected]。找到对应页面，按格式提交。他们有自己的CNA权限，可以直接分配CVE编号，不需要经过MITRE二次审核。
五、第四步：提交之后——时间线和跟进
提交只是开始。以下是提交后的标准时间线（以GitHub Security Advisories为例）：
Day 0： 提交Advisory。你会收到自动确认邮件。
Day 1-3： 维护者确认收到报告，可能要求补充信息。保持邮件畅通，及时回复。
Day 7： 如果没有任何回复，发一封礼貌的跟进邮件。不要催促，只是确认“报告是否已到达正确的团队”。
Day 14： 第二次跟进。如果仍然没有回复，尝试通过其他渠道联系（比如项目的公开邮件列表、维护者的社交媒体）。
Day 30： 如果厂商完全无响应，可以考虑升级到CERT/CC或国家级CSIRT。
Day 45-90： 最后的窗口期。如果厂商在90天内既未修复也未回应，可以按照负责任披露的原则，考虑公开漏洞（部分平台和CNA对此有明确规定）。
六、几个让你少走弯路的实操建议
第一，先查重。 在动手挖之前，先去VulDB、NVD、GitHub Security Advisories搜一下目标软件是否已经有CVE。重复提交会被直接拒绝，浪费你的时间。
第二，CVSS评分要合理。 不要为了显得“严重”就给9.8。CNA会复核你的评分，虚高的评分会让审核员对你的专业性产生怀疑。参考同类漏洞的评分，给出有依据的数值。
第三，复现文档用英文写。 即使你提交的是国内CNA，英文文档的通用性更好。GitHub Security Advisories的审核者可能是全球各地的维护者。README可以用中英双语，但核心内容用英文。
第四，别把“拿到CVE”当成终点。 CVE编号公开后，写一篇技术分析文章，发到安全社区。这不仅能让更多人知道你的发现，也是你个人品牌的一部分。CVE编号是你的“学术引用”，技术文章是你的“课堂讲解”。
第五，保持耐心。 从提交到CVE公开，整个流程走完可能需要1-3个月。这不是你的问题，是CNA的工作流程决定的。利用这段时间继续挖下一个目标，不要盯着邮箱等回复。
写在最后
拿CVE编号这件事，技术能力只占一半，另一半是流程能力——知道找谁、怎么写、什么时候跟进。
我见过太多人，技术很强，挖到了真漏洞，但因为提交渠道选错了、复现文档写得太糙、跟进方式不对，最后什么都没拿到。
这篇文章里的每一步，都是我用被拒的邮件和浪费的时间换来的。希望你不用再走一遍。
严正声明
本文所述CVE申请流程和渠道信息基于CVE官方文档、VulDB公开资料及GitHub Security Advisories文档。所有漏洞挖掘和提交操作必须在获得明确授权的目标范围内进行，遵循负责任披露原则。未经授权对他人系统进行安全测试属于违法行为。CVE申请的具体流程和要求可能随CVE项目政策更新而变化，请以CVE.org和各CNA官方页面为准。
免责声明：
本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。
任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。
本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。
本文转载自：昆仑AI安全实验室 klsec.com
klsec.com《手把手教你拿到人生第一个CVE编号：从找资产到提交，避坑全指南》