GHSA-m99c-q26r-m7m7
Evmos vulnerable to unauthorized account creation with vesting module
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
CreateClawbackVestingAccountmethod and defining a funder address - vesting and lockup periods can then be created by that funder address using
FundClawbackAccount
Patches
Has the problem been patched? What versions should users upgrade to?
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
References
Are there any links users can visit to find out more?
What each source reports
GitHub AdvisoriesNo score
Evmos vulnerable to unauthorized account creation with vesting module
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
CreateClawbackVestingAccountmethod and defining a funder address - vesting and lockup periods can then be created by that funder address using
FundClawbackAccount
Patches
Has the problem been patched? What versions should users upgrade to?
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
References
Are there any links users can visit to find out more?
- Record
GHSA-m99c-q26r-m7m7- Updated
- 2026-11-02
OSVNo score
Evmos vulnerable to unauthorized account creation with vesting module
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
CreateClawbackVestingAccountmethod and defining a funder address - vesting and lockup periods can then be created by that funder address using
FundClawbackAccount
Patches
Has the problem been patched? What versions should users upgrade to?
Workarounds
Is there a way for users to fix or remediate the vulnerability without upgrading?
References
Are there any links users can visit to find out more?
- Record
GHSA-m99c-q26r-m7m7- Updated
- 2026-11-02
OSVGO-2024-2731No score
Evmos vulnerable to unauthorized account creation with vesting module in github.com/evmos/evmos
Evmos vulnerable to unauthorized account creation with vesting module in github.com/evmos/evmos
- Record
GO-2024-2731- Updated
- 2026-11-02
Affected packages
| Package | Affected | Fixed |
|---|---|---|
github.com/evmos/evmos/v13/x/vestingGo | through 13.0.2 | None known |
github.com/evmos/evmos/v13Go | through 13.0.2 | None known |
github.com/evmos/evmosGo | All versions | None known |
github.com/evmos/evmos/v2Go | All versions | None known |
github.com/evmos/evmos/v3Go | All versions | None known |
github.com/evmos/evmos/v4Go | All versions | None known |
github.com/evmos/evmos/v5Go | All versions | None known |
github.com/evmos/evmos/v6Go | All versions | None known |
github.com/evmos/evmos/v7Go | All versions | None known |
github.com/evmos/evmos/v8Go | All versions | None known |
Show 5 moreShow less
| Package | Affected | Fixed |
|---|---|---|
github.com/evmos/evmos/v9Go | All versions | None known |
github.com/evmos/evmos/v10Go | All versions | None known |
github.com/evmos/evmos/v11Go | All versions | None known |
github.com/evmos/evmos/v12Go | All versions | None known |
github.com/evmos/evmos/v13Go | All versions | None known |
History
| Recorded | Changed | Sources |
|---|---|---|
| first indexed | GitHub Advisories, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
GHSA-m99c-q26r-m7m7 is a vulnerability with no CVSS score yet in github.com/evmos/evmos/v13/x/vesting, published April 17, 2024. No source lists public exploit code. No source names a fixed version.