Improved Security Processes for the Age of AI
Security is at the heart of digital ledger software, and this is nowhere truer than in the Cosmos stack. Cosmos Labs has a long history of security operations and practices that have evolved as the Cosmos stack has expanded and matured. Currently, AI is posing one of the largest upheavals in the software world, as frontier models are able to identify vulnerabilities that have been long undetected, especially in open source software.
For example, in June 2026, an autonomous agent read about 1.5 million lines of FFmpeg's C code for roughly $1,000 and reported 21 zero-days. The oldest had been in the codebase since 2003. This is just one of many examples throughout the broader software ecosystem outside of blockchain.
In light of these changes and in response to recent security incidents, we are undergoing a holistic overhaul of our security practices and are evolving to meet this moment. We previously shared some of our commitments to improvements in a recent security post-mortem, and this blog is the first step in delivering on them. These announcements are a step in an ongoing effort to strengthen security across the Cosmos technology stack, with continued improvements to our practices remaining a cornerstone of our stack.
Policy Changes
Patching Policy
We are overhauling the patching policy for vulnerabilities in the Cosmos stack, with an emphasis on improving predictability and transparency for users. We have gathered and listened to ecosystem and client feedback in shaping the direction of our security program and the changes outlined below. We have heard that ad-hoc processes put strain on organizations, that more transparency is needed for teams to make informed decisions for critical software, and that our program must change and adapt with this shifting landscape.
- The policy applies to the components in our bug bounty scope, including the Cosmos SDK, CometBFT, IBC, Cosmos EVM and the CosmWasm repositories.
- Every severity is patched privately. There is no longer a public patching path for low, medium, or high severity vulnerabilities.
- Patches are published on a monthly cycle, at the start of each month.
- We publish a full GHSA for every vulnerability, whatever its severity.
- Teams that pass KYC receive the patch and the full details before publication, so they can remediate privately. More on KYC below.
- A vulnerability under active exploitation leaves the cycle and is handled immediately as an incident.
Patching will now be a private process. Doing everything in private maximizes security, by eliminating the risk of public AI scanning and any other disclosure while a fix is being rolled out. It also eliminates the chance that a bug can be publicly disclosed as a lower severity vulnerability, but be chained with another known or unknown vulnerability for a higher severity impact.
The disclosure embargo is now the same for every severity. The patch and its advisory are published at the start of the following month, so a vulnerability remains publicly undisclosed for no more than about a month. A critical stays private for at least ten days before that monthly release, therefore affected chains have time to act. Each advisory links to its patch, which includes the root cause and a reproducing test.
The Cosmos ecosystem includes a variety of institutions and blockchains each with their own custom uses of the stack. While we can evaluate the severity and impact of vulnerabilities, we cannot guarantee that our evaluation covers cases where teams have modified, forked or used the Cosmos stack in specific ways. What we can do is give teams as much information as possible, including the impact we discovered and full end-to-end reproductions, so they can validate and make decisions on their own with full transparency from the Cosmos team.
The updated patching policy can be found here.
Security Contacts
This more transparent patching policy requires more trust between users and Cosmos Labs, and vice versa. As a result, we are implementing a more comprehensive security contact policy to support this.
Access is granted to chain development teams and to major exchange partners. Both must have passed KYC and be running the software in production. Once a team has access, the patches in that month's private repository are available to build against, including copying the source into their own build. The policy requires teams to keep those patches confidential until Cosmos Labs publishes them. That means not publishing the source anywhere, and not passing it to outside security teams, end users, validators or node operators. Shipping a binary built from the patch is fine.
The private repositories remain available for two weeks after the monthly public release, hence teams have time to move back to the public tags.
Please fill out the following form to become eligible for our KYC process. You will receive a follow-up email from [email protected].
Code of Conduct and Contribution Guidelines
Recent developments in the security landscape have also changed how projects are maintained. There is now a single Code of Conduct served to every repository in the Cosmos organization, and a contributing guide for the repositories that do not keep their own.
The disclosure policy now sets out the consequences of publishing vulnerability details before their disclosure date, from a written warning through to a permanent block from the Cosmos GitHub organization. Reports of improper behavior help improve security for the whole ecosystem. Appeals and reports go to [email protected], which is independent of the team that issues these consequences.
Immunefi Program Changes
The Cosmos stack bug bounty will continue to be hosted on Immunefi. Vulnerability reports and subsequent communications are handled through the Immunefi platform.
Rewards are now restructured:
- Critical: $50,000
- High: $4,000
- Medium: $1,000
- Low: $500
We strongly encourage researchers to target critical vulnerabilities, because they pose a risk to user funds and therefore provide the greatest benefit to the community when addressed.
Addressing other vulnerabilities across the Cosmos stack remains relevant. This change aims to align researcher incentives with finding fund-loss vulnerabilities, so we can prioritize those fixes across the stack.
The full scope of our program is on its page.
Ledger Security
We are also excited to announce a new update to the Cosmos stack, fully centered on ledger-level security. Enterprises and validators need more secure methods for operating Cosmos software and we are delivering new versions of Cosmos SDK and CometBFT with key features like the long-requested validator key rotation and more native remote signing capabilities.
The Cosmos stack officially has post-quantum support, with the ML-DSA quantum-resistant signing scheme being released and supported across the board. ML-DSA is available for both validator and account keys, which means a chain can move to a fully quantum-resistant architecture as defined today. Chains that keep Ethereum-compatible accounts stay on secp256k1 for account keys.
These timelines are not far out, with NIST deprecating RSA-2048 and ECC-256 in 2030 and the G7 Cyber Expert Group asking financial institutions to migrate their critical systems between 2030 and 2032. Once a chain has enabled ml_dsa_65 and its IBC counterparties are running CometBFT v0.40.0, v0.38.26, or later, validators can move to ML-DSA keys at their own pace, outside any coordinated upgrade. The network is post-quantum secure once two thirds of voting power has rotated.
cosmos/kms signs through hardware security modules and key management services, so the validator uses FIPS 140-3 validated modules, which FedRAMP-authorized deployments require. It replaces TMKMS, maintained by Iqlusion, and there is a migration guide for teams moving across.
The 2026.1 Ledger Security release is across four artifacts, bundled together and joining the existing 2026.1 release family:
We published an official ledger blog with all the details on October 8. Check more details here.
Moving Forward
As mentioned, this blog marks the first step of a major commitment to hardening security across the Cosmos stack. We have made significant improvements to our vulnerability remediation process to better support Cosmos stack users, and also delivered a new stack release that improves the security of ledger operations.
Moving forward, we will be focusing our efforts on the following:
- Continuously iterating on the vulnerability remediation policies with the operator community and enterprises
- Developing in-house resources to use AI for preemptive scanning of software, including code already in production, to proactively identify vulnerabilities
- Revamping internal auditing processes with overhauled threat modeling based on incident records, to catch problems before code is released
The Cosmos security team wants to make sure we are sharing these developments in a way that allows greater transparency for users. Please continue to share your feedback at [email protected] as we iterate our processes and build a more secure Cosmos.
Where to go next
- The patching and disclosure policy
- Report a vulnerability through the bug bounty program
- Sign up for private security notifications if you run the Cosmos stack in production
- Advisories, audits and incident communications
- Post-quantum keys and validator key rotation in the Cosmos Docs
About the author
Alex Johnson is Cosmos Security Operations Lead. He has spent years working on distributed systems as both an engineer and a manager, so he understands how the technology works under the hood as well as what to build with it. What drives him is developer empathy, building tools that institutions and developers can actually pick up, use and succeed with.
