此内容来源于官方的 Cosmos Security 仓库。最近同步： 2026 年 4 月 27 日 | 查看源文件
简介
Cosmos Labs 致力于维护 Cosmos Stack 的安全性，并支持负责任的漏洞披露。我们运营漏洞赏金计划，以激励安全研究人员识别并报告安全问题。 本文档定义了漏洞报告流程，介绍了漏洞赏金计划，并概述了 Cosmos Labs 在补丁修复和公开披露方面的处理方式。报告漏洞
必须进行私下披露 影响 Cosmos 生态系统的安全漏洞，包括 Cosmos SDK、CometBFT、IBC 以及其他核心组件，必须通过以下列出的渠道私下报告。- 首选： 通过 Cosmos HackerOne 漏洞赏金计划 提交报告。
- 如果无法通过 HackerOne 提交，可将报告发送至
[email protected]，并提供充分的技术细节，包括影响范围和复现步骤。
通过电子邮件提交的报告不符合赏金奖励资格。 只有通过 HackerOne 提交的报告才有资格获得赏金。在 Cosmos Labs 完成问题修复并明确授权披露之前，禁止公开披露漏洞（包括 GitHub issue、博客文章或社交媒体）。 披露时间线可与报告人协同安排。 提交报告即表示同意参与协调式漏洞披露，以便在公开发布细节之前，为修复方案的开发、测试和部署预留时间。
漏洞赏金计划概览
Cosmos Labs 通过 HackerOne 运营漏洞赏金计划。 符合条件的报告将根据严重程度、影响范围和报告质量给予奖励。 范围内： Cosmos Stack 的核心组件，包括 Cosmos SDK、CometBFT、IBC、Cosmos EVM 以及其他关键基础设施组件。 权威的范围定义、严重等级分类和奖励区间维护在 Cosmos 的 HackerOne 项目页面。 该计划依据适用于善意研究的 Safe Harbor 条款运行。HackerOne 页面定义了适用的协调式漏洞披露政策和 Safe Harbor 条款。如有冲突，以 HackerOne 政策为准，覆盖所有其他文档。
漏洞严重等级
已报告的漏洞会被分配一个严重等级，该等级决定处理优先级和披露时机。| 等级 | 说明 | 示例 |
|---|---|---|
| 严重 | 资金发生永久且无法恢复的损失 | 直接资金损失、未经授权且无限制的代币增发、不可逆的资金盗取。 |
| 高 | 对大量节点或用户造成严重影响；通常可被远程利用。 | 远程崩溃或链停摆类漏洞。 |
| 中 | 影响有限或有条件限制；利用可能需要特定条件。 | 需要高权限才能触发的节点停摆。 |
| 低 | 影响较小或利用场景不切实际。 | 区块传播缓慢、有限的拒绝服务。 |
静默修复与披露流程
对于大多数安全漏洞，Cosmos Labs 采用静默修复模式。在公开披露之前，问题会先被私下处理并完成修复。 这种做法与其他主要协议采用的实践一致，例如 Ethereum 的 Geth（见 https://geth.ethereum.org/docs/developers/geth-developer/disclosures）、**Bitcoin Core**（见 https://bitcoincore.org/en/security-advisories/）以及 Zcash（见 https://z.cash/technology/security-advisories/）。 过早披露可能会使尚未打补丁的网络面临风险。静默修复能为运营方争取升级时间，再将漏洞细节公开。 被归类为严重的漏洞将按个案处理。当某个问题带来即时风险或全网范围风险时，Cosmos Labs 会在任何公开披露之前启动紧急缓解措施、私下分发修复方案，或协调网络升级。 如果 Cosmos Labs 判断某个具有全网影响的漏洞（例如链停摆或共识失败）已经被积极利用，或者在计划发布之前已确认攻击者知晓该问题，则无论其原始分类为何，都会为响应和披露目的将其升级按严重级别处理。修复分发
- 修复将通过补丁版本或次版本发布。
- 发布说明可能不会明确提及安全影响。
- 验证者和节点运营方可能会被私下通知进行升级。
- 对于严重漏洞，修复可能会私下分发给关键运营方，或要求进行紧急网络升级。
披露时间线
| 严重程度 | 披露时机 | 说明 |
|---|---|---|
| 低 / 中 | 修复公开发布后约四周 | 发布包含影响和修复细节的完整安全公告。 |
| 高 | 受影响版本达到**生命周期结束（EOL）**之后（通常约 1 年） | 为降低被利用风险而延后披露。 |
| 严重 | 按个案处理（至少在 EOL 之后） | 仅在认为安全时才披露；细节可能会受到限制或不予公开。 |
透明度与事后披露
在披露禁运期结束后，Cosmos Labs 会发布安全公告（通过 GitHub advisories 或官方博客文章），其中包含：- 漏洞描述
- 受影响版本
- 严重等级分类
- 修复指导
- 报告人署名（除非要求匿名）
Cosmos Labs 感谢并认可安全研究人员、审计人员以及白帽黑客对强化 Cosmos 生态系统所作出的贡献。
参考资料
- Bitcoin Core Security Advisories
- Go Ethereum Vulnerability Disclosure
- Bitcoin Core Security Disclosure Policy Announcement
This content is sourced from the official Cosmos Security repository.Last sync: Apr 27, 2026 | View source
Introduction
Cosmos Labs is committed to maintaining the security of the Cosmos Stack and supporting responsible vulnerability disclosure. We operate a bug bounty program to incentivize security researchers to identify and report security issues. This document defines the process for reporting vulnerabilities, describes the bug bounty program, and outlines Cosmos Labs’ approach to patching and public disclosure.Reporting a Vulnerability
Private Disclosure Required Security vulnerabilities affecting the Cosmos ecosystem—including the Cosmos SDK, CometBFT, IBC, and other core components—must be reported privately through the channels listed below.- Preferred: Submit reports through the Cosmos HackerOne Bug Bounty Program.
- If HackerOne submission is not possible, reports may be sent to
[email protected]with sufficient technical detail, including impact and reproduction steps.
Reports submitted via email are not eligible for bounty rewards. Only reports submitted through HackerOne qualify for bounties.Public disclosure of vulnerabilities (including GitHub issues, blog posts, or social media) is prohibited until Cosmos Labs has remediated the issue and explicitly authorized disclosure. Disclosure timelines may be coordinated with the reporter. Submission of a report constitutes agreement to participate in coordinated vulnerability disclosure, allowing time for development, testing, and deployment of a fix prior to public release of details.
Bug Bounty Program Overview
Cosmos Labs operates a bug bounty program through HackerOne. Eligible reports are rewarded based on severity, impact, and quality. In Scope: Core Cosmos Stack components, including the Cosmos SDK, CometBFT, IBC, Cosmos EVM, and other critical infrastructure components. The authoritative scope definition, severity classifications, and reward ranges are maintained on the Cosmos HackerOne program page. The program is governed by Safe Harbor provisions for good-faith research. The HackerOne page defines the applicable Coordinated Vulnerability Disclosure Policy and Safe Harbor terms.In the event of conflict, the HackerOne policy supersedes all other documentation.
Vulnerability Severity Levels
Reported vulnerabilities are assigned a severity classification that determines handling priority and disclosure timing.| Level | Description | Examples |
|---|---|---|
| Critical | Permanent and irrecoverable loss of fund | Direct fund loss, unauthorized and unlimited token minting, irreversible theft of fund. |
| High | Severe impact affecting many nodes or users; often remotely exploitable. | Remote crash or chain halt vulnerabilities. |
| Medium | Limited or conditional impact; exploitation may require specific conditions. | Node halt requiring elevated permissions. |
| Low | Minor impact or impractical exploitation scenarios. | Slow block propagation, limited denial-of-service. |
Silent Patch and Disclosure Process
Cosmos Labs follows a silent patch model for most security vulnerabilities. Issues are addressed privately and remediated prior to public disclosure. This approach aligns with practices used by other major protocols, such as Ethereum’s Geth (see https://geth.ethereum.org/docs/developers/geth-developer/disclosures), Bitcoin Core (see https://bitcoincore.org/en/security-advisories/), and Zcash (see https://z.cash/technology/security-advisories/). Premature disclosure can place unpatched networks at risk. Silent remediation allows operators time to upgrade before vulnerability details become public. Vulnerabilities classified as Critical are handled on a case-by-case basis. When an issue presents an immediate or network-wide risk, Cosmos Labs will initiate emergency mitigations, private fix distribution, or coordinated upgrades before any public disclosure occurs. If Cosmos Labs determines that a vulnerability with network-wide impact (such as a chain halt or consensus failure) is already being actively exploited, or that attacker awareness is confirmed prior to a scheduled release, the issue is escalated and handled as Critical for response and disclosure purposes, regardless of its original classification.Fix Distribution
- Fixes are delivered through patch or minor releases.
- Release notes may omit explicit references to security implications.
- Validators and node operators may be notified privately to upgrade.
- For critical vulnerabilities, fixes may be distributed privately to key operators or require emergency network upgrades.
Disclosure Timeline
| Severity | Disclosure Timing | Details |
|---|---|---|
| Low / Medium | Approximately four weeks after public release of the fix | Full advisory published with impact and remediation details. |
| High | After the affected version reaches End-of-Life (EOL) (~1 year typical) | Disclosure delayed to reduce exploitation risk. |
| Critical | Case-by-case (At minimum after EOL) | Disclosure only when deemed safe; details may be limited or withheld. |
Transparency and Post-Disclosure
After expiration of the disclosure embargo, Cosmos Labs publishes a Security Advisory (via GitHub advisories or official blog posts) containing:- Vulnerability description
- Affected versions
- Severity classification
- Remediation guidance
- Reporter attribution (unless anonymity is requested)
Cosmos Labs acknowledges and appreciates the contributions of security researchers, auditors, and white-hat hackers who strengthen the Cosmos ecosystem.