IMPORTANT: If you find a security issue, you can report it to our bug bounty program on HackerOne. DO NOT open a public issue on the repository.

As part of our Coordinated Vulnerability Disclosure Policy, we operate a bug bounty program with Hacker One.

See the policy linked above for more details on submissions and rewards and read this blog post for the program scope.

The following is a list of examples of the kinds of bugs we're most interested in for the Cosmos SDK. See here for vulnerabilities we are interested in for Tendermint and other lower-level libraries (eg. IAVL).

• /baseapp
• /crypto
• /types
• /store

• x/auth
• x/bank
• x/capability
• x/staking
• x/slashing
• x/evidence
• x/distribution
• x/mint

We are interested in bugs in other modules, however the above are most likely to have significant vulnerabilities, due to the complexity / nuance involved. We also recommend you to read the specification of each module before digging into the code.

• Integer operations on tx parameters, especially sdk.Int / sdk.Dec
• Gas calculation & parameter choices
• Tx signature verification (see x/auth/ante)
• Possible Node DoS vectors (perhaps due to gas weighting / non constant timing)

• HD key derivation, local and Ledger, and all key-management functionality
• Side-channel attack vectors with our implementations
  • e.g. key exfiltration based on time or memory-access patterns when decrypting privkey

The Cosmos SDK team uses the following disclosure process:

1. After a security report is received, the Cosmos SDK team works to verify the issue and confirm its severity level using Common Vulnerability Scoring System (CVSS).
2. The Cosmos SDK team collaborates with the CometBFT and Gaia teams to determine the vulnerability’s potential impact on the Cosmos Hub and partners.
3. Patches are prepared in private repositories for eligible releases of Cosmos SDK. See Stable Release Policy for a list of eligible releases.
4. If it is determined that a CVE-ID is required, we request a CVE through a CVE Numbering Authority.
5. We notify the community that a security release is coming to give users time to prepare their systems for the update. Notifications can include forum posts, tweets, and emails to partners and validators.
6. 24 hours after the notification, fixes are applied publicly and new releases are issued.
7. The Gaia team updates their CometBFT and Cosmos SDK dependencies to use these releases and then issues new Gaia releases.
8. After releases are available for CometBFT, Cosmos SDK, and Gaia, we notify the community again through the same channels. We also publish a Security Advisory on Github and publish the CVE, as long as the Security Advisory and the CVE do not include information on how to exploit these vulnerabilities beyond the information that is available in the patch.
9. After the community is notified, CometBFT pays out any relevant bug bounties to submitters.
10. One week after the releases go out, we publish a post with details and our response to the vulnerability.

This process can take some time. Every effort is made to handle the bug in as timely a manner as possible. However, it's important that we follow this security process to ensure that disclosures are handled consistently and to keep Cosmos SDK and its downstream dependent projects--including but not limited to Gaia and the Cosmos Hub--as secure as possible.

Communications to partners usually include the following details:

1. Affected version or versions
2. New release version
3. Impact on user funds
4. For timed releases, a date and time that the new release will be made available
5. Impact on the partners if upgrades are not completed in a timely manner
6. Potential required actions if an adverse condition arises during the security release process

An example notice looks like:

Dear Cosmos SDK partners,

A critical security vulnerability has been identified in Cosmos SDK vX.X.X.
User funds are NOT at risk; however, the vulnerability can result in a chain halt.

This notice is to inform you that on [[**March 1 at 1pm EST/6pm UTC**]], we will be releasing Cosmos SDK vX.X.Y to fix the security issue.
We ask all validators to upgrade their nodes ASAP.

If the chain halts, validators with sufficient voting power must upgrade and come online for the chain to resume.

The following timeline is an example of triage and response. Each task identifies the required roles and team members; however, multiple people can play each role and each person may play multiple roles.

1. Request CVE number (ADMIN)
2. Gather emails and other contact info for validators (COMMS LEAD)
3. Test fixes on a testnet (COSMOS SDK ENG)
4. Write “Security Advisory” for forum (COSMOS SDK LEAD)

1. Post “Security Advisory” pre-notification on forum (COSMOS SDK LEAD)
2. Post Tweet linking to forum post (COMMS LEAD)
3. Announce security advisory/link to post in various other social channels (Telegram, Discord) (COMMS LEAD)
4. Send emails to partners or other users (PARTNERSHIPS LEAD)

1. Cut Cosmos SDK releases for eligible versions (COSMOS SDK ENG)
2. Cut Gaia release for eligible versions (GAIA ENG)
3. Post “Security releases” on forum (COSMOS SDK LEAD)
4. Post new Tweet linking to forum post (COMMS LEAD)
5. Remind everyone using social channels (Telegram, Discord) that the release is out (COMMS LEAD)
6. Send emails to validators and other users (COMMS LEAD)
7. Publish Security Advisory and CVE if the CVE has no sensitive information (ADMIN)

1. Write forum post with exploit details (COSMOS SDK LEAD)
2. Approve payout on HackerOne for submitter (ADMIN)

1. Publish CVE if it has not yet been published (ADMIN)
2. Publish forum post with exploit details (COSMOS SDK ENG, COSMOS SDK LEAD)