Summary
Interchain Security: The signers of ICS messages do not need to match the provider address
Context
ICS has the following four messages that enable validators on the provider chain to perform different actions:
MsgOptIn-- adds a validator to the consumer chain’s active setMsgOptOut-- removes a validator from the consumer chain’s active setMsgAssignConsumerKey-- changes the consensus key used for a validator’s operations on a consumer chainMsgSetConsumerCommissionRate-- sets a validator’s consumer-specific commission rate
Normally, only the respective validators are allowed to perform these actions.
Issue
The upgrade to SDK 0.50, introduced a signer field to these messages. This field is used to authenticate the user sending the message to the system. However, there was no validation on the ICS side to check if the signer matches the provider address.
As a result, any user could opt-in, opt-out, change the commission rate, or change what public key a validator uses on a consumer chain.
For more context, check out the code:
- proto files https://github.com/cosmos/interchain-security/blob/v5.1.1/proto/interchain_security/ccv/provider/v1/tx.proto#L52
- message validation https://github.com/cosmos/interchain-security/blob/v5.1.1/x/ccv/provider/types/msg.go#L106
- message handling https://github.com/cosmos/interchain-security/blob/v5.1.1/x/ccv/provider/keeper/msg_server.go#L52
Severity assessment
The severity assessment is based on this framework.
Potential impact: Catastrophic
- By changing consumer keys for 1/3+ of a consumer chain's validator set, any user could cause a consumer chain to halt. Given that the consumer is down, the provider will jail provider validators for consumer downtime, so this exploit would not have impacted the provider directly. Consumer chain halts would need to be addressed by a provider-side patch.
- By changing consumer keys on a consumer node, double signing, and submitting evidence back to the provider, any user could tombstone any provider validator. This would cause the provider's active set to change. At scale, this exploit could be applied to all active provider validators and a well-funded attacker could then run their own nodes and take over consensus on the provider and on consumer chains.
Likelihood: Rare
- The bug was discovered internally. There is no evidence that any external party has identified this vulnerability.
- The bug has been live for two weeks with no issues.
- All four message types are ones that only validators use, and rarely use in daily operations.
- In the Cosmos Hub’s recent history (May - Aug), there has been only one instance of any of these message types, which was performed in accordance with chain rules.
- The catastrophic exploits (such as tombstoning the entire validator set of the provider) are also extremely complex. They involve several operations that are not well-understood by many people, and the entire exploit must occur quickly and at-scale to avoid other node operators responding defensively.
Impact
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-7Q74-G774-7X3G? GHSA-7Q74-G774-7X3G is a high-severity security vulnerability in github.com/cosmos/interchain-security/v5 (go), affecting versions >= 5.1.0, < 5.2.0. It is fixed in 5.2.0.
- Which packages are affected by GHSA-7Q74-G774-7X3G?
github.com/cosmos/interchain-security/v5(go) (versions >= 5.1.0, < 5.2.0)github.com/cosmos/interchain-security(go) (versions > 0)github.com/cosmos/interchain-security/v2(go) (versions > 0)github.com/cosmos/interchain-security/v3(go) (versions > 0)github.com/cosmos/interchain-security/v4(go) (versions > 0)
- Is there a fix for GHSA-7Q74-G774-7X3G? Yes. GHSA-7Q74-G774-7X3G is fixed in 5.2.0. Upgrade to this version or later.
- Is GHSA-7Q74-G774-7X3G exploitable, and should I be worried? Whether GHSA-7Q74-G774-7X3G is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-7Q74-G774-7X3G is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-7Q74-G774-7X3G? Upgrade
github.com/cosmos/interchain-security/v5to 5.2.0 or later.