Cosmos EVM Security Update: Patches Released and Next Steps for Steem Virtual Machine (SVM)
Two days ago, I published a security alert regarding an ongoing incident in the Cosmos EVM module, the open-source stack that powers EVM compatibility on the Steem Virtual Machine (SVM). You can read that initial analysis here: Cosmos EVM Security Alert: What It Means for Steem Virtual Machine (SVM).
At the time of that post, the only official guidance from Cosmos Labs was to halt operations if in direct contact with their team and await a post-mortem. Today, August 26, 2026, that guidance has changed. Cosmos Labs has published a community update providing concrete remediation steps.
The Official Cosmos Labs Update
From the official update released today:
Update for the community on the current security incident. Many affected chains have now patched. We continue to provide mitigation information to affected chains. Chains that use a Cosmos EVM version less than v0.6.2 or v0.7.2 are recommended to immediately halt the blockchain and upgrade it to include the patches in those releases. Please contact security@cosmoslabs.io if you use Cosmos EVM and have not yet provided your security team contact details.
Operational takeaways:
- The incident is still being treated as active.
- A public patch path now exists: v0.6.2 for the 0.6 line and v0.7.2 for the 0.7 line.
- Any chain running versions below these tags is instructed to halt and upgrade.
- Teams without a registered security contact must email Cosmos Labs immediately.
It is important to clarify the versioning: the instruction is to upgrade to v0.6.2 or v0.7.2. Versions below those tags are the ones that must halt. A full technical post-mortem has not yet been published.
Recap of the Incident
This current incident is distinct from the January 2026 SagaEVM and ICS20 precompile issue (ASA-2026-002), which involved a different code path and was patched in v0.6.0. The August vulnerability cluster centers around staking precompiles, vesting accounts, and EVM balance write-back mechanisms.
Public Timeline:
- August 19: Cosmos Labs published v0.6.2 and v0.7.2, tagging both as important security fixes and state-breaking updates.
- August 20: MANTRA halted following suspicious activity in project-managed wallets.
- August 22: MANTRA resumed on patched software after approximately 30 hours of downtime. The team reported that user, exchange, and partner funds were not exploited.
- August 22: TAC and KiiChain were affected and subsequently halted.
- August 24: Cosmos Labs issued the initial public halt advisory.
- August 25: Cosmos Labs specified the patched versions (v0.6.2 and v0.7.2).
- August 26: Cosmos Labs confirmed many affected chains have patched and reiterated the upgrade instructions.
Reported Impact on Other Networks:
- KiiChain: 148,326,583.15 KII drained across 18 repeated attacks before halting at block 9,355,723. A portion of the funds was bridged toward the BNB Smart Chain.
- TAC: Experienced large internal token movements. The team stated the total supply was not inflated and other assets remained intact.
- MANTRA: Affected internal wallets; resumed after a coordinated network upgrade.
Technical Details of the Vulnerability
Cosmos Labs has not yet released a formal security advisory detailing the exact mechanics of the August flaw. However, release notes and chain incident reports provide significant insight.
The v0.6.2 and v0.7.2 changelogs highlight state-handling issues, including:
- Contract creation improperly bumping the sender nonce.
- SetAccount persisting nonce and balance concurrently.
- The EVM commit path failing to correctly write a module account's balance.
KiiChain's incident report details a specific exploit vector involving:
- An underflow in the staking precompile when a post-delegation balance is written back into the EVM state.
- Additional defects tied to vesting accounts.
In this scenario, an ordinary wallet cannot simply delegate more tokens than it owns. The exploit requires converting an address into a vesting account, deploying a contract onto it, and then delegating a fractional amount (e.g., 1 wei) more than the spendable balance, causing the mirrored EVM balance to underflow. Total supply was not minted from nothing; the drains were strictly capped by the victim account balances.
KiiChain has also claimed that the public upstream patch only addresses the underflow, leaving two of the three defects unfixed for chains that still have vesting accounts enabled. Cosmos Labs has not publicly confirmed or denied this claim. Until an official post-mortem is released, this remains an unresolved risk for any chain utilizing vesting and staking precompiles.
Implications for Steem Virtual Machine (SVM)
The recent Cosmos Labs update does not explicitly name SVM, and there are currently no public reports indicating that SVM has been exploited or forced offline.
However, SVM is built on the Cosmos SDK, CometBFT, and the official Cosmos EVM module. This places SVM in the exact class of networks that Cosmos Labs is advising to verify their software version, halt if running vulnerable code, and execute a coordinated, state-breaking upgrade.
Because SVM is in an earlier testing phase compared to mainnet chains like MANTRA or KiiChain, the practical risk depends on four critical factors that the SVM core team must clarify:
- Which specific Cosmos EVM tag is SVM currently running?
- Are staking precompiles enabled on the network?
- Are vesting accounts enabled?
- Has a security contact been registered with Cosmos Labs?
If SVM is already running v0.6.2 or higher (or v0.7.2 or higher), the immediate directive to halt no longer applies. The remaining tasks are verification, monitoring, and assessing whether additional mitigations are required for vesting-related vulnerabilities. If SVM is running an older version, the instruction is clear: halt the testnet, upgrade the binaries, and coordinate the restart across all validators.
Recommended Actions
For Validators and Node Operators:
- Verify the exact cosmos/evm version in your current SVM binary.
- If the version is below v0.6.2 or v0.7.2, prepare to halt your node and participate in a coordinated upgrade. These patches are state-breaking; running mixed binaries will result in a network fork.
- Do not resume operations using unofficial or unverified builds.
- Monitor official SVM communication channels exclusively for restart instructions.
For SVM Developers and Core Team:
- Publish a concise status update detailing the current version number, enabled precompiles, vesting status, and confirmation of contact with Cosmos Labs.
- If vesting accounts are enabled, do not assume the public patch is a complete fix. Review KiiChain's claims and consider implementing supplementary guards, such as blocking vesting-account creation in the ante handler.
- Maintain active communication with security@cosmoslabs.io to receive private mitigation guidance.
For Users and Builders:
- There is no public evidence of an SVM exploit at this time.
- Until the core team confirms the network is running the patched version, avoid executing large or irreversible EVM-side transactions on the testnet.
- Remember that the January ICS20 bug and the August vesting/staking cluster are entirely separate vulnerabilities. Being patched for one does not guarantee protection against the other.
Outstanding Questions
Cosmos Labs has yet to release:
- A formal CVE or ASA designation for the August vulnerability cluster.
- A comprehensive list of all affected chains.
- An aggregate total-loss figure.
- A detailed technical post-mortem.
- A definitive answer regarding KiiChain's claim about unfixed vesting defects.
Until this report is published, the statement that "many chains have patched" simply indicates the adoption of the known public fix, not the closure of the incident.
Conclusion
The August 24 advisory instructed networks to stop and wait. The August 26 update shifts the directive: many chains have patched, and those below v0.6.2 or v0.7.2 must halt and upgrade immediately.
For SVM, the focus is no longer on tracking rumors, but on strict version verification. The network shares the same underlying module and therefore inherits the same class of risk. While no public exploit has occurred on SVM, network safety now hinges entirely on the exact binary in use, the status of enabled precompiles, and the configuration of vesting accounts.
I will provide another update once Cosmos Labs publishes the official post-mortem or the SVM team releases a definitive status report. Coordinated upgrades and transparent communication are how modular blockchain stacks survive shared-module vulnerabilities.