GHSA-m99c-q26r-m7m7 json
Evmos vulnerable to unauthorized account creation with vesting module
published 2y ago modified 8mo ago also GO-2024-2731
- cvss
- —
- not scored
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no score, EPSS covers CVEs only
- public exploits
- 0
- none known
Summary
### 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 `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?_
Is GHSA-m99c-q26r-m7m7 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerAffected packages
| ecosystem | package | affected | fixed in |
|---|---|---|---|
| go | github.com/evmos/evmos/v13/x/vesting | <=13.0.2 |
no fix listed |
| go | github.com/evmos/evmos/v13 | <=13.0.2 all versions |
no fix listed |
| go | github.com/evmos/evmos | all versions |
no fix listed |
| go | github.com/evmos/evmos/v2 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v3 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v4 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v5 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v6 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v7 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v8 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v9 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v10 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v11 | all versions |
no fix listed |
| go | github.com/evmos/evmos/v12 | all versions |
no fix listed |
References
Sources
- GitHub Advisory GHSA-m99c-q26r-m7m7
- OSV GO-2024-2731
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.