Full Report
Blockchains are effectively code that runs on a bunch of different computers. Naturally, it's important that all of these computers have the same result. If the output is different between computers, then consensus can fail. If consensus fails, then the entire blockchain will likely stop working. This vulnerability affects the Cosmos SDK IBC Go library. When deserailizing a cross-chain acknowledgment, the JSON can be unmarshalled differently in some cases. Why is JSON non-deterministic here? Probably because it didn't NEED to be deterministic in the past. Even an extra space can cause issues here. Here's the PR for the fix. It simply unmarshals and remarshals the ACK packet data then compares the values. If some weird non-deterministic behavior was happening here then this would fail.
Analysis Summary
# Vulnerability: Non-deterministic JSON Unmarshalling of IBC Acknowledgement
## CVE Details
- **CVE ID:** No known CVE assigned (Referenced as ASA-2025-004 / GHSA-jg6f-48ff-5xrw)
- **CVSS Score:** Critical (Numerical score not finalized, but categorized as Critical by vendor)
- **CWE:** CWE-502 (Deserialization of Untrusted Data)
## Affected Systems
- **Products:** Cosmos SDK `ibc-go` library
- **Versions:**
- v7.x (specifically versions prior to v7.9.2)
- v8.x (specifically versions prior to v8.6.1)
- Earlier versions of IBC-Go may also be affected.
- **Configurations:** Systems utilizing IBC (Inter-Blockchain Communication) protocol; specifically those with validators, full nodes, or custom IBC Middleware.
## Vulnerability Description
A flaw exists in how IBC-Go handles the deserialization (unmarshalling) of cross-chain acknowledgement packets. The process is non-deterministic, meaning that the same input can result in different internal representations or outputs across different nodes (e.g., due to white space differences or JSON field ordering). In a blockchain context, if nodes produce different outputs from the same input, they fail to reach consensus, leading to an immediate chain halt.
## Exploitation
- **Status:** PoC availability not explicitly stated, but the attack involves opening an IBC channel and sending a crafted packet.
- **Complexity:** Medium (Requires ability to open an IBC channel).
- **Attack Vector:** Network (Remote via IBC protocol).
## Impact
- **Confidentiality:** None
- **Integrity:** Medium (Potential for inconsistent state across nodes).
- **Availability:** Critical (Total chain halt).
## Remediation
### Patches
The following versions address the issue by unmarshalling and then re-marshalling the ACK packet data to ensure consistency:
- **v7.9.2**
- **v8.6.1**
*Note: Chains using specific "ack-serializing middleware" may require a coordinated upgrade as the patch could be state-breaking for those specific configurations.*
### Workarounds
- **Permissioned Channel Opening:** Restrict the ability to open IBC channels to trusted actors only. This prevents untrusted users from introducing the problematic packets to the chain.
## Detection
- **Indicators of Compromise:** Non-deterministic consensus errors appearing in validator logs; sudden chain halts shortly after new IBC channels are opened or specific acknowledgements are processed.
- **Detection Methods:** Monitor for `consensus failure` or `app hash mismatch` errors across the validator set.
## References
- **Vendor Advisory:** [https://github.com/cosmos/ibc-go/security/advisories/GHSA-jg6f-48ff-5xrw]
- **Release Information:** [https://github.com/cosmos/ibc-go/releases/tag/v8.6.1]
- **Bug Bounty Program:** [https://hackerone.com/cosmos]