Cosmos Ecosystem Security Guide: Deconstructing Security Scenarios Across Cosmos Ecosystem Components
TechFlow Selected TechFlow Selected
Cosmos Ecosystem Security Guide: Deconstructing Security Scenarios Across Cosmos Ecosystem Components
This article not only analyzes major past security vulnerabilities in the Cosmos ecosystem but also classifies common security vulnerabilities based on their causes, impacts, code locations, and other factors.
Navigating Web3 tides with focused insightsAuthor: CertiK
As one of the largest and most renowned blockchain ecosystems globally, Cosmos focuses on enhancing blockchain interoperability, enabling efficient communication between different blockchains. A series of leading projects, including Celestia and dYdX v4, are built upon the Cosmos SDK and IBC protocol.
As Cosmos development components gain increasing favor among developers, security issues within the Cosmos ecosystem will inevitably have broader implications. For example, the previously discovered Dragonfruit vulnerability in the Cosmos SDK impacted the normal operations of multiple major public chains. Due to the decentralized nature of foundational components in the Cosmos ecosystem, developers must use or extend different components based on specific functional requirements, resulting in security issues that are similarly scattered and diverse. Therefore, a research report helping developers systematically understand the current security landscape and mitigation strategies within the Cosmos ecosystem is highly necessary.
CertiK’s exclusive publication, the "Cosmos Ecosystem Security Guide," meticulously analyzes various security scenarios across different components of the Cosmos ecosystem through reader-friendly categorization. This report not only includes analyses of past major security incidents within the Cosmos ecosystem but also classifies common vulnerabilities by cause, impact, code location, and more, providing maximum security guidance for Cosmos developers and serving as a reference index for security auditors learning about and auditing Cosmos-related security issues.
CertiK has consistently contributed to improving the security of both the Cosmos ecosystem and the broader Web3 landscape through continuous research and discovery. We will regularly share various project security reports and technical studies—stay tuned! If you have any questions, please feel free to contact us.
Below is the full text of the "Cosmos Ecosystem Security Guide"👇.
Overview
Cosmos is an open-source, open, and highly scalable cross-chain network, and one of the most well-known blockchain ecosystems globally. Cosmos is a heterogeneous network supporting cross-chain interactions launched by CometBFT (formerly the Tendermint team), consisting of multiple independent, parallel blockchains forming a decentralized network. Its vision is to break down information silos and enable interoperability between different blockchains. In today's multi-chain era, achieving cross-chain interaction has become an urgent demand in the blockchain industry.
Cosmos provides an efficient cross-chain model, particularly suitable for public chains focused on specific vertical domains. By offering modular blockchain infrastructure, Cosmos offers convenience to application developers, allowing them to select and utilize public chains that meet their needs.
Applications and protocols within the Cosmos ecosystem connect via the IBC (Inter-Blockchain Communication) protocol, enabling cross-chain interactions between individual blockchains and allowing assets and data to flow freely. Cosmos’ vision is to build an internet of blockchains, providing scalability and interaction possibilities for a large number of autonomous, easy-to-develop blockchains.
For a long time, CertiK has maintained thorough attention and research on the Cosmos ecosystem environment. We have accumulated substantial experience in Cosmos ecosystem security. In this research report, we will present our exploration and findings regarding the security of the Cosmos ecosystem, focusing primarily on four areas: Cosmos SDK security, IBC protocol security, CometBFT security, and CosmWasm security. Our analysis will extend from fundamental components of Cosmos to base chains or application-specific chains within the ecosystem. Through analyzing and expanding on similar issues, we aim to present key security aspects related to the chains themselves in a bottom-up manner.
Due to the complex diversity of the Cosmos ecosystem, its security issues exhibit diverse characteristics. Therefore, this research report does not cover all types of security vulnerabilities; it only discusses those with typical features and greater potential harm to Cosmos ecosystem chains. For further details on other security issues, please contact CertiK security engineers for discussion.
Background
-
CometBFT: The Foundation of Cross-Chain Scalability
CometBFT is an innovative consensus algorithm comprising two main components: the underlying consensus engine (CometBFT Core) and the generic Application Blockchain Interface (ABCI). Its consensus algorithm combines PBFT+Bonded PoS hybrid consensus to ensure nodes synchronously record transactions. As a core component of Interchain scalability, CometBFT maintains the security, decentralization, and integrity of the Interchain ecosystem through validator consensus.
-
Cosmos SDK: Modularity and New Features
The Cosmos SDK is a toolkit designed to accelerate developers' development processes, offering modularity and pluggable features. Using the Cosmos SDK, developers can build their own blockchains or functional components based on the CometBFT consensus algorithm, enabling convenient development and shortened development cycles. It has already been adopted by many blockchain projects such as Cronos, Kava, and the recently launched dYdX V4. Future development plans will focus on modularity and introducing new features, enabling developers to create more complex, modular applications and fostering a broader, stronger ecosystem.
-
IBC Protocol: Enhancing Interoperability and Scalability
The IBC protocol (Inter-Blockchain Communication Protocol) enables secure, decentralized, and permissionless data transfer between blockchains. Since Cosmos consists of multiple independent, parallel blockchains forming a decentralized network utilizing relay technology to achieve cross-chain functionality between different blockchains, IBC can be considered the core component of the entire project. The Interchain Foundation currently focuses on two themes: scalability and usability. By enhancing IBC’s scalability and interoperability, Cosmos will further expand its ecosystem capacity, enabling seamless interactions between blockchains, applications, and smart contracts.
-
CosmWasm: Unlocking Decentralized, Permissionless Deployment
CosmWasm (Cosmos WebAssembly) is a WebAssembly-based smart contract framework specifically designed for the Cosmos ecosystem. It allows developers to deploy decentralized applications without permission requirements while enabling blockchain developers to decouple their product development cycle from blockchain upgrades, thereby reducing validator upgrade costs. Additionally, it features a modular architecture, integration with the Cosmos SDK, cross-chain communication, and other capabilities.
To date, the Cosmos SDK and IBC protocol are relatively mature and widely used throughout the current Cosmos ecosystem.
From the perspective of chain developers, most custom functionalities required by ecosystem chains on Cosmos can currently be accomplished using the Cosmos SDK. To perform special operations during cross-chain interactions or optimize performance, chain developers may customize their respective IBC modules. Additionally, a small number of chains may modify and customize underlying engines like CometBFT Core. Due to space limitations, these latter cases won't be discussed in this report. This report will primarily analyze the technical aspects and security issues of the Cosmos SDK and IBC protocol.
Cosmos SDK Security Guide
The Cosmos SDK is a powerful and flexible framework for building blockchain applications and decentralized protocols. Developed by the Interchain Foundation, it is a core component of the Cosmos network—a decentralized network of interconnected blockchains.
The Cosmos SDK aims to simplify the development of custom blockchain applications and enable seamless interoperability between different blockchains. Key features of the Cosmos SDK include: modular architecture, customizability, integration with CometBFT, implementation of IBC interfaces, and developer-friendliness. The Cosmos SDK leverages the underlying CometBFT Core consensus engine to ensure robust security, protecting the network against malicious attacks and safeguarding user assets and data. Furthermore, its modularity allows users to easily design custom modules. Despite these advantages, security vulnerabilities may still arise when developers use the Cosmos SDK to implement their own applications.
From a security audit perspective, we need comprehensive coverage of the audit target, fully considering potential security risks from all angles. However, from a security research standpoint, greater emphasis should be placed on identifying high-impact vulnerabilities to avoid major security risks efficiently and provide more effective support to service integrators. From this perspective, categorizing high-risk, wide-reaching vulnerabilities and analyzing their vulnerability models is essential and valuable.
Within the ABCI interface spanning the entire Cosmos ecosystem, we focus particularly on the BeginBlock, EndBlock, CheckTx, and DeliverTx interfaces. The first two directly involve execution logic for individual blocks, while the latter two relate to the specific processing of sdk.Msg (the fundamental data structure for message transmission in the Cosmos ecosystem).
Since implementation logic for various application chains in the Cosmos ecosystem often follows modules and examples similar to those in the Cosmos SDK, understanding the following security vulnerabilities requires a basic grasp of the module execution workflow within the Cosmos SDK.
In the Cosmos ecosystem, transactions are initially created in a user agent, then signed and broadcast to nodes within the blockchain. Nodes use the CheckTx method to verify various transaction details such as signatures, sender balances, transaction sequences, and provided gas. If the transaction passes validation, it is added to the mempool, awaiting inclusion in a block. Conversely, if validation fails, an error message is sent back to the user, causing the transaction to be rejected. During block execution, further checks are performed via the DeliverTx method to ensure consistency and determinism.
In the Cosmos SDK, the lifecycle of a transaction can be briefly described as follows:
1. Transaction Creation: Transactions are created on the client side using various tools, CLI, or frontend interfaces.
2. Adding to Mempool: The transaction is added to the mempool, where nodes send an ABCI message - CheckTx to the application layer to check validity and receive the result abci.ResponseCheckTx. In CheckTx, the transaction is decoded from byte format to Tx format, then ValidateBasic() is called on each sdk.Msg within the Tx for preliminary stateless validity checks. If the application has a corresponding anteHandler, it executes its internal logic first, then calls the runTx function, ultimately invoking RunMsgs() to process the content of sdk.Msg. If CheckTx succeeds, the message is added to the local mempool as a candidate for the next block and broadcast via P2P to peer nodes.
3. Inclusion in a Proposed Block: At the start of each round, the proposer creates a block containing the latest transactions, which is finally accepted or voted as an empty block by full nodes responsible for consensus validation.
4. State Changes: DeliverTx is invoked to iterate through transactions in the block, similar to CheckTx, but calling runTx in Deliver mode and executing state changes. The MsgServiceRouter is called to route different messages in the transaction to different modules, then execute each corresponding message in the Msg Server. After message execution, checks are run; if any fail, the state is reverted. During execution, a Gas meter tracks gas usage. If any gas errors occur (e.g., insufficient gas), the consequences are the same as execution failure—the state change is reverted.
5. Committing the Block: When a node receives sufficient validator votes, it commits a new block to add to the blockchain and finalize state transitions in the application layer.
Transaction Lifecycle Diagram in the Cosmos Ecosystem
Below is the specific execution logic of the Cosmos SDK, useful for reference when analyzing vulnerability trigger paths later:
Specific Execution Logic of Key ABCI Interfaces in the Cosmos SDK
Common Vulnerability Classification
Before understanding vulnerability classification, we need a basic categorization of vulnerability severity to better identify high-risk security issues and mitigate potential security risks.
Considering severity and scope of impact, we primarily focus on Critical and Major rated security vulnerabilities, which typically lead to the following risks:
1. Chain halts
2. Fund loss
3. Impact on system state or normal operation
These dangers are often caused by the following types of security vulnerabilities:
1. Denial of Service
2. Incorrect state setting
3. Missing or unreasonable validation
4. Uniqueness issues
5. Consensus algorithm issues
6. Logical flaws in implementation
7. Language-specific issues
Vulnerability Analysis
Due to the modular nature of the Cosmos ecosystem, there are numerous instances of inter-module usage and intra-module calls across various chains. Therefore, situations exist where the vulnerability trigger path differs from the controllable path of variables at the trigger point. When analyzing specific causes of vulnerabilities, we should not only focus on the trigger path but also pay attention to the controllable path of critical vulnerability variables, which helps us better define and classify vulnerability models.
Chain Halts
Chain halts are mostly caused by issues arising during single-block execution. However, throughout Cosmos' historical development, there have also been instances where consensus security vulnerabilities forced the chain to halt voluntarily for repairs. Thus, we include such consensus-affecting vulnerabilities under the category of chain-halting effects and discuss these two types separately.
The first case commonly involves denial-of-service-type vulnerabilities, primarily due to improper crash handling and user-influenced loop boundary traversals. Such vulnerabilities often cause the chain to pause or slow down significantly.
As previously mentioned, the Cosmos SDK and CometBFT serve as critical infrastructure in the Cosmos ecosystem, utilized not only by base chains but also by various application chains implementing their own logic based on this architecture. Consequently, they all adhere to the ABCI interface rules of CometBFT, making the ABCI interface their primary attack surface. Security vulnerabilities capable of causing chain halts typically directly affect block code execution, so their occurrence paths generally trace back to the BeginBlock and EndBlock interfaces.
The second case involves vulnerabilities affecting consensus, usually related to implementations across various chains. Known examples include logical processing validations, time synchronization, and randomness issues. These vulnerabilities fundamentally impact the principle of blockchain decentralization. While they may appear insignificant at first glance, if maliciously exploited, they could pose significant security risks.
First Case
-
Case One: SuperNova Project
Vulnerability Background: Lack of address validation during mint distribution leads to operation failure and fund loss. In the minting module, each token mint depends on staking amounts. However, if the pool doesn't exist or the contract address is incorrectly input, the minting module might encounter unexpected conditions, potentially halting the blockchain. In the reward pool module, the pool contract address isn't validated. If the distribution operation fails, the chain will halt directly.
Vulnerable Location: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/mint/keeper/keeper.go#L175
Vulnerable Code Snippet:
Vulnerability Trigger Path:
BeginBlocker (/x/mint/keeper/abci.go)
Keeper.DistributeMintedCoin
Keeper.distributeLPIncentivePools
PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)
Patch:
https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0
The patch is located in the poolincentive message handling module (x/poolincentive/types/msgs.go), not the mint module.
Address validation was added when processing MsgCreateCandidatePool (i.e., creating a pool) to prevent incorrect addresses at the source.
-
Case Two: Cosmos Interchain Security Project
Project Address: https://github.com/cosmos/interchain-security
Vulnerability Background: Validators can slow down the provider chain by submitting multiple AssignConsumerKey messages within the same block. The AssignConsumerKey function defined in x/ccv/provider/keeper/key_assignment.go allows validators to assign different consumerKeys to approved consumer chains. To do this, an element is added to the consumerAddrsToPrune AddressList. Since this AddressList is iterated over in the EndBlocker in x/ccv/provider/keeper/relay.go, attackers can exploit it to slow down the provider chain. To execute this attack, a malicious actor can create transactions containing multiple AssignConsumerKey messages and send them to the provider chain. The cardinality of the consumerAddrsToPrune AddressList will match the number of AssignConsumerKey messages sent. Consequently, the execution of EndBlocker will consume more time and resources than expected, slowing down or even halting the provider chain.
Vulnerable Location: https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_assignment.go#L378
Vulnerable Code Snippet:
Vulnerability Trigger Path:
msgServer.AssignConsumerKey
Keeper.AssignConsumerKey
AppModule.EndBlock
EndBlockCIS
HandleLeadingVSCMaturedPackets
HandleVSCMaturedPacket
PruneKeyAssignments
-
Case Three: Quicksilver Project - Airdrop Module
Vulnerability Background: BeginBlocker and EndBlocker are optional methods that module developers can implement in their modules. They are triggered at the beginning and end of each block, respectively. Using panics to handle errors in the BeginBlock and EndBlock methods may cause the chain to stop when errors occur. The EndBlocker did not consider whether the module had sufficient tokens when liquidating unclaimed airdrops, potentially triggering a panic and halting the chain.
Vulnerable Location: https://github.com/quicksilver-zone/quicksilver/blob/b4aefa899e024d60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15
Vulnerable Code Snippet:
Vulnerability Trigger Path:
AppModule.EndBlock
Keeper.EndBlocker
Keeper.EndZoneDrop
Patch: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16
Directly removed the panic handling code and replaced it with error logging.
-
Case Four: Cosmos Interchain Security Project
Project Address: https://github.com/cosmos/interchain-security
Vulnerability Background: Attackers can launch a denial-of-service attack by sending multiple tokens to the provider chain's reward address.
During the EndBlocker execution flow of the consumer chain, the SendRewardsToProvider function defined in x/ccv/consumer/keeper/distribution.go retrieves the balance of all tokens in tstProviderAddr and sends them to the provider chain. To achieve this, it must iterate through all tokens found in the reward address and send them individually via IBC to the provider chain. Since anyone can send tokens to the reward address, an attacker can create and send a large number of tokens with different denoms—for example, using a chain with a token factory module—to launch a denial-of-service attack. As a result, the execution of EndBlocker will consume more time and resources than expected, slowing down or even halting the consumer chain.
Vulnerable Location: https://github.com/cosmos/interchain-security/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103
Vulnerable Code Snippet:
Vulnerability Trigger Path:
AppModule.EndBlock
EndBlock
EndBlockRD
SendRewardsToProvider
Second Case
This type of consensus issue may not cause immediate severe harm, but considering the fundamental principles and systems of blockchain as a whole—or examining specific scenarios—its impacts and dangers might not be smaller than those of other conventional vulnerabilities. Moreover, these vulnerabilities share common characteristics.
-
Case One
Vulnerability Background: Cosmos SDK Security Advisory Jackfruit
The non-deterministic behavior of the ValidateBasic method in the x/authz module of the Cosmos SDK can easily lead to consensus halts. The MsgGrant message structure in the x/authz module contains a Grant field, which includes the expiration time granted by user-defined authorization. In the ValidateBasic() validation processing of the Grant structure, its time information is compared with the node's local time instead of the block time. Since local time is non-deterministic, timestamps across different nodes may vary, leading to consensus issues.
Vulnerability Announcement:
https://forum.cosmos.network/t/cosmos-sdk-security-advisory-jackfruit/5319
https://forum.cosmos.network/t/cosmos-sdk-vulnerability-retrospective-security-advisory-jackfruit-october-12-2021/5349
https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-2p6r-37p9-89p2
Vulnerable Code Snippet:
Patch:
https://github.com/cosmos/cosmos-sdk/compare/v0.44.1...v0.44.2
Issues related to timestamps like this not only appear in foundational components like the Cosmos SDK but have also occurred in various application chains.
-
Case Two
Vulnerability Background: SuperNova, nova project
Project Address: https://github.com/Carina-labs/nova/tree/v0.6.3
Using time.Now() returns the operating system's timestamp. Local time is subjective and therefore non-deterministic. Since timestamps across different nodes may differ slightly, the chain might fail to reach consensus. In the ICAControl module, the transaction sending function uses time.Now() to get the timestamp.
Vulnerable Location: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14
Vulnerable Code Snippet:
Patch:
Changed from using local timestamp to using block time.
timeoutTimestamp := time.Now().Add(time.Minute * 10).UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))
timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp))
-
Case Three
Vulnerability Background: BandChain project's oracle module
Project Address: https://github.com/bandprotocol/bandchain/
Comments in the codebase indicate that the oracle module must execute before the staking module to enable punishment measures for validators violating the oracle protocol. The order in the code is: in the SetOrderEndBlockers function, the staking module runs before the oracle module. If the staking module executes before the oracle module, it becomes impossible to punish validator stakes based on validations completed in the oracle module.
Vulnerable Location: https://github.com/LeastAuthority/bandchain/blob/master/chain/app/app.go#L221-L225
Vulnerable Code Snippet:
It's clear that the actual implementation contradicts the comment— the oracle module should come before the staking module.
-
Case Four
Vulnerability Background: Sei Cosmos project's accesscontrol module
Project Address: https://github.com/sei-protocol/sei-cosmos
In multiple instances across various Cosmos codebases, Go map iteration uses the Go language's map type and iterates over it. Since Go's map iteration is non-deterministic, this can lead nodes to reach different states, potentially causing consensus issues and halting the chain. A proper handling approach is to sort the map keys into a slice and iterate over the sorted keys. This issue is quite common and stems from language-specific characteristics in application.
In the BuildDependencyDag implementation in x/accesscontrol/keeper/keeper.go, nodes iterate over anteDepSet. Due to the non-deterministic behavior of map iteration in Go, ValidateAccessOp might encounter two different types of errors, potentially leading to consensus failure.
Vulnerable Location: https://github.com/sei-protocol/sei-cosmos/blob/afe957cab74dd05c213d082d50cae02dd4cb6b73/x/accesscontrol/keeper/keeper.go#L314C9-L314C9
Vulnerable Code Snippet:
From these cases, we can see that vulnerabilities causing passive chain halts tend to be the most harmful. Their root causes can be traced back to directly affecting the execution flow of individual blocks in the blockchain. On the other hand, consensus security vulnerabilities often involve chains halting voluntarily for repair, whose root causes can be traced back to affecting the overall operation flow and state of the blockchain. Unlike the fund-loss-type vulnerabilities we'll discuss next, which aren't judged by their logical path but rather by factors like fund ownership, amount, scope, and methods of impact.
Fund Loss
Fund loss issues commonly arise in logical processing of sdk.Msg and IBC messages. Of course, some vulnerabilities causing chain halts can also result in fund losses, depending on the specific vulnerability. Here, we focus on the former. Additionally, since IBC is a crucial part of the Cosmos ecosystem, some IBC-related vulnerabilities are inevitable. Specific attack surfaces and corresponding vulnerabilities related to IBC will be discussed in the next section.
Fund loss commonly occurs in scenarios involving gas consumption, locked funds that cannot be withdrawn, lost funds during transfers, calculation errors leading to fund loss, and non-unique fund storage IDs.
Here, we take the SuperNova project as an example to analyze three related vulnerabilities.
-
Vulnerability Background: SuperNova Project
Project Address: https://github.com/Carina-labs/nova
If a zone's decimal precision exceeds 18, funds may become locked. In the project's code, there is no upper limit on a zone's decimal precision, allowing it to exceed 18 digits. In ClaimSnMesssage, when users wish to claim their share tokens, ClaimShareToken is used. However, if the zone's decimal precision exceeds 18, the conversion will fail, preventing asset withdrawal from the system. Thus, controlling the zone's decimal precision can directly trigger transaction crashes and failures.
Vulnerable Location: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167
Vulnerable Code Snippet:
Vulnerability Trigger Path:
msgServer.ClaimSnAsset
Keeper.ClaimShareToken
Keeper.ConvertWAssetToSnAssetDecimal
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
CertiK
