持续记录并汇总自1999年以来每个月新增通用漏洞披露（CVE）数量的通用漏洞披露追踪器（CVE Tracker）页面显示，当前CVE总数已达394,368个，本月新增12,688个；按月推算约17,350个，按年推算约103,854个。数据更新于2026-10-22，并默认以最近90天的每日视图呈现这些数量的变化。
正文
CVE 总数为 394,368；当月数量为 12,688；月度预测约 17,350；年度预测约 103,854；数据更新于 2026-10-22。
最近 90 天，按日显示。
评论
多数人对 CVE 数量暴涨普遍持怀疑态度，认为数字受制度激励、统计口径和低质量报告扭曲，图表读数并不靠谱；少数人则指出即便只看严重级别 CVE，趋势也比全部 CVE 更夸张，且 AI 正在翻出几十年人类代码里的漏洞，认为增长至少部分反映真实风险，而另有少数声音进一步认为整个 CVE/CVSS 体系已经过时、受美国政治与资金拖累。讨论现场还夹杂对站点卡死、大语言模型垃圾项目和“CVE 登月却无人受益”的冷嘲，分歧主轴在于这究竟是指标灌水还是真实安全欠债暴露。
认为 CVE 数量暴涨是指标灌水与制度扭曲的结果，不代表真实风险
- Linux 内核等项目会对几乎任何 bugfix 都发 CVE，员工也会故意报 CVE 来倒逼被拒绝的升级；DNS 服务器维护者抱怨大量所谓高危 CVE 只是“发几百个包让服务卡一分钟”的洪水攻击，连补丁都不值得写；指数曲线的拐点也和 AI 出现的时间对不上，更像 CVE 数量本身被当成指标刷了出来（认可度：较多人） > 很多所谓高危 CVE 只是“发几百个包让服务卡一分钟”的洪水攻击，根本不值得重写代码修复（@strenholme）
认为这波增长部分反映真实风险，AI 正在翻出历史代码里的旧漏洞
- 原本人们以为 AI 会带来新漏洞，实际情况却是 AI 在把几十年人类代码里的老漏洞挖出来；有人查了带严重级别过滤的数据，发现严重级别 CVE 的增长约为 2020 年的 25 倍，比全部 CVE 的约 5 倍还夸张，说明过滤掉低危后趋势仍未消失。还有人追问长期趋势，怀疑这只是在消耗低垂果实、未来可能回落；在 DOGE 削减网络安全机构、MITRE 经费告急的背景下，发放量仍在飙升也被视为不能全归咎于灌水的迹象（认可度：少数人） > 原本以为 AI 会带来安全漏洞，结果它是在发现几十年人类代码里的漏洞（@xnx）
认为项目本身质量低劣，图表与数据都不可信
- 有人查看源码后认为这是典型的大语言模型垃圾项目：所有代码堆在一个文件里，充满啰嗦的 Claude 风格注释；实际使用中切换到对数刻度没有反应并会把站点卡死，站点显示的 2026 年 CVE 数量约 12,000，也与源码里 79,764 份 CVE 数据文件对不上，有人仅今年为 RHEL 打的补丁就远超这个数（认可度：较多人） > 看源码就知道又是大语言模型垃圾项目，所有代码堆在一个文件里，满是非常啰嗦的 Claude 风格注释（@mschuster91）
认为 CVE/CVSS 体系已过时且受美国政治与资金拖累，需要全球新机制
- 评论指出 CVE、CVSS、CPE 像委员会设计出来的过时产物，负责任披露假设的是前 AI 时代几个月才出一个漏洞的慢节奏，如今已不反映现实；NIST 已不再真正分析 CVE，MITRE 经费在 2025 年一度到期，美国政治变动会直接威胁全球漏洞库，因此需要更稳健的全球体系，EU CRA 的 SBOM 与强制报告被视为较好起点。也有人提到 DOGE 削减网络安全机构、MITRE 警告项目可能恶化的例子，说明依赖美国资金已让项目积压和前景不明（认可度：少数人） > CVE/CVSS/CPE 像委员会设计出来的过时系统，美国资金和政治一变动就威胁全球漏洞库，应改由更稳健的全球体系接手（@aforwardslash）
反对以监管名义限制前沿模型做网络安全工作，认为这会自废武功
- 有人反讽说，若按某些思路去监管和限制前沿模型从事网络安全工作，只会让防御方失去工具、而攻击者不受影响；他批评西方政策制定者和 AI 公司领导人是在借监管俘获自利，把大家推向无防御状态（认可度：少数人） > 限制前沿模型做网络安全工作只会让好人面对坏行为者时毫无防御，这完全是借监管自肥（@bvcp）
调侃 CVE 数量已“登月”却无人受益，是典型 2026 式荒诞
- 有人吐槽 CVE 像登月计划一样暴涨，但无论维护者还是发现者都没因此拿到钱，用“很 2026”概括这种荒诞感；这类冷嘲也代表了不少人对数量游戏疲劳的情绪（认可度：少数人） > CVE 数量已经登月了，却没有人因此拿到报酬，真是非常 2026（@keyle）
有价值的补充
- 关于内核 CVE 数量为何虚高：Linux 内核由于处在系统底层，几乎任何 bug 都可能被用来破坏内核安全，而漏洞是否真能被利用在修复时往往不明显，因此 CVE 分配团队会过度谨慎，给识别出的几乎任何 bugfix 都发 CVE；这被用来解释“CVE 数量本身被制度放大”的机制（据 @braiamp 的说明）。