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