2026-11-13 11:15:55 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

38 万个漏洞里，真正挨过打的只有两千个

原创

升斗安全XiuXiu
升斗安全XiuXiu

升斗安全

2026年11月10日 18:14
广东

去阅读

【文章说明】

目的：本文内容仅为网络安全技术研究与教育目的而创作。
红线：严禁将本文知识用于任何未授权的非法活动。使用者必须遵守《网络安全法》等相关法律。
责任：任何对本文技术的滥用所引发的后果自负，与本公众号及作者无关。
免责：内容仅供参考，作者不对其准确性、完整性作任何担保。

阅读即代表您同意以上条款。

一份翻了 27 年 CVE 老账的研究：38 万多条漏洞里，真被人用过的只有两千来个。这篇不复读百分比，聊点实在的：哪类洞值得挖、报告里哪句话决定厂商排不排你、以及为什么同一条 CVE 落在两台机器上会是两个价。

上周有个刚入行的小朋友发我一份报告，语气挺急，说挖到一个 CVSS 9.8，提交两天了厂商没动静。我把链接点开扫了一眼：得管理员先登录，再点一个精心构造的链接，触发一次反射型 XSS。

我没好意思直说「这玩意儿大概率排不上号」，只回了他一句：先去看看这家最近三个月公开致谢的都是些什么洞。

真不怪他。干这行的人，多少都被一个念头坑过“分数越高越危险”、“报告越厚越紧急”。好像守住一台服务器，就等于把那份几千行的扫描结果从头修到尾。做过几年授权测试就会明白，这么干能把人累垮，还拦不住事。

38 万对 2,056

微软 11 月 2 号挂出来一份研究，我觉得刚好能把这层窗户纸捅破。

他们把 1999 年到 2026 年 9 月公开的 CVE 翻了个底朝天，约 38.3 万条；再从中筛出「有证据表明在真实攻击里被用过」的，只有2,056 条。

不到两百分之一。

这个比例我第一次看到也愣了一下。但它不是说剩下那 38 万条都是纸老虎，而是说：漏洞库里绝大多数条目，一辈子都停在公告、扫描器和 Excel 表里。攻击者根本没打算雨露均沾，人家是来拿权限的，不是来刷 CVE 成就的。

顺带把这批数是怎么算的说清楚，不然后面容易读歪。它不是按「缓冲区溢出还是反序列化」这种成因分，而是按打进去之后最坏能拿到什么归一类，一个 CVE 只归一类。比如一个洞能绕登录、接着直接执行代码，那就记成 RCE，不记成认证绕过。平台是另一套标签，Windows、Linux/Unix、移动、网络设备、IoT/OT、虚拟化宿主机、开发包，一个 CVE 可以同时挂好几个。

这里有个挺实在的坑，原报告自己也认了：公告里写「可导致远程代码执行」，不等于实战里真能稳定拿到 shell。我见过不止一次，PoC 跑下去服务直接崩了，重启完事儿，本质上就是个 DoS。所以下面这些百分比，说的是公告上写的类别，不是实验室里一发入魂的成功率。心里有这根弦，才不会把数据用歪。

那两千个，长什么样

先说结论：能直接把系统接管过来的，占了 78%。

给完全没接触过渗透的朋友打个比方，把一台服务器想成一栋楼。

服务端 RCE 嘛，楼下那扇对着大街的门，锁芯有毛病，路人捅一下就开，屋里还没人拦。不用谁配合，不用点链接。认证绕过更好懂，门禁读卡器认了张假工牌，连密码都省了。本地提权呢，是你已经混进院子，可手里只有访客权限；翻进管家房摸到那串总钥匙，整栋楼就随便走了。客户端 RCE 多一道人情关，得先哄屋里那人亲手点开一个文件。好在钓鱼这套活儿这些年太熟，这道关没想象中难过。

这四类放一块儿，就是所谓「接管类」。共同点只有一个：给你一个能站稳、还能往下走的落脚点。

数字也直白。服务端 RCE 在全部 CVE 里占 20%，到被利用那堆里涨到 37%；本地提权 11% 涨到 18%；客户端 RCE 从 4% 涨到 13%；操作系统、内核、驱动这类系统代码，从 23% 涨到 41%。

这里有个特别容易被读岔的地方。客户端 RCE 翻了三倍多，是涨得最猛的那个，但要论绝对数量，坐头把交椅的还是服务端 RCE 的 37%。中文那几篇转述爱写「增长更为显著」，不少人看完就记成「客户端 RCE 最常被利用」，其实差着意思。涨得凶，主要是因为它基数本来就小。

掉队的那些

反过来看掉队的更有意思。XSS 在全部 CVE 里占 15%，被利用的只剩 4%；拒绝服务 16% 掉到 7%。

不是说这两类没价值。挖 SRC 的朋友都清楚，一个能打到管理员会话的 XSS 一样拿高分，关键业务上把服务打瘫也够喝一壶。可站在攻击者那本账上，它们多数时候只给你一次性的效果：隔着门缝塞张纸条，或者把门砸出个响，人还是进不去，也拿不到能接着往下走的东西。

RCE、提权这类拿到的是可持续的立足点。站稳之后，横向、持久化、捞凭据，后面一整套动作才铺得开。攻击者挑洞，本质上挑的是「这一下能不能接出第二下」。

按公开的那几个占比反推一下，78% 大致是这么凑出来的：服务端 RCE 37 + 客户端 RCE 13 + 认证绕过差不多 10 + 本地提权 18。原报告图里还留了个 1,239 的数字，看说明是把三类远程接管单独拎出来按平台再切一遍，1,239 / 2,056 约六成，跟上面那个约 10% 也对得上。中文编译版把这个数删了，78% 看着就像凭空冒出来的。这块是我自己对着图算的，官方没逐项列表，当个口径参考就行。

中文版删掉的那段时间账

我顺手翻回微软原博客，发现中文那版把最要命的一段整个抹掉了【时间】。

防守这边，按微软 2026 年的暴露面数据，一个漏洞从被发现到补上，中位数大概是这样：Windows 工作站两周，Windows Server 一个多月，Linux 服务器和 macOS 上的应用十周往上，网络设备一年以上。

攻击那边呢？VulnCheck 统计 2025 年有 29% 的利用，出现在 CVE 公布当天甚至更早。CISA 把漏洞收进 KEV 名录的平均时滞，2024 年发布的 CVE 是 89 天，2025 年 57 天，2026 年到 9 月已经压到 20 天，中位数只剩 3 天。

换成人话：小偷看到通告到配好钥匙，一两天；物业换锁，两周到一年多，网络设备那栋楼干脆一年多没换过。中间那段空档就是活生生的攻击窗口，而且越是关键的资产，换锁越慢。

顺便提醒一句，别把「KEV 收录日期」当成「第一次被打的日期」。收录快慢反映的是上报和编目流程，攻击者什么时候动手，是另一条时间线。这俩混着用，很容易得出离谱的结论。原报告还提了 AI 辅助找洞、写利用会继续压缩这个窗口，这话我信一半，方向没毛病，但它没给量化数据，当趋势看，别当结论背。

同一个洞，两台机器，两种命

再说个我这些年在授权测试里反复撞见的画面。

两条一模一样的 CVE，一条挂在内网一台谁也不连的测试机上，一条挂在对外提供服务的业务服务器上。第二台跑着个服务账号，权限图省事给得挺宽，还绑了云身份，跟另外七八个系统有可信连接。

扫出来是同一个编号、同一个 9.8。但第一台丢了顶多重装，第二台丢了，等于把那串「万能工牌」一起交出去了——顺着身份和可信连接，能一路刷到别的核心系统。

微软管这个叫爆炸半径，算法其实就一句话：影响 × 暴露。影响是打进去能拿到什么，暴露是这台机器站在什么位置、手里攥着哪些身份和连接。攻击者不是随机挑洞的，人家先找够得着的门，再看门后头连着什么。

所以「哪个 CVE 更严重」这个问题，本身就问错了。得先问：它长在哪台机器上，那台机器手里有什么。

挖洞的，可以反着读

这份数据到了赏金猎人手里，其实该倒过来看。

先说选目标。别把一整周耗在纯反射型 XSS 上，除非你有把握把它串成会话接管。同样的时间，花在认证逻辑、服务端解析、权限边界上，命中率和单价通常都更好看。这两千个挨过打的洞，已经把厂商真正在意的东西投票投出来了。当然，都在授权范围内聊。

再说报告怎么写。别只贴一个 CVSS 分数，把「拿下来之后能干什么」补完整：能不能读到本地凭据、能不能借服务账号横向、能不能碰到别的用户数据、能不能触到管理面。厂商排修复队列用的就是影响 × 暴露这套逻辑，你替他把这段写好了，报告自然往前挪。我见过太多技术含量足够的提交，卡在只写了一句「可导致 RCE」。

最后一条，别拿 9.8 当谈判筹码。有真实利用证据、进了 KEV 的洞，和一个纸面 9.8 但谁也复现不出来的洞，根本不在同一个队列里。想明白这点，能省掉很多没必要的争执。

防守侧，四步够了

也不用整那么复杂。先把面向互联网的资产盘清楚，包括影子资产和第三方依赖那堆没人认领的东西；在这上面按接管类先排，服务端 RCE、认证绕过、提权优先；XSS 和 DoS 往后放，除非那台机器停机一分钟就是事故；最后，对网络设备这类一年都换不上锁的，别死等补丁，收暴露面、砍服务账号的多余权限、把通往关键资产的路径先掐断，比排队等固件实在。

还有一类容易被漏掉：可用性要命的系统上的 DoS，以及凭据泄露。单看都不吓人，但前者在特定场景下是直接把业务干停，后者正好喂给前面说的那条特权身份链路。

漏洞库每年都在涨，涨的主要是纸面上的数。真要盯的，是那两千把已经被撬开过的锁，和你自己机房里那台还挂着万能工牌、一年没换过锁的服务器。

写这类稿子最费劲的从来不是找数据，是把一堆百分比翻回人话。要是读着还算顺，点个赞、点个推荐（在看），让更多挖洞的朋友刷到。

还没关注的顺手关注一下，后面接着聊「报告怎么写才拿得到分」那点细节，都是这些年踩坑攒下来的。

觉得哪段对刚入行的朋友有用，转给他就行，比在群里喊十遍「别只盯 CVSS」管用。