Summary
ASA-2024-003: Missing BlockedAddressed Validation in Vesting Module
ASA-2024-003: Missing BlockedAddressed Validation in Vesting Module
Component: Cosmos SDK
Criticality: Low
Affected Versions: Cosmos SDK versions <= 0.50.3; <= 0.47.8
Affected Users: Chain developers, Validator and Node operators
Impact: Denial of Service
Description
A vulnerability was identified in the x/auth/vesting module, which can allow a user to create a periodic vesting account on a blocked address, for example a non-initialized module account. Additional validation was added to prevent creation of a periodic vesting account in this scenario.
If this case is triggered, there is the potential for a chain halt if the uninitialized account in question is called by GetModuleAccount in Begin/EndBlock of a module. This combination of an uninitialized blocked module account is not common.
Next Steps for Impacted Parties
If your chain has uninitialized blocked module accounts, it is recommended to proactively initialize them, as they are often initialized during a chain migration or during init genesis.
If you are a chain developer on an affected version of the Cosmos SDK, it is advised to update to the latest available version of the Cosmos SDK for your project. Once a patched version is available, it is recommended that network operators upgrade.
A Github Security Advisory for this issue is available in the Cosmos-SDK repository. For more information about Cosmos SDK, see https://docs.cosmos.network/.
This issue was found by Dongsam who reported it to the Cosmos Bug Bounty Program on HackerOne on January 30, 2024. If you believe you have found a bug in the Interchain Stack or would like to contribute to the program by reporting a bug, please see https://hackerone.com/cosmos.
Addendum
A variant trigger of this issue via the x/authz and x/feegrant modules was discovered by Richie who reported it to the Cosmos Bug Bounty Program on HackerOne on April 6th, 2024, and was subsequently fixed by the Cosmos SDK team on April 21st, 2024. The guidance for mitigating this additional variant is the same as the parent advisory, so it is suggested that all chains proactively initialize module accounts if they have not already done so.
Impact
The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths. Typical impact: varies by context: data corruption, logic bypass, or denial of service.
GHSA-4J93-FM92-RP4M has a CVSS score of 6.5 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.50.4, 0.47.9); upgrading removes the vulnerable code path.
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
github.com/cosmos/cosmos-sdk to 0.50.4 or later; github.com/cosmos/cosmos-sdk to 0.47.9 or later
Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.
Frequently Asked Questions
- What is GHSA-4J93-FM92-RP4M? GHSA-4J93-FM92-RP4M is a medium-severity improper input validation vulnerability in github.com/cosmos/cosmos-sdk (go), affecting versions >= 0.50.0, <= 0.50.3. It is fixed in 0.50.4, 0.47.9. The application does not adequately validate input before processing it, allowing unexpected values to reach sensitive code paths.
- How severe is GHSA-4J93-FM92-RP4M? GHSA-4J93-FM92-RP4M has a CVSS score of 6.5 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of github.com/cosmos/cosmos-sdk are affected by GHSA-4J93-FM92-RP4M? github.com/cosmos/cosmos-sdk (go) versions >= 0.50.0, <= 0.50.3 is affected.
- Is there a fix for GHSA-4J93-FM92-RP4M? Yes. GHSA-4J93-FM92-RP4M is fixed in 0.50.4, 0.47.9. Upgrade to this version or later.
- Is GHSA-4J93-FM92-RP4M exploitable, and should I be worried? Whether GHSA-4J93-FM92-RP4M 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-4J93-FM92-RP4M 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-4J93-FM92-RP4M?
- Upgrade
github.com/cosmos/cosmos-sdkto 0.50.4 or later - Upgrade
github.com/cosmos/cosmos-sdkto 0.47.9 or later
- Upgrade