Evmos vulnerable to unauthorized account creation with vesting module

Exploitation

No confirmed exploitation recorded. Patch Next marks exploitation only from CISA KEV.

CVSS

not scored

EPSS

No dated EPSS signal available.

As published by the source; long descriptions are shortened.

Impact What kind of vulnerability is it? Who is impacted? Using the vesting module, a malicious attacker can create a new vesting account at a given address, before a contract is created on that address. Addresses of smart contracts deployed to the EVM are deterministic. Therefore, it would be possible for an attacker to front-run a contract creation and create a vesting account at that address. When an address has been initialized without any contract code deployed to it, it will not be possible to upload any afterwards. In the described attack, this would mean that a malicious actor could prevent smart contracts from being deployed correctly. In order to remediate this, an alternative user flow is being implemented for the vesting module: - only the account receiving the vesting funds will be able to create such an account by calling the CreateClawbackVestingAccount method and defining a funder address - vesting and lockup periods can then be created by that funder address using…

Published by the source

17 Apr 2024, 17:37 UTC

Last modified by the source

10 Jun 2024, 20:09 UTC

Source last checked

26 Oct 2026, 15:04 UTC

1. Revision 1 · created · 26 Oct 2026

   Published from ghsa record GHSA-m99c-q26r-m7m7

Preview the exact text before you copy it. Commands are read-only suggestions; review them before running anything.

# Patch Next advisory brief: GHSA-m99c-q26r-m7m7

Advisory: Evmos vulnerable to unauthorized account creation with vesting module
IDs: GHSA-m99c-q26r-m7m7
Record: https://patchnext.com/advisories/ghsa-m99c-q26r-m7m7 (revision 1, source checked 26 Oct 2026, 15:04 UTC)
Inventory: none attached. This brief comes from a public page and does not say whether any deployment is affected.
Severity: Unrated
Exploitation: no confirmed exploitation recorded. Patch Next confirms exploitation only from CISA KEV.
Vendor response: Vendor response not established. A vendor fix does not mean a deployment is fixed.

## Affected components
- Go github.com/evmos/evmos/v13: affected <= 13.0.2
- Go github.com/evmos/evmos/v13/x/vesting: affected <= 13.0.2

## Suggested inspection (read-only)
- Go github.com/evmos/evmos/v13: check the installed version with your package manager.
- Go github.com/evmos/evmos/v13/x/vesting: check the installed version with your package manager.

## Supported action
No complete vendor fix is recorded. Follow the primary source's mitigation guidance and check this record again before closing anything.

## Required regression checks
- Run the test suite and a production build.
- Exercise the features that depend on github.com/evmos/evmos/v13, github.com/evmos/evmos/v13/x/vesting.
- Repeat the inspection and confirm that only fixed versions remain installed.

## Rollback considerations
- Keep the previous lockfile and deployment artifact. Rolling back reinstates the vulnerable version, so apply any documented mitigation while you fix forward.

## Unresolved questions
- Which deployments run an affected version?
- Exploitation status can change. Check again before lowering the priority.
- Mark the work resolved only after the fixed version is verified in production.

## Sources
- Verified: https://github.com/advisories/GHSA-m99c-q26r-m7m7 (GitHub-reviewed advisory GHSA-m99c-q26r-m7m7 lists affected ranges: Go github.com/evmos/evmos/v13/x/vesting >=0 =0 <=13.0.2)

Commands are suggestions: review each one before running it.