How severe is GHSA-v6rw-hhgg-wc4x?

GHSA-v6rw-hhgg-wc4x has a CVSS score of 9.1/10, rated CRITICAL. Immediate patching is strongly recommended.

Which packages are affected by GHSA-v6rw-hhgg-wc4x?

GHSA-v6rw-hhgg-wc4x affects the following packages: github.com/evmos/evmos/v11 (Go). Ecosystems affected: Go.

How do I fix GHSA-v6rw-hhgg-wc4x?

Update github.com/evmos/evmos/v11 to 12.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v6rw-hhgg-wc4x is resolved across your whole dependency graph.

How do I detect GHSA-v6rw-hhgg-wc4x in my Go dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/evmos/evmos/v11. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-v6rw-hhgg-wc4x if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-v6rw-hhgg-wc4x?

O3 pinpoints whether GHSA-v6rw-hhgg-wc4x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-v6rw-hhgg-wc4x actively exploited in the wild?

No public exploit code has been indexed for GHSA-v6rw-hhgg-wc4x yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-v6rw-hhgg-wc4x published, and has it been updated?

GHSA-v6rw-hhgg-wc4x was published on April 17, 2024 and was last updated on June 5, 2024. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐹 Go

GHSA-v6rw-hhgg-wc4x

CRITICAL

Evmos vulnerable to DOS and transaction fee expropiation through Authz exploit

Also known asGO-2024-2732

Published

Apr 17, 2024

Updated

Jun 5, 2024

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🐹github.com/evmos/evmos/v11

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?

An attacker can use this bug to bypass the block gas limit and gas payment completely to perform a full Denial-of-Service against the chain.

Disclosure

Evmos versions below v11.0.1 do not check for MsgEthereumTx messages that are nested under other messages. This allows a malicious actor to perform EVM transactions that do not meet the checks performed under newEthAnteHandler. This opens the possibility for the DOS of validators and consequently halt the chain through an infinite EVM execution.

Additional details

The attack scenario is as follows:

The attacker deploys a simple smart contract with an infinite loop to the chain.
The attacker calls the smart contract using an embedded transaction with an extremely high gas value (uint64 max or similar).
Once the transaction is included in a block, nodes will try to execute the EVM transaction with almost infinite gas and get stuck. This stops new block creation and effectively halts the chain, requiring a manual restart of all nodes.

Users Impacted

All Evmos users are impacted by this vulnerability as it has the potential to halt the chain. Users' funds and chain state are safe but when under attack, the chain could be deemed unusable.

Patches

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

The vulnerability has been patched on Evmos versions ≥v12.0.0.

Details

As a temporary workaround, the fix blocks MsgEthereumTxs messages from being sent under the authz module's MsgExec message. It also covers the scenario in which MsgEthereumTx are deeply nested by:

Doing a recursive check over the nested messages of MsgExec
Limiting the amount of possible nested messages (inner messages) in MsgExec

This is done by adding an additional AnteHandler decorator (AuthzLimiterDecorator) for Cosmos and EIP-712 transactions.

This is a state machine-breaking change as it restricts previously allowed messages and thus requires a hard-fork upgrade.

References

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

For more information

If you have any questions or comments about this advisory:

Reach out to the Core Team in Discord
Open a discussion in evmos/evmos
Email us at [email protected] for security questions
For Press, email us at [email protected].

Affected Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐹Go	`github.com/evmos/evmos/v11`	all versions	12.0.0

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/evmos/evmos/v11. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update github.com/evmos/evmos/v11 to 12.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-v6rw-hhgg-wc4x is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-v6rw-hhgg-wc4x is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-v6rw-hhgg-wc4x. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Impact _What kind of vulnerability is it? Who is impacted?_ An attacker can use this bug to bypass the block gas limit and gas payment completely to perform a full Denial-of-Service against the chain. ## Disclosure Evmos versions below `v11.0.1` do not check for `MsgEthereumTx` messages that are nested under other messages. This allows a malicious actor to perform EVM transactions that do not meet the checks performed under `newEthAnteHandler`. This opens the possibility for the DOS of validators and consequently halt the chain through an infinite EVM execution. ### Additional details

O3 Security · Impact-Aware SCA

Is GHSA-v6rw-hhgg-wc4x in your dependencies?

O3 detects GHSA-v6rw-hhgg-wc4x across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works