> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cosmos.network/llms.txt
> Use this file to discover all available pages before exploring further.

# Bug Bounty Program

> Security and maintenance policy documentation for the Cosmos Stack

<Info>
  This content is sourced from the official [Cosmos Security](https://github.com/cosmos/security) repository.

  **Last sync:** Apr 27, 2026 | [View source](https://github.com/cosmos/security/blob/main/SECURITY.md)
</Info>

## 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](https://hackerone.com/cosmos).
* If HackerOne submission is not possible, reports may be sent to
  `security@cosmoslabs.io` 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](https://hackerone.com/cosmos).

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.                                      |

These classifications follow industry standards and inform response
urgency and disclosure policy. Additional details are available in the
[Classification Matrix](https://github.com/cosmos/security/blob/main/resources/CLASSIFICATION_MATRIX.md).

***

## 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](https://geth.ethereum.org/docs/developers/geth-developer/disclosures)),
**Bitcoin Core** (see [https://bitcoincore.org/en/security-advisories/](https://bitcoincore.org/en/security-advisories/)),
and **Zcash** (see [https://z.cash/technology/security-advisories/](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)

All advisories remain publicly available. This delayed disclosure model
balances ecosystem safety with long-term transparency.

***

Cosmos Labs acknowledges and appreciates the contributions of security
researchers, auditors, and white-hat hackers who strengthen the Cosmos
ecosystem.

***

### References

* [Bitcoin Core Security Advisories](https://bitcoincore.org/en/security-advisories/)
* [Go Ethereum Vulnerability Disclosure](https://ethereumpow.github.io/go-ethereum/docs/vulnerabilities/vulnerabilities)
* [Bitcoin Core Security Disclosure Policy Announcement](https://bitexes.com/blog/124272)