OpenAI 赏金天花板抬到约 17.2 万美元,核心危急漏洞 3 万美元起
OpenAI 赏金区间中位数平均翻四倍以上:核心产品危急漏洞最高 30,000 美元,叠满奖励的特殊漏洞约 172,000 美元。本文拆解乘数怎么叠、Cathedral 冲刺意味着什么,以及为什么 172,000 美元不该是你的目标。

先说结论:核心产品严重漏洞最高可达 30,000 美元,叠满奖励可到约 172,000 美元
OpenAI 在 2026 年 11 月 2 日宣布上调安全漏洞赏金:中等、严重与危急级别的奖励区间中位数平均提高到原来的四倍以上。核心产品(ChatGPT、Codex 或 API Platform)中的危急漏洞,现在最高可获得 30,000 美元;符合“特殊”(exceptional)标准的危急漏洞,基础奖励仍为最高 100,000 美元,叠加各项奖励后最高可达约 172,000 美元。同一天,OpenAI 还宣布了另一项配套动作:与外部安全公司 Cathedral Systems 合作开展下一轮内部安全冲刺,用自家模型挑战自家防线。
这篇要先把一个容易误读的数字说清楚:172,000 美元不是“危急漏洞的新单价”,而是天花板。它要求同时满足四个条件——漏洞本身达到特殊级别、报告质量过硬、赶上优先活动、研究员处于最高忠诚等级。绝大多数报告拿不到这个数,能拿到 30,000 美元封顶的危急奖励,已经是这次上调后的新常态。理解这一点,才能正确判断这次调整到底改变了什么。
改了什么:四项变化,一次说清
第一,基础奖励区间整体上调。OpenAI 的说法是,中等、严重、危急三个级别的奖励区间中位数平均提高到四倍以上。官方给出的新锚点是:核心产品中的危急漏洞最高 30,000 美元。要注意“核心产品”这个限定:非核心资产的奖励低于核心产品,官方示例中非核心资产 Prism 的高危 IDOR 漏洞基础奖励为 2,500 美元,与核心产品的 30,000 美元完全不在一个量级。投稿之前先确认目标资产属于哪一档,比算奖励更重要。
第二,报告质量奖励。能提供可靠概念验证(PoC)、把漏洞隔离清楚、讲清何时可利用、论证实际影响的报告,可以获得质量乘数。官方示例中质量乘数为 1.15。这个设计传递的信号很明确:OpenAI 买的不只是“发现”,更是“可复现、可修复的发现”。一份只有截图和猜测的报告,和一份能让工程师按步骤复现的报告,在新规则下会拉开 15% 的差距。
第三,五级忠诚奖励。OpenAI 新设了五档忠诚奖励,奖励长期、持续合作的研究员。官方示例中出现的档位包括青铜(Bronze)1.05、黄金(Gold)1.10 与最高档 31337 的 1.15。这是对“回头客”的定价:第一次投稿和第十次投稿,在同样的漏洞上会拿到不同的钱。对独立研究员来说,这意味着与一家厂商建立长期合作关系本身就有了复利价值。
第四,优先活动乘数。针对新上线功能,OpenAI 会设立短期的优先活动,附带专门的奖励池,示例中的活动乘数为 1.30。这是最有时间价值的一项:新功能上线窗口期的漏洞,不仅竞争者少,而且奖励自带 30% 的加成。盯着新功能发布节奏投稿,收益会显著高于平时。
官方算例:一张表看懂奖励是怎么叠出来的
OpenAI 在公告中给了四组示例算例,全部标注为“示例与历史奖励均为示意”。中等漏洞示例:ChatGPT 核心资产中只读成员可向无写权限的 Project 上传文件,历史奖励 750 美元,新算法为 2,000 × 1.15(质量)× 1.05(青铜忠诚)= 2,415 美元。高危漏洞示例:非核心资产 Prism 的 IDOR 导致可读取他人上传到 Project 的文件,历史奖励 1,000 美元,新算法为 2,500 × 1.15 × 1.10(黄金忠诚)= 3,162.50 美元。
危急漏洞示例最能说明问题:ChatGPT 核心资产的一键接管账户漏洞,历史奖励 6,500 美元,新算法为 30,000 × 1.15(质量)× 1.30(优先活动)× 1.15(31337 忠诚)= 51,577 美元。特殊级别示例:可查看任意 ChatGPT 用户聊天记录这类严重破坏安全边界的漏洞,基础奖励 100,000 美元,同样叠满后为 100,000 × 1.15 × 1.30 × 1.15 = 171,925 美元,约等于公告标题中的 172,000 美元。注意乘法是连乘的:四项乘数叠加起来不是加 15% 加 30%,而是 1.15 × 1.30 × 1.15 ≈ 1.72 倍,这正是天花板数字的来源。
这张表还有一个反直觉的启示:同一漏洞在不同研究员手里价格不同。青铜研究员与 31337 研究员提交同一个危急漏洞,差价接近 10%;赶上优先活动与否,差价是 30%。投稿策略从此不只是“找什么漏洞”,还包括“什么时候投、用什么质量投、以什么身份投”。
溯及既往:已经提交的报告也能吃到新标准
这次调整包含一项对研究员非常友好的溯及条款:已经提交但尚未授予奖励的报告,直接适用新的奖励标准;公告前 30 天内已经授予奖励的报告,如果按新标准(基础奖励加忠诚奖励)算出来更高,OpenAI 会补足差额。这条规则消除了“早投吃亏”的顾虑,也避免了研究员为了等新标准而故意压着报告不交——而压报告对厂商和用户都没有好处。
从厂商的角度看,补差价是一笔小钱,换来的却是信任:研究员不需要猜测“现在投还是等一等”,规则本身就保证了不吃亏。这种设计值得所有运营漏洞赏金计划的团队借鉴——规则的不确定性本身就是一种成本,明确写出来,比事后逐个解释要便宜得多。
配套动作:与 Cathedral 的安全冲刺意味着什么
同一天宣布的另一项动作是:OpenAI 正在筹备下一轮内部安全冲刺,外部安全公司 Cathedral Systems 的研究员将使用 OpenAI 的模型,与 OpenAI 团队一起挑战其防线。官方的说法是,Cathedral 将带来“差异化的专业经验与方法”。据多家二次报道,这轮冲刺尚未公布开始时间、持续时长与目标清单,因此目前只能把它理解为一次计划中的合作,而非已经完成的一轮测试。
把这两件事放在一起看,逻辑是完整的:对外用更高的赏金吸引独立研究员,对内用外部团队加自家模型做集中攻防。据二次报道转述的配套公告,上一轮内部冲刺动员了约四分之一的产品工程师参与,用 Codex 协助调查、复现与准备修复补丁,并重申了面向一线防御者的 10 亿美元补贴承诺(六个月内以补贴形式提供)。这些数字是厂商自述的转述,应理解为官方说法而非独立测评,但方向是清楚的:当攻击者也能用上强大的模型时,防御方必须先用同样的能力打自己一遍。
这里需要提醒一句:Cathedral 近期曾因在另一家 AI 公司的赏金计划中的行为引发争议,多家报道提到过相关背景;OpenAI 的公告本身没有提及这些背景。本文不把这些背景当作 OpenAI 公告的事实,也不据此对合作本身下结论——读者如果关心,应当去核对原始报道,而不是从赏金公告里推断。
给独立研究员的判断:172,000 美元不该是你的目标函数
如果把 172,000 美元当成目标,很容易走偏:去追那些“可能够得上特殊级别”的极端漏洞,投入数周却一无所获。更现实的目标函数是三项可控因素的乘积:选对资产(核心产品优先)、选对时机(新功能优先活动窗口)、把报告写到可复现。这三项每一项都有明确的加成,而且都不依赖运气。
具体建议是:第一,优先研究核心产品的新功能,新功能上线后两周内是优先活动的典型窗口,奖励与竞争比最优;第二,报告模板固定化——漏洞隔离步骤、利用条件、影响论证、复现环境,四项缺一不可,质量乘数本质上是为这份模板付费;第三,把与 OpenAI 的合作当作长期关系经营,忠诚档位的复利会在第三次、第五次投稿时显现出来,而不是第一次。
另外一个实际提醒:OpenAI 的安全团队将于 11 月 20–21 日出现在奥克兰的 PROMPT2PWN 活动现场,可现场测试目标。如果你正好在附近,现场交流往往比邮件往来更高效——能当面确认的范围问题,不要靠猜测。
给 vibe 开发者的启示:赏金规则本身就是产品设计
这篇资讯对 vibe 开发者也有直接参考价值,哪怕你从不提交漏洞赏金。OpenAI 这次调整的本质,是用价格机制解决三个运营难题:如何让报告可复现(质量乘数)、如何留住好的研究员(忠诚档位)、如何让新功能获得优先测试(优先活动)。这三个难题,任何一个运营用户反馈、内测计划或赏金计划的产品都会遇到。
举一个可迁移的做法:如果你在自己的项目里接受外部安全反馈,不妨把奖励拆成“基础 + 质量 + 持续合作”三部分,而不是一个笼统的数字。基础奖励定发现的价值,质量加成定报告的可用性,持续合作加成定关系的价值。拆开之后,研究员知道该往哪个方向努力,你也不用每次都为“这份报告值多少钱”单独谈判。需要提醒的是,站内此前已发布过一篇关于运营漏洞赏金计划的实战指南(vibe-project-bug-bounty-guide),讲的是如何从零搭建自己的赏金计划;本篇讲的是 OpenAI 这家厂商的最新定价,两者题材不同,不要混淆。
最后回到一个基本判断:当一家 AI 公司的赏金天花板从 100,000 美元抬到约 172,000 美元时,它真正想买的不是某一个漏洞,而是整个研究社区的注意力排序——让最优秀的研究员先看它的产品,而不是别人的。这对所有依赖外部安全反馈的团队都是一个提醒:赏金标准不是成本项,而是注意力竞价;你的定价,决定了你排在研究员待办清单的第几位。
数字核对:为什么是 171,925 美元,而不是 172,000 美元
细心的读者会发现,公告标题说法是“最高约 172,000 美元”,而示例算例的精确结果是 171,925 美元。两者并不矛盾:172,000 美元是取整后的对外说法,171,925 美元是 100,000 × 1.15 × 1.30 × 1.15 的精确乘积。同样,危急漏洞示例的 51,577 美元也是 30,000 × 1.15 × 1.30 × 1.15 的精确结果(51,577.5 美元取整)。在引用这些数字时,建议同时给出精确算例与取整说法,避免把约数当成精确承诺。
还有一个数字值得单独核对:公告说奖励区间中位数“平均提高到四倍以上”,这是一个平均口径,不是每个级别都恰好翻四倍。从示例看,中等漏洞的历史奖励 750 美元对应新基础 2,000 美元(约 2.7 倍),高危漏洞 1,000 美元对应 2,500 美元(2.5 倍),危急漏洞 6,500 美元对应 30,000 美元(约 4.6 倍)。也就是说,上调幅度是向危急级别倾斜的:越严重的漏洞,涨幅越大。这符合赏金设计的常识——厂商最想买的,永远是影响最大的那一档。
投稿前必须先确认的一件事:范围以项目页为准
公告正文讲的是“OpenAI 软件中的漏洞”,并没有在正文中逐项列出收录与排除清单。实际投稿时,范围、目标资产分级、报告格式与披露规则,都以 Bugcrowd 上的赏金项目页为准。不要仅凭一篇资讯就开始测试:先读项目页,确认目标在范围内、确认测试方法不违反规则、确认披露流程,再动手。
这个提醒看似多余,却是赏金新手最常见的翻车点:测了不在范围内的资产、用了不被允许的测试手段、或者在厂商修复前公开了细节,每一种都可能导致报告无效,甚至失去后续合作资格。规则页多读十分钟,胜过事后申诉十封邮件。OpenAI 这次把奖励算例写得如此透明,恰恰说明它希望研究员把精力花在找漏洞本身,而不是花在猜规则上。
奖励变高之后,研究员的策略也该变一变
赏金天花板抬高,最直接的影响不是“同一个人能多拿多少钱”,而是“值得投入的漏洞类型变了”。过去中危漏洞的奖励不高,研究员往往优先追高危和危急;现在中危奖励的中位数也翻了几倍,一条链路完整、影响讲清楚的中危报告,收益已经值得认真打磨。这对独立研究员尤其友好:不需要每次都赌那种可遇不可求的危急链,只要把“复现步骤可靠、影响边界清晰、修复建议可行”三件事做到位,中危报告也能稳定变现。反过来,只堆数量、不讲质量的报告会越来越不划算——质量乘数、忠诚乘数和活动乘数都是乘在基础奖励上的,基础分低,再多乘数也放大不出多少。
忠诚计划的存在,还改变了“换个马甲重新开始”的算盘。五档忠诚乘数是按历史表现累积的,长期在同一项目下提交高质量报告的研究员,每份报告都会比新人多拿一截。这意味着赏金研究正在从“打一枪换一个地方”变成“长期经营一个项目”:熟悉目标的架构、跟踪新功能上线节奏、在新功能短期活动期间集中测试,比广撒网更有效。OpenAI 明确把新功能短期活动列为优先方向,也是同一个信号——厂商最想要的,是有人在新功能刚上线、最容易出问题的窗口里就把它测透,而不是等上线半年后再来补报告。
对厂商之外的读者,这次调整还有一层参考价值。很多小团队抄赏金政策时只抄“奖励金额表”,却不抄背后的结构:基础奖励、中危到危急的分档、质量乘数、忠诚累积、活动加成。OpenAI 这套结构的真正意图,是让研究员的收益与“报告对厂商的实际价值”对齐,而不是与“漏洞的惊悚程度”对齐。小团队即使拿不出几万美元的预算,也可以借鉴这个结构:给复现可靠的报告加分,给长期合作的研究员加分,给新功能上线窗口的报告加分。金额可以小,结构不能省——结构才是赏金计划能不能长期运转的关键,而不是某一次上调的数字。
还有一个容易被忽略的细节:赏金规则的溯及安排。这次调整明确,未授予的报告适用新标准,公告前三十天内已授予的报告如果按新标准更高还可以补差额。对正在等待评审的研究员来说,这意味着不需要为了赶新标准而催促评审,也不需要担心自己的报告“生不逢时”。这种溯及安排看似只是善意,实际上是在保护评审质量——研究员不催,评审员才能按正常节奏把每份报告查清楚,而不是为了赶在某个时间点前结案而草草定级。小团队抄规则时,这一条最值得抄:规则变了,让已经在流程里的人也受益,远比只奖励后来者更能留住合作者。
评论 (0)
原始来源
相关文章

GitHub 将从 12 月 2 日起在公开仓库默认阻止 pull_request_target,此前 11 月 9 日与 16 日各有一次褐断。本文讲清规则改了什么、哪类工作流该改回、拆分或定向放行,以及褐断前必须跑完的检查清单。

Anthropic 10 月 30 日证实:Claude Code 在 Opus 5.5 下新增两句服务端指令,拒绝复刻任何一个具体的现成游戏,哪怕改名、自称原创也不行。本文拆解规则原文、发现与证实链条、误伤案例与三处绕不过的短板,并给出 vibe 游戏开发者的四条实操建议。

社交登录把注册摩擦降到一次点击,但真正的成本藏在账号合并、state 与 PKCE、Token 存储里。本指南讲清 OIDC 与 OAuth 的分工、提供方选择、合并规则与上线前测试清单。