GHSA-MJFQ-3QR2-6G84

GHSA-MJFQ-3QR2-6G84 is a high-severity code injection vulnerability in github.com/cosmos/evm (go), affecting versions = 0.1.0. No fixed version is listed yet.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

Cosmos EVM Allows Partial Precompile State Writes

In x/evm/statedb.go:

Add the following function:

func (s *StateDB) RevertMultiStore(cms storetypes.CacheMultiStore, events sdk.Events) {
	s.cacheCtx = s.cacheCtx.WithMultiStore(cms)
	s.writeCache = func() {
		// rollback the events to the ones
		// on the snapshot
		s.ctx.EventManager().EmitEvents(events)
		cms.Write()
	}
}

In x/evm/statedb/journal.go:

Replace the Revert function with the following:

func (pc precompileCallChange) Revert(s *StateDB) {
	// rollback multi store from cache ctx to the previous
	// state stored in the snapshot
	s.RevertMultiStore(pc.multiStore, pc.events)
}

In precompiles/common/precompile.go:

Change the function signature in HandleGasError to:

func HandleGasError(ctx sdk.Context, contract *vm.Contract, initialGas storetypes.Gas, err *error, stateDB *statedb.StateDB, snapshot snapshot) func() {
...
}

In the HandleGasError function, add the following line in the switch statement in the case storetypes.ErrorOutOfGas: case:

stateDB.RevertMultiStore(snapshot.MultiStore, snapshot.Events)

Add the following function:

// RunAtomic is used within the Run function of each Precompile implementation.
// It handles rolling back to the provided snapshot if an error is returned from the core precompile logic.
// Note: This is only required for stateful precompiles.
func (p Precompile) RunAtomic(s snapshot, stateDB *statedb.StateDB, fn func() ([]byte, error)) ([]byte, error) {
	bz, err := fn()
	if err != nil {
		// revert to snapshot on error
		stateDB.RevertMultiStore(s.MultiStore, s.Events)
	}
	return bz, err
}

All Precompiles:

Finally, in each precompile, locate the Run function, and wrap each switch statement and return values into p.RunAtomic. For example:

// Run executes the precompiled contract IBC transfer methods defined in the ABI.
func (p Precompile) Run(evm *vm.EVM, contract *vm.Contract, readOnly bool) (bz []byte, err error) {
	ctx, stateDB, snapshot, method, initialGas, args, err := p.RunSetup(evm, contract, readOnly, p.IsTransaction)
	if err != nil {
		return nil, err
	}

	// This handles any out of gas errors that may occur during the execution of a precompile tx or query.
	// It avoids panics and returns the out of gas error so the EVM can continue gracefully.
	defer cmn.HandleGasError(ctx, contract, initialGas, &err, stateDB, snapshot)()

        // === WRAP HERE ===
	return p.RunAtomic(snapshot, stateDB, func() ([]byte, error) {
		switch method.Name {
		// TODO Approval transactions => need cosmos-sdk v0.46 & ibc-go v6.2.0
		// Authorization Methods:
		case exampleCase:
			bz, err = p.example(ctx, evm.Origin, stateDB, method, args)
		default:
			return nil, fmt.Errorf(cmn.ErrUnknownMethod, method.Name)
		}

		if err != nil {
			return nil, err
		}

		cost := ctx.GasMeter().GasConsumed() - initialGas

		if !contract.UseGas(cost) {
			return nil, vm.ErrOutOfGas
		}

		if err := p.AddJournalEntries(stateDB, snapshot); err != nil {
			return nil, err
		}

		return bz, nil
	})
}

Workarounds

There are no workarounds for chains that make use of precompiles. A coordinated upgrade is necessary to patch the issue.

Testing

A test was introduced in the distribution precompile to ensure that partial state writes no longer occur when a lower gas amount is set.

Impact

Setting lower EVM call gas allows users to partially execute precompiles and error at specific points in the precompile code without reverting the partially written state.

If executed on the distribution precompile when claiming funds, it could cause funds to be transferred to a user without resetting the claimable rewards to 0. The vulnerability could also be used to cause indeterministic execution by failing at other points in the code, halting validators.

Any evmOS or Cosmos EVM chain using precompiles is affected.

Untrusted input is evaluated as executable code within the application's runtime environment. Typical impact: arbitrary code execution within the application's privilege context.

Affected versions

github.com/cosmos/evm (= 0.1.0)

Security releases

Not available

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

The vulnerability was patched by wrapping each precompile execution into an atomic function that reverts any partially committed state on error.

For chains using a different file structure, you must manually apply the diff:

Frequently Asked Questions

  1. What is GHSA-MJFQ-3QR2-6G84? GHSA-MJFQ-3QR2-6G84 is a high-severity code injection vulnerability in github.com/cosmos/evm (go), affecting versions = 0.1.0. No fixed version is listed yet. Untrusted input is evaluated as executable code within the application's runtime environment.
  2. Which versions of github.com/cosmos/evm are affected by GHSA-MJFQ-3QR2-6G84? github.com/cosmos/evm (go) versions = 0.1.0 is affected.
  3. Is there a fix for GHSA-MJFQ-3QR2-6G84? No fixed version is listed for GHSA-MJFQ-3QR2-6G84 yet. Monitor the advisory for updates and apply mitigations in the interim.
  4. Is GHSA-MJFQ-3QR2-6G84 exploitable, and should I be worried? Whether GHSA-MJFQ-3QR2-6G84 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  5. What actually determines whether GHSA-MJFQ-3QR2-6G84 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  6. How do I fix GHSA-MJFQ-3QR2-6G84? No fixed version is listed yet. In the interim: Never evaluate untrusted input as code. Use sandboxed evaluation environments if dynamic execution is required.

Other vulnerabilities in github.com/cosmos/evm

Stop the waste.
Protect your environment with Kodem.