同样的洞，有人拿高危有人拿中危：漏洞定级到底在争什么

原创

Sink
Sink

船山信安

2026年9月25日 18:02
湖南

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

漏洞挖掘 · VULNHUNT

同样的洞，有人拿高危有人拿中危：漏洞定级到底在争什么

SRC 与评级 · 写给觉得评审不公的白帽子

两份提交躺在同一个工单池里。同一个注入点，同一条 payload，一个判高危，一个判中危。评审没有掷骰子。他们看到的根本不是同一个东西：一个交的是\"这里有个注入\"，另一个交的是\"这个注入能读到什么、谁读得到\"。这篇要拆的就是这个差别，以及被判低之后，申诉到底该怎么写。

01CVSS 打的是漏洞，不是\"你这一个洞\"

CVSS 从来没打算衡量一个洞有多值钱。

CVSS v3.1 是 FIRST 在 2019 年发布的通用漏洞评分系统。它的基础分只回答一件事：这个漏洞在技术上多容易被利用，利用完能造成多大破坏。攻击向量、攻击复杂度、所需权限、要不要用户交互、对机密性完整性可用性的影响。就这五项。

里面没有环境。

规范确实留了环境分和时间分，那是给使用方自己填的。问题是绝大多数提交表单里没有这一栏。你填不了，评审也看不到。于是同一条 SQL 注入，躺在测试环境的报表库里，和躺在核心支付库里，算出来是同一个分数。

这不是评审坏了，这是工具的分工。尺子量的是长度，不是重量。

真正扎心的地方在后面：白帽子提交的绝大多数注入，确实是前者。

原因很朴素 —— 核心库你碰不到。前面有网络隔离，有访问控制，有盯着慢查询和异常返回的审计。你能碰到的、能稳定复现的，通常是边缘系统、测试环境、忘了下线的老活动页。这些地方确实有洞，也确实不值高危。

分歧就是这么来的。你觉得\"我明明拿到了数据库\"，评审看到的是\"这是个 2019 年上线的活动页，库里三千条测试数据，且只对内网开放\"。

两个判断都成立。他们说的不是同一个洞。

还有个更实际的问题：环境分为什么从来没人填。

要填环境分，你得知道这个资产的保密性需求有多高、可用性中断一小时损失多少、它承载的是不是关键业务流程。这些信息只有厂商手里有。白帽子一份都没有。

所以定级这件事，天然是个需要两边共同填完的动作。而提交表单只有一边在填。

这也解释了最常见的一种委屈：你确实没被针对。对方手上那半张表，你根本看不见。

所以定级争议的本质不是\"分数算错了\"。是你在拿技术严重性的材料，去要业务危害的评级。

02决定级别的三样东西，有一件常被搞反

评审脑子里其实在过三个问题。跟 CVSS 有关系，但不完全是一回事。

可达性：谁能碰得到。不需要任何身份就能触发，还是要先登录？登录的是普通用户还是管理员？在公网还是必须先进内网？要不要受害者点一下链接？

影响面：碰到了能拿走什么。多少条数据、多少个用户、涉不涉及资金和身份信息、能不能被批量化。

修复成本：改起来有多疼。这一件最容易被搞反，下面单说。

先讲可达性为什么能盖过分数。

两个 XSS。一个是存储型，需要已登录的普通用户发帖才能触发，但能打到后台管理员。另一个是反射型，无需登录，但要诱导受害者点一条精心构造的 URL。

按 CVSS v3.1 的基础分算，后者反而可能更高，因为它不需要任何权限。前者要带着\"需要低权限\"这一项往下压。

但真实评审里，前者经常判得更重。因为它通向管理员会话，后者要骗人点链接。

分数没变，判断变了。变的是\"谁能碰得到\"和\"碰到之后是什么\"，不是公式。

接下来是常被搞反的那件。

一个洞改一行网关配置就能堵上，另一个要动数据层、要回归测试、要申请停机窗口。运维当然先修前者。

但\"先修\"不等于\"更严重\"。

修复成本影响的是排期优先级，不影响严重性。这两句话经常被搅在一起，于是出现一段经典对话：白帽子说\"这个洞你们三天就修好了，说明它不难，凭什么判低危\"；评审说\"我们修得快不代表它危害大\"。

两边都没说错。他们在用同一个词说两件事。

吵之前先分清楚：你现在争的是\"它有多坏\"，还是\"它该不该先改\"。这是两个不同的申诉。

影响面里还藏着一个经常被漏掉的量：能不能批量。

同一个越权，一次只能改一个用户的一条字段，和一个脚本跑一晚上能遍历十万条，危害差三个数量级。但提交里往往只有一句\"可修改用户信息\"，没写能不能循环调用、有没有频率限制。

这一句不写，评审只能按最保守的那种估。

反过来，写清楚\"做不到什么\"也是加分的。你注明\"该接口有单账号日限额，无法批量遍历\"，评审知道你在边界内测过，你后面写的那句\"可读取全量\"反而更可信。

03三个失分点，我全踩过

危害描述跑在 PoC 前面。

你提交\"存储型 XSS 可窃取管理员 Cookie\"。截图是 alert(1) 弹窗。管理员路由你没验证过存不存在，后台跟前台是不是同域你没确认，Cookie 有没有 HttpOnly 你没看，有没有 CSP 你没提。结果定中危。

评审不是不信 XSS 能打 Cookie。他是不信你在这个系统上能打到。

弹窗只证明\"输入没被过滤\"。从\"没被过滤\"到\"管理员会话被劫持\"，中间还隔着四步：后台页面在哪、管理员会不会打开它、Cookie 是不是 HttpOnly、有没有 CSP 拦外带。你一步都没走。

那就只能按\"可能有数据\"降级。这在流程上完全说得通。

危害描述要和 PoC 停在同一格。走到哪写到哪。多走一步，级别往上抬一格；多写两步没走的路，整条都会被怀疑。

第二个失分点是打码。很多人把这件事做反了。

手机号打码，姓名打码，订单号打码，URL 打码，连返回的字段名都打码。剩一个黑框，配一句\"可读取大量用户敏感信息\"。

评审看到的就是：一个黑框。

他不能因为你写了\"大量\"就给高分，就像他不能因为厂商说\"影响很小\"就给低分。两边都是没证据的话。

正确做法是保留结构、抹掉值。字段名留着，返回条数留着，分页参数留着，数据内容换成等长占位。让评审能数出来这是哪张表、多少条、属于哪个业务。

数据条数比数据内容更能定级。这句话反直觉，但它是真的。

打码还有一个反方向的错：真名真号直接贴进提交单。打码过头顶多被降级，不打码可能直接把你自己送进麻烦里。提交单不是匿名的地方，别拿真实用户的个人信息去证明一个中危。

稳妥的做法是只在前几条里保留可核对的结构，剩下的用条数和字段列表代替。评审要的是规模，不是样本。

第三个失分点：把组合链拆成单个漏洞提交。

你有三个发现：一个低危的信息泄露，一个中危的越权，一个低危的配置不当。分开交，三个都是低危中危，加起来还是低危中危。

合起来是一条能改任意用户绑定手机号的路径。

拆开交是亏的。评审看每一条时，只按这一条本身判，他不知道这条的终点在哪。

前提是你真的把链走完了。

\"理论上可以进一步利用\"不算走完。\"我用 A 处拿到的 token，在 B 接口换出了 C 的手机号，收到验证码，改绑成功\"才算走完。

写的时候当成一条攻击路径叙事，不是三个漏洞的列表。第一跳、第二跳、第三跳，每跳的凭证从哪来，下一跳凭什么成立。

走不完就别硬凑。半条链硬说成一整条，评审一问就断，比老实交三个低危还难看。

还有个小坑：链里如果有一环是别人早就交过的重复漏洞，整条的价值会打折。你以为你在讲一条新路径，评审看到的是\"这条的第三步三个月前就有人交了，还没修\"。动手前先搜一遍，能省掉一次尴尬。

04危害描述改写：同一个洞，两种定级

下面这两段写的是同一个存储型 XSS。洞没变，材料变了。

【反例】

危害：存储型 XSS，可窃取管理员 Cookie，进而控制后台。

证明：弹窗截图一张。

评审看到的：输入未过滤，后续四步均未验证。

【正例】

危害：评论框可写入 HTML，内容在后台工单详情页渲染。

后台与前台同域，管理员每日处理工单必打开该页。

Cookie 未设置 HttpOnly，页面无 CSP，已验证可外带。

证明：四张截图，含写入、管理员视角渲染、

Cookie 属性、外带接收记录。

评审看到的：从入口到管理员会话，每一步都成立。

差别不在文采。正例里每一句都能被追问\"你怎么知道的\"，而且每一句都答得上来。

我给自己定了个规矩：写完危害描述，逐句问一句\"评审看到这句会追问什么\"。追问得出来的，我先把答案补上，再提交。

补不上就删掉那句。删掉比被问倒强。

危害描述不是给漏洞加戏，是给评审补上他没法自己去查的那部分信息。

05申诉不是\"我觉得应该高危\"

我年轻时申诉过两次，两次都没赢。回头看，人家判得对。

第一次我写的是\"这个漏洞明明可以导致服务器被控制，为什么是中危\"。评审回了一句\"请补充可证明的完整利用过程\"。我当时挺生气，觉得他在敷衍。

现在我知道那句话是标准回复。它真正的意思是：你没给我能改变判断的东西。

申诉要赢，得补三样东西。

一、新的利用条件。评审原来认为\"需要管理员登录\"，你证明普通用户就行。这是直接掀掉评级前提的那一种，杀伤力最大，也最难拿。

二、更完整的 PoC。不是再贴一张弹窗截图。是从入口到终点每一步都跑通，每一步的输出都在，换个人照着做也能复现。

三、受影响的资产清单与业务含义。哪几个域名、哪几个接口、对应什么业务、覆盖多少用户。

第三样最常被忽略，也最有杀伤力。

\"这个越权可以改任意用户的绑定手机\"，这是中危。

\"这个越权影响改绑接口，该接口承载全站改绑流程，改绑后可重置支付密码\"，这是另一回事。

洞没变。你递给评审的信息变了。

还有个次序问题：一次申诉只解决一个判定项。你觉得可达性判错了，就只补可达性，别顺带把影响面和修复排期一起抱怨了。三件事一起抛，评审只会挑最好答的那件回你。

格式上我后来固定成四段，因为评审读一份申诉通常只有几分钟。

第一段一句话说结论，第二段写新增的利用条件，第三段贴完整 PoC 和每一步输出，第四段给资产清单和业务含义。他看完第一段就知道这次要不要改判，看完后两段才知道改到哪儿。

把结论埋在结尾一段，等于赌他有耐心读完。

06申诉的语气跟材料一样重要

申诉里最不该出现的三样东西：情绪、反问句、\"你们是不是没看懂\"。

评审一天看几十条提交。他判你中危，通常不是因为不懂，是因为你递上去的材料只够判中危。这两句话差别很大。

我后来用的句式很固定：

我对这个判断的理解是 X，但我补充了 Y，麻烦再评估一次。

这句话同时做了三件事：承认对方的判断有依据、给出新增材料、把决定权还回去。

\"理解是 X\"这一半不能省。你得先把对方的逻辑复述对，他才会相信你真的看过他的理由，而不是只想要个更高的级别。

不要群嘲。别在群里截图说\"某平台又瞎判\"。这一次你可能赢了围观，下一次你的提交会被看得更仔细，而且不是往松的方向看。

也不要翻旧账。上一次另一个洞怎么判的，跟这一条无关。提了，就把这次讨论拖进了情绪。

我还学会一件事：申诉被驳回，就收手。同一条再申第二次，除非你有全新的材料，否则只是在消耗对方对你的耐心额度。这个额度，你在下一次真需要的时候会用得上。

也不是每条都值得申。判断方法很简单：如果你补充的材料只是把原来的话说得更重，别申；如果你手里多了一样原来没有的东西，申。

重复说一遍\"这很严重\"，对方只会再读一遍同样的材料。

07厂商那边也有一笔账要算

说完白帽子，也得说说对面。

同一个越权，A 审核员判高危，B 审核员判中危，理由都写得通。这种事在同一个平台内部就能发生。白帽子记性都好，撞上几次，信任就漏光了。

评级口径不公开，驳回时不写清卡在哪一项，申诉回复只有一句模板话术。三件事叠在一起，结果是认真做技术的人慢慢退出，留下来的是批量交低质量漏洞刷数量的人。

这个结果对厂商自己也不划算。

我不认为厂商有义务公开全部评级细则，那会被人反过来卡规则。但至少两件事现在就能做。

驳回时写清判定项。是可达性不够、影响面不足，还是证明不完整。三个字的差别，白帽子就知道下次该补什么，而不是瞎猜。

同类漏洞的口径内部对齐一次。把结论沉淀成可引用的判例，审核员换人时结论不换。

两件事都要花人力。不花的代价是，你收到的漏洞会越来越浅。

说回我们自己这一侧。

每次被判低，都是一次练习。练的是把\"这个洞技术上多严重\"翻译成\"这个洞对业务意味着什么\"。

这项能力不只在提交工单时有用。往后你要说服研发改一个有风险的架构，要向管理层解释为什么这个季度先修这三件事，要在事故复盘里讲清楚影响范围 —— 用的是同一套肌肉。

多挖两个中危，简历上多两行。学会翻译，值的不止这些。

这中间还有一层我自己想了很久才想通的东西。评级低不是对你技术的否定，它只是一次信息不对齐。你拿着洞，他拿着业务，两边都没把话说完。

把话说完这件事，谁先做谁占便宜。

ONE LINE
       定级争的从来不是分数，是你能不能把技术影响讲到业务那张桌子上。

参考来源

· CVSS v3.1 规范（Common Vulnerability Scoring System version 3.1）：由 FIRST（Forum of Incident Response and Security Teams）于 2019 年发布，含基础分、时间分、环境分三组指标

· OWASP Top 10（2021）：OWASP 基金会发布的 Web 应用十大安全风险，2021 年版为最新一版，其中 A01 为访问控制失效、A03 为注入

· CWE（Common Weakness Enumeration）：由 MITRE 维护的公共弱点枚举列表，用于描述漏洞的弱点类型而非具体实例

· NVD（National Vulnerability Database）：美国国家标准与技术研究院（NIST）运维的国家漏洞数据库，提供 CVE 条目及其 CVSS 评分