Strapi 安全漏洞披露机制详解：GHSA 报告要求、排除范围与协调披露流程

Strapi（一个 100% JavaScript/TypeScript 的开源无头 CMS）在仓库根目录以 SECURITY.md 明确了其安全漏洞的受理范围、报告规范与协调披露流程。本文完整拆解该策略文档的核心内容——支持版本矩阵、"开发模式默认行为不算漏洞"的测试要求、GHSA 报告模板与 AI 使用披露要求、基于 CNA 运行规则的排除清单，以及从提报到公开发布的 15 步安全流程。读完后，安全研究员可以准确判断自己的发现是否在 Strapi 的受理范围内、应如何组织一份合格的漏洞报告；Strapi 运维者则能理解官方对"默认开发配置"与"生产加固"的责任边界划分。

支持版本：只有 v5.x GA/Stable 在安全更新覆盖范围内

Strapi 的策略文档开宗明义：截至 2026 年 5 月（且直到该文档更新为止），只有 v5.x.x 的 GA（正式）或 STABLE 发布版本享受安全更新与缺陷修复；更早的版本不受支持，使用者需"自担风险"。版本矩阵如下（原文照录）：

版本	支持开始	支持结束	安全更新截止	备注
5.x.x	2024 年 9 月	—	—	LTS
4.x.x	2021 年 11 月	2025 年 10 月	2026 年 4 月	已终止支持（EOL）
3.x.x	2020 年 5 月	2022 年 11 月	2022 年 11 月	已终止支持（EOL）

一个关键细节是：非稳定版（RC、Beta、Alpha）在对应的 GA/Stable 版本发布后即视为终止支持。也就是说，如果你在 5.x 的某个 RC 上发现了漏洞，而该版本已有对应的正式 release，那么 RC 本身不再属于安全更新范围。

适用范围：In Scope 与 Out of Scope 的清晰分界

策略明确其适用于从该 monorepo 发布的包——包括 Strapi 核心、所有 @strapi/* 包以及捆绑的管理后台（admin panel），且仅限于当前受支持的版本。

在范围内（In Scope）：

• v5.x.x 最新的 GA / Stable 发布版本；
• 由本仓库发布的 @strapi/* 包中的漏洞。

不在范围内（Out of Scope）：

• 已终止支持的大版本（v3.x、v4.x），以及任何非 GA 的 v5.x 发布标签（Alpha / Beta / RC）；
• 第三方或社区 Marketplace 插件（非 Strapi 官方发布）——应直接向插件维护者报告；
• 客户自行运营的 Strapi 实例及其承载基础设施；
• 你不拥有或不运营的 Strapi Cloud 生产租户；
• Fork 与衍生项目。

这个范围划分对研究者有直接的实际意义：Strapi 仓库是一个 monorepo，核心、各 @strapi/* 包与管理后台均在其中（可参见仓库 packages/core/ 目录下的 core、strapi、content-manager 等子包），但社区插件不在其安全责任边界内。

测试要求：为什么"只在开发模式复现"不算漏洞

这是整份策略中最具技术实质的一节，也是理解 Strapi 安全立场的关键。策略要求报告者在提交前，必须对一个正确配置的生产应用进行验证。原因在于 Strapi 出厂的一系列默认值有意偏向本地开发的开发体验（developer ergonomics），某些"漏洞"只有在开发模式默认配置下才会显现；将应用加固为生产部署形态，是开发者/运维者的责任，并在 Strapi 的部署指南中有所记录。

策略列举了不应作为漏洞报告的"开发模式预期行为"，这些都能在仓库源码中找到对应实现：

1. CORS 默认不锁定。Strapi 的 CORS 中间件源码 packages/core/core/src/middlewares/cors.ts 中，defaults 对象的 origin 默认为 '*'（同时 credentials: true），即默认允许任意来源跨域访问——这是策略中"developers must configure allowed origins for production"的直接代码依据。运维者需要在 config 中将 origin 配置为具体的允许来源列表才能收敛。

2. 上传的 MIME 类型与文件扩展名限制默认不强制。仓库的 upload 插件中存在 MIME 校验相关的工具与测试（如 packages/core/upload/server/src/utils/tests/mime-validation.test.ts），说明校验能力存在，但策略将"默认未开启限制"归为运维者应在部署时自行配置的项。

3. 仅开发模式出现的冗长错误响应、堆栈跟踪或调试输出。

4. 默认管理后台 URL、默认 API token 配置等被文档明确标注为"需要运维者配置"的部署期选项。

5. 判定基准可以概括为一句话：任何在 strapi develop 下可复现、但在 strapi start 配合生产加固配置下不可复现的行为，都不算漏洞。这两个命令在仓库中确有对应实现：packages/core/strapi/src/cli/commands/develop.ts 与 packages/core/strapi/src/cli/commands/start.ts。

策略对此的处理是明确的：如果报告只能在开发模式或默认开发配置下复现，将被以"范围外"关闭。

报告渠道：GHSA 是唯一入口，且没有赏金

所有漏洞报告必须通过 GitHub 的 Security Advisory（GHSA）系统提交，这是唯一被接受的受理渠道；报告需通过仓库的 GHSA 新建入口提交。CVE 由 GitHub 代表 Strapi 在 GHSA 流程中签发，报告者不要自行申请 CVE——Strapi 会在公告流程中通过 GitHub 发起申请。

机器可读的安全联系信息按 RFC 9116 规范发布在仓库的 .well-known/security.txt 中。该文件内容与策略文档完全一致：Contact 指向 GHSA 新建入口与 [e-mail] 邮箱，Preferred-Languages 为 en，Policy 指向 SECURITY.md，Acknowledgments 指向 GitHub 安全公告页（该页同时充当对历史报告者的致谢记录）。

策略用醒目的 IMPORTANT 提示明确声明：Strapi 目前不提供、且没有计划提供任何漏洞赏金、周边礼品或其他形式的回报；提交报告不构成付款请求，团队不会就补偿进行谈判。

报告的署名与致谢（opt-in 模式）

在公开公告中给报告者署名是**自愿选择（opt-in）**的，报告者需在 GHSA 报告中三选一并明确表态：

• 署名（Credit me, with）：给出确切的展示名、handle、所属组织（可选），以及一个希望被链接的个人 URL（博客、个人站、GitHub 主页或社交账号）；
• 匿名署名（如 "an independent security researcher"）；
• 不署名——公告中不提及其人。

如果不表态，默认按不署名处理；在公告发布前任何时间点都可以更改选择。Strapi 不会公布邮箱、电话或任何其他联系方式。

报告必备内容与标准模板

初始报告必须包含以下全部要素：

• 疑似漏洞的摘要（summary）；
• 该漏洞具体能做什么、能访问什么的详细信息；
• 概念验证（PoC）——至少要有代码样例，复现视频可选。PoC 必须说明漏洞如何实际访问敏感数据、提升权限或以其他方式突破安全边界——仅仅在浏览器里触发一个弹窗告警不构成安全漏洞；
• 影响概述（谁受影响、如何受影响）；
• AI 使用披露（见下文）。

可选地，你可以附上自己估算的 CVSS 4.0 分值，但 Strapi 保留调整权利。

语言要求：只接受英文报告。 初始报告及后续全部往来（PoC、补充细节、截图、通过 GHSA 评论索取的脚本等）都必须使用英文；其他语言提交的报告会被关闭并要求用英文重新提交。

报告至少应遵循以下模板（原文完整保留，可直接复制使用）：

## Summary

<one or two sentence summary of the vulnerability>

## Affected Versions

<which Strapi versions are affected, e.g. 5.0.0 - 5.x.x>

## Vulnerability Details

<detailed technical description of the vulnerability, what it does, and what it can access>

## Proof of Concept

<step-by-step reproduction; include code samples inline using fenced code blocks. Do NOT attach files.>

## Impact

<who is impacted and how — e.g. authenticated users with X role can perform Y, leading to Z>

## Suggested CVSS 4.0 Score (optional)

<your estimate, if any — see https://www.first.org/cvss/calculator/4-0>

## AI Usage Disclosure

<state whether AI tools were used during discovery, analysis, validation, or drafting of this report. If yes, list which tools and at which stages, and confirm that findings were manually verified by a human.>

AI 工具的使用披露是强制项

如果在漏洞发现的任何环节——发现、验证、分析或撰写报告——使用了 AI 工具（LLM、AI 驱动的扫描器、AI 辅助代码分析、agentic 编码工具等），必须在初始报告中披露。披露内容应包括：

• 使用了哪些 AI 工具；
• 用在了哪些阶段（发现、验证、PoC 生成、报告撰写等）；
• 确认发现结果在提交前已经过人工手动验证。

策略明确警告：看起来未经人工验证、纯 AI 生成的报告，或在明显使用了 AI 却未披露的报告，大概率会被拒绝。这与后文"排除清单"中"缺乏人工验证复现的 LLM 生成叙述型报告"一条相互呼应。

附件规则：一切内联，拒绝预上传

原始报告不接受任何文件附件。 所有代码样例、PoC 与引用都必须以围栏代码块的形式直接内联在 GHSA 报告正文中。如果 Strapi 判断还需要额外材料（脚本、归档、截图、大文件等），会主动通过 GHSA 评论系统向你索取——请等他们开口，不要在初始报告中预先附加文件，也不要链接到外部文件托管服务。

响应时间与升级路径：没有固定 SLA

策略用 IMPORTANT 提示声明：由于 AI 生成的漏洞报告数量激增，整体提交量急剧上升，Strapi 已无法承诺具体的响应时限。 报告按善意与分诊能力尽快处理，其中"写得清楚、经过人工验证、影响与复现步骤明确"的报告会被优先捡起。

在没有固定 SLA 的前提下，策略为报告者规定了一条唯一的升级路径，而不是重复提交或另找渠道：

1. 至少等待 14 天再考虑升级。分诊是排队制而非严格先到先得——写得好的报告会比那些需要反复澄清的报告更快被处理；
2. 14 天后仍无回应，在 GHSA 线程本身发一条礼貌的跟进评论——这是唯一支持的升级渠道；
3. 不要重复开公告、直接邮件联系 Strapi 员工、在 Discord / Slack / 社交媒体上发帖，或以升级为目的联系 [e-mail]——邮箱不是升级渠道，这些行为不仅不会推进报告，反而可能让它排在更后面。

如果又经过一段合理时间（≥ 14 天）GHSA 线程上仍无回应，此时才可以引用 GHSA ID 邮件 [e-mail]，Strapi 会调查报告为何未被捡起。

修复节奏方面：报告一旦被确认为有效漏洞，Strapi 会视复杂度尽快发布补丁，历史上通常在几天内。随后进入严格的内外部披露流程：补丁随版本发布，patch notes 中会带上"已修复安全漏洞"的警告，而详细披露会依据严重性延迟 2 至 8 周。如果你有博客文章等计划发布的资源并希望纳入披露范围，应尽早告知。任何公开披露之前，先与 Strapi 沟通，以确保在补丁可用且用户有时间升级之前不泄露过多信息。

特定排除项：CNA 规则与低信号报告清单

依据 CNA（Common Vulnerabilities and Names Authority）运行规则，以下类别不应作为漏洞报告提交（原文引用了具体规则条款）：

• Strapi 所使用的第三方依赖库自身的漏洞（CNA 规则 4.1.12）——除非有充分证据表明该库在 Strapi 内引发了新漏洞（规则 4.1.14）。规则 4.1.12 的核心表述是：更新产品依赖这一行为本身不得被判定为产品的漏洞，无论依赖是否有漏洞；对产品的公告应引用依赖自身漏洞的 CVE ID。
• Strapi 的 EOL 版本（CNA 规则 4.1.13）：产品处于 EOL 状态本身不得被判定为漏洞。
• 授权用户所做的不当配置（CNA 规则 4.1.3）：该配置若有良好文档或属业界常识，不应被判定为漏洞。
• 不导致安全影响的状况或行为（CNA 规则 4.1.2）：如攻击者访问权扩大、目标可用性下降或其他安全策略违背之外的"影响"不算。

在 CNA 规则之外，策略还列出了一份"长期低信号、通常不予修复即关闭（除非报告者能证明具体且非理论化的影响）"的报告类别清单，值得逐条研读：

• 仅能在开发模式或默认开发配置下复现的报告（见测试要求一节）；
• 无提权、账号冒充或跨用户影响路径的 Self-XSS；
• 只有文字描述、缺乏可运行可复现 PoC 的理论漏洞；
• 未经人工验证、根因分析或影响论证的自动化扫描器原始输出（SAST、DAST、依赖扫描器、AI 漏洞扫描器）；
• 无可演示利用的缺失安全头（CSP、X-Frame-Options、HSTS 等）；
• 作用于无状态变更端点、且无可演示安全影响（数据外泄、账号接管、有意义规模上的资源耗尽）的缺失限流；
• 页面上无敏感状态变更操作的 Clickjacking / UI redress；
• 公开面上的版本/横幅/技术栈信息泄露且无下游利用演示；
• 作用于无状态变更端点、或已受认证/token 机制保护的端点上的 CSRF；
• 无可演示影响（如 token 窃取、OAuth 滥用）的开放重定向；
• 无下游影响演示的用户名/邮箱枚举；
• 需要攻击者控制受害者的网络、浏览器扩展、宿主机器或开发环境的漏洞；
• 需要认证访问自己实例才能实现资源耗尽的 DoS（例如管理员向自己的部署上传超大文件）；
• 第三方或社区 Marketplace 插件中的问题——直接向插件维护者报告；
• 主体由 LLM 生成叙述构成、且报告者本人未做人工验证复现的报告；
• 针对 Strapi 员工、贡献者或社区成员的社会工程攻击；
• 针对开发者机器或生产服务器的物理接触攻击；
• 不对应真实安全边界违背的最佳实践建议（例如"你应该更频繁地轮换密钥"）。

此外，策略还保留了通用红线：任何针对 Strapi 团队、员工或合作伙伴代表的威胁、勒索/敲诈意图、或以恶意意图（如以淹没安全资源为目的）提交的报告，将被立即拒绝关闭，视情况上报相关执法或安全项目组织。

Safe Harbor：善意研究的法律保护边界

Strapi 支持在本策略范围内、遵守本策略规则开展的善意安全研究，并承诺不对满足以下全部条件的研究者采取法律行动：

• 善意遵守本策略；
• 仅通过上文描述的 GHSA 流程报告漏洞；
• 只测试自己拥有或运营的实例，或明确获授权用于安全测试的环境；
• 避免侵犯隐私、破坏数据，以及中断或降级 Strapi 服务；
• 不超出演示漏洞所严格必要的范围去利用、外泄或留存数据；
• 在协调披露时间线走完之前不做公开披露。

超出此安全港口的行为——包括测试 Strapi Cloud 生产租户、你未拥有的第三方 Strapi 实例、未被明确开放测试的 Strapi 运营基础设施，或"特定排除项"中描述的任何行为——均不属于本策略授权范围，可能被移交相关当局。该安全港口条款不授予违反任何适用法律的许可，也不约束任何第三方。

披露前通知：仅面向付费客户与合作伙伴

在确认漏洞的公开披露之前，Strapi 会向所有存在付费商业关系的客户与合作伙伴发送预先披露/提前预警通知，收件人名单包括：

• Strapi Cloud 付费层级客户；
• Strapi Growth 客户；
• Strapi Enterprise 客户；
• 在 Strapi Partner Program 中、其合作伙伴协议附带有效付费许可或订阅的合作伙伴。

这些通知旨在给受影响方留出准备补丁发布与评估自身部署暴露面的时间。接收方受其商业协议中保密条款约束，不得在协调公开披露日之前公开讨论、写博客、发推或以其他方式分享通知内容。

需要明确的是：Strapi 不运营任何面向开放/社区层的预先披露名单。免费层用户、社区插件维护者与公众将在公开披露时通过 GitHub 公告、CVE 记录、release notes 与博客获知漏洞。如果你使用免费/社区层并希望尽早获知已修复问题的消息，官方建议关注 Strapi 的 Releases 页面并订阅（watch 仓库并选择 Custom → Releases，或订阅 releases Atom feed）——安全相关的 release 在补丁发布时就会在 patch notes 中带出警告，尽管详细公告仍会遵守 2–8 周的禁运期。

安全流程全景：从提报到公开披露的 15 个环节

策略文档最后给出的流程拆解，完整设定了研究者可预期的时间线与沟通节点：

1. 通过 GitHub 安全公告系统提交漏洞；
2. 开始内部跟踪并与报告者建立沟通；
3. 内部验证漏洞；
4. 内部通知并排期补丁开发；
5. 开始开发补丁；
6. 验证补丁（内部验证 + 与报告者共同验证）；
7. GitHub 公告信息整理；
8. 通过 GitHub 申请 CVE；
9. 披露与沟通草案；
10. 补丁随版本发布，patch notes 带出首个警告；
11. 向付费客户与合作伙伴发送披露前通知；
12. 强制等待期（2 至 8 周）；
13. 发布 GitHub 公告与 CVE；
14. 公开披露（博客文章）；
15. 向付费客户与合作伙伴发送含公开披露细节的跟进沟通。

其他报告平台与例外情形

Strapi 不支持其他报告平台——所有安全漏洞必须经由 GHSA 系统提交。策略点名了若干明确不支持的渠道，包括 huntr.dev、直接联系 Strapi 员工（Discord、Slack 或邮件）、Stack Overflow 等（原文表述为"部分而非全部"）。

唯一的窄例外：如果你的司法辖区无法访问或受限 GitHub、确实无法走通 GHSA 提交流程，可以邮件 [e-mail]，Strapi 会代你开启 GHSA。注意两点：该例外仅针对辖区访问限制，不是一般性替代受理渠道；且如果你没有 GitHub 账号，Strapi 在流程中无法与你共享私有 fork、PR、公告草稿等协调产物。此外，邮箱发起的报告同样适用本策略的全部规则——必备报告内容、报告模板、AI 披露要求与禁止附件规则，一条不少。

小结：给研究者与运维者各一条主线

对安全研究员而言，这份策略的价值在于把"什么会被受理、什么会被直接关闭"写成了可核对的清单：受支持版本内的真实边界违背、生产配置下可复现、PoC 完整、全英文、AI 使用如实披露、附件内联——满足这些条件的报告才有进入分诊队列的资格；反之，开发模式默认行为、扫描器原始输出、低信号类别都会触发即关闭处理。

对 Strapi 运维者而言，策略反向划清了责任边界：CORS 来源限制（源码默认 origin: '*'）、上传 MIME 白名单、默认管理 URL 与 token 配置等，都被明确定位为"运维者应在部署时自行加固"的项。换言之，生产环境的默认安全姿态由部署方负责，Strapi 的核心团队只对生产加固配置下仍然成立的安全边界违背承担修复责任。

以上全部内容以仓库根目录 SECURITY.md 为准；若策略更新（例如版本支持矩阵、响应时限），以该文件与 .well-known/security.txt 的最新内容为准。