# The Year Finding and Exploiting Bugs Became Cheap, and What to Do About It - **Authors**: Stefanos Chaliasos - **Date**: September 07, 2026 - **Tags**: security, AI, audit, zk, formal-verification Over the past few years, nearly every security researcher I know has incorporated LLMs into their process. What began with chatbots quickly evolved into scripts calling model APIs, then agents, skills, custom harnesses, autoresearch loops, and more approaches than anyone can reasonably keep track of. Toward the end of 2025, something shifted. Models and the harness/systems around them became better, and AI-assisted bug finding and exploit development stopped feeling like an interesting experiment, but it became reality, while we start observing an increased amount of exploits[1](#fn:numbers). In my opinion three effects are already visible: - Total losses have not been reduced. - Beyond the largest and most obvious targets, we see exploits of smaller projects increasing exponentially. - Bug bounty programs are filling with a mix of valuable findings, duplicates, and AI slop. All of the above are happening due the fact that **the cost of finding and exploiting bugs is falling exponentially**, while most attackers are quicker (and it is much easier I might add) to adapt than most of the defenders. We can spend a long time discussing what went wrong over the past year. The more important questions are what happens now, and what we should do about it. > [!IMPORTANT] Our thesis > > AI changes the economics of both attack and defense. A successful security strategy will not rely on one perfect audit. It will combine everything from testing, AI tools, to manual reviews, and formal verification. Importantly on a continuous way. AI does not need to discover and exploit every vulnerability autonomously to change security. It only needs to make each stage cheaper: learning an unfamiliar codebase, generating hypotheses, find bugs through a myriad of strategies, writing a PoC, and trying again when unsuccessful. That changes the ROI for attackers. A target that once required weeks of specialist work may now require days. A smaller protocol that was previously not worth trying to attack, becomes an ideal target. > [!NOTE] This is a change in ROI, not some magic AI apocalypse > > AI can be unreliable and still be transformative. If ten weak attempts are cheap enough, the eleventh attempt only needs to succeed once. Especially in security that is critical, where you might have fixed 99% of the bugs, but still one bug is enough to break a protocol. In the following, will discuss what's happening on cryptography, if AI is the answer to the problem, and my personal view on how security is getting evolved. ## Advanced cryptography is losing its accidental shelter The impact is especially important for ZKPs, MPC, and other advanced cryptographic protocols. These systems used to benefit from a kind of accidental shelter. The code was more difficult to understand and grasp than other software, the number of capable attackers was small, and the value secured by projects was often lower than the value sitting in a large smart contract protocol. From an attacker's perspective, why spend weeks understanding a ZK protocol when a simpler contract might secure more money? That is shifting quickly. In 2026 we saw the [first two known exploits against live ZK circuits](https://blog.zksecurity.xyz/posts/groth16-setup-exploit/). One was exploited by white hats to rescue roughly \$1.5 million; the other was drained for 5 ETH. The root cause was not a deep new cryptographic attack. Both systems used Groth16 verifiers generated from trusted setups that had not been finalized correctly. Something that most of the time is out-of-scope from audits and a very simple prompt detects it immediately. After that more exploits have occurred in the ZK-space[2](#fn:morezk). On the defensive side, we have seen the same change firsthand. Our AI-assisted pipeline found real vulnerabilities in [Cloudflare's CIRCL](https://blog.zksecurity.xyz/posts/circl-bugs/), [OpenVM's zkVM](https://blog.zksecurity.xyz/posts/openvm-bugs/), [Bron Labs's MPC library](https://blog.zksecurity.xyz/posts/bron-bugs/), and many others. Importantly, auditing those codebase would have taken a long time but AI tools manage to find bugs quite reliably and fast. Something worth noting here is that our AI-auditors did not found all the bugs, in matter of fact they missed some that we found later, still from an attackers and defenders perspective that's irrelevant. ## Is AI the problem or the answer? Strangely, nowadays AI seems to be both the cause of every new (security) problem and the proposed solution to it. Bug bounty programs are flooded with AI-generated reports, creating a burden for triagers and a worse experience for researchers submitting valid reports. The proposed answer is AI-assisted deduplication and triage. Attackers can use AI to understand code and develop exploits faster. The proposed answer is to use AI to find the vulnerabilities before they do. That sounds circular because it is. Security has always been a cat-and-mouse game. AI has simply accelerated both sides. So, is the answer to everything AI? Yes and no. Nearly every auditor now uses AI to understand code, detect vulnerabilities, and prepare proofs of concept. We do too. We also continuously improve our AI-auditor [zkao](https://zkao.io/), which continuously audits cryptographic code for vulnerabilities. But a AI is not a panacea. Models change, harnesses improve, and the state of the art moves every few months. A useful AI security setup must be evaluated continuously, updated as new techniques emerge, and tested against the kinds of code its users actually ship. The tool itself needs a security research team behind it. ## What is the state today and where things going? The following diagram shows how I think about the available defenses. They are not substitutes for one another, and they are not steps that a project completes once and leaves behind. ![A layered security program, from continuous foundations through deep assurance to operational feedback](https://blog.zksecurity.xyz/posts/the-year-finding-bugs-became-cheap/security-assurance-stack.svg) Very few projects use every layer today. Most employ a handful, e.g., tests and fuzzing, one or more external audits before a major release, perhaps a bug bounty, and some monitoring. That was a reasonable model in the pre-AI era. It is much less effective when attackers have a much higher throughput for attacking protocols. **An audit from three years ago is almost worthless nowadays in most cases**. Even if a project has not changed substantially since then (or at all), the security field has changed dramatically. When projects actually evolved this becomes critical for the whole stack. Tests must evolve with the code. AI harnesses must learn from new bugs. Formal verification must track the real implementation and its assumptions. Bug bounty triage and incident response must keep pace with rising report volume. The estimates below are deliberately directional. They are my view of adoption among security-conscious cryptography projects, not the result of thorough research or survey. ![Estimated adoption of security practices today](https://blog.zksecurity.xyz/posts/the-year-finding-bugs-became-cheap/security-adoption-today.svg) Tests, fuzzing, and manual audits have been adopted and matured over the years. Custom AI harnesses has becoming popular recently but requires internal security expertise. Formal verification remains specialized and expensive. Reviewing a formal verification effort as an adversarial target is newer still. Third-party AI auditing tools sit in the middle. Adoption is growing quickly, but the market is noisy. It is easy to demonstrate that a tool can produce findings. It is much harder to demonstrate that those findings are valid (even an AI-PoC could be slop), important, and worth a maintainer's time. For critical cryptographic infrastructure, I expect the picture to change substantially over the next few years. For the most security-aware projects, it may happen within months. ![Expected adoption of security practices among the most security-aware projects](https://blog.zksecurity.xyz/posts/the-year-finding-bugs-became-cheap/security-adoption-next.svg) Let's go over the layers one by one. ### 1. Tests, fuzzing, and traditional hardening LLMs have made it cheaper to write tests, fuzz targets, static-analysis rules, and the glue code needed to run them. That does not make every generated test useful. The hard part is still choosing the right properties and building oracles that detects critical issues. For cryptographic systems, ordinary unit tests are only the beginning. Domain-specific fuzzing, property-based testing, differential testing, and fault injection can reach failures that simple tests miss. Our [zkvmBlast](https://blog.zksecurity.xyz/posts/zkvmblast/) project is such an example. This layer should be adopted by everyone. It is cheap, repeatable, and useful to every layer above it. ### 2. Custom AI harnesses A small number of security-focused teams already maintain their own AI bug-finding setup. At the simplest level, this may be a collection of prompts and skills. At the other end, it may be a full internal harness with specialized agents, validation stages, codebase context, evaluation infrastructure, and self-evolving loops. These harness should be quite specialized for a specific project and its major threats. One of the most important idea is that these should also be **regression harnesses**. In the past, finding a bug meant adding a test. Now it should also mean updating the security harness so that future versions can rediscover that class of bug, ideally across the rest of the codebase. The harness must then run frequently, improve over time, and use diverse models when the risk justifies the cost. A one-off prompt is not continuous security. ### 3. Third-party AI auditing tools This is the most heavily marketed part of the stack. You have probably already heard claims that some tool has solved software security once and for all. It has not. One question I often get is: > if a team already has its own harness, why should it use an external AI auditor? The answer is that a third-party tool only deserves a place if its maintainers continuously follow and advance the state-of-the-art, evaluate new models, encode new security knowledge, make it more efficient/cheaper, and improve the system against the code their clients actually write. Keeping an internal harness at that level can be more expensive and difficult than it first appears. This is why [zkao](https://zkao.io/) has remained focused on cryptography. We spend most of our time making it better at the kinds of code our clients build. > [!NOTE] Where AI tools fit > > We see general AI tools as a cheap first line of defense, and specialized continuous AI auditing as a deeper layer. Neither removes the need for an expert review of critical code. ### 4. Manual audits Manual audits remain the main independent defense for most projects, and I expect that to continue. Human auditors are still best placed to reconstruct an incomplete threat model, challenge protocol assumptions, reason about composition, validate exploitability, and decide what actually matters (obviously with the help of AI nowadays[3](#fn:nonai)). But a manual audit has a fixed budget and a fixed amount of time. That limitation is inherent. AI and traditional tooling should widen the search before, during, and after the engagement so that expert attention can be spent on the hardest questions. For critical systems, audits should also be repeated. A second review can look at the same code with a different team or methodology, while later reviews should follow meaningful changes in code or new knowledge in the field. ### 5. Formal verification Formal verification is another area where AI is changing the economics. The work remains specialized, but experts can use modern models to write definitions, propose lemmas, fill routine proofs, and explore proof failures faster than before. At zkSecurity, formal verification of cryptographic systems has become one of our main focus. We built [Clean](https://blog.zksecurity.xyz/posts/clean-verified-zkvms/) to prove properties of circuits and are extending it toward end-to-end verification of multi-AIR systems such as zkVMs. We have also developed [zkGolf](https://zk.golf/) to enable formally verified autoresearch for circuits. ### 6. Assurance for formal verification itself Formal verification creates a new security boundary, and that boundary can also be wrong. A proof may establish the wrong theorem. The specification may omit a critical property. The model may exclude an attacker-controlled value. The verified component may be integrated into unverified production code incorrectly. This creates a new kind of security work: adversarial review of the specification, assumptions, proof boundaries, and integration. The question is not only, "Does the proof check?" It is also, "Does this proof say what the system does, and does the deployed system match what was proved?" We have already started doing this work and are developing a more systematic methodology for it. As formal verification adoption grows, assurance of the verification work will become a discipline of its own. ### 7 and 8. Bug bounties, monitoring, and incident response These are not our main focus, but weaknesses here can erase the value of every earlier layer. Closing a bug bounty because it attracts AI noise is becoming a norm, but it also removes a path for reporting the real issues that every other defense missed. The better answer is faster deduplication, prioritization, and AI-assisted triage. Maybe even fix the incentives a bit and cost of submitting slop (not necessarily pay-per-report). Production monitoring and incident response are equally important. Prevention will never catch everything. Every organization running critical infrastructure needs the ability to detect an exploit, understand the affected surface, contain the damage, deploy a fix, and feed what it learned back into its tests, harnesses, audits, and specifications. Further, monitoring your dependencies has also been more important in the AI-era. ## What happens next Here are my current bets for the next few years: 1. **Offensive capability becomes abundant.** More people/automated systems will be able to inspect every valuable project even specialized code, and exploit vulnerabilities. 2. **Validation becomes the bottleneck.** Handling critical bugs in a timely manner will become the most challenging and important task for defenders, either through external reports or internal audits/tools. 3. **Audits become continuous.** Point-in-time review will basically have an expiration day, for live protocols re-audit every X months would be needed. 4. **Security harnesses become product infrastructure.** In an era where exploitation becomes almost free, having good security infrastructure and integration will become a must. 5. **Formal verification becomes more practical.** AI-assisted formalization will lower some of the cost, but writting the right specification and connecting proofs to production code will remain challenging. Adversarial analysis of FV would be required moving forward. The old model was to build, audit, ship, and hope that the reviewed code stayed close enough to production. That model was already fragile. In a world where the cost of attacking software keeps falling, it is no longer adequate for critical systems. The answer is not to buy every security tool or to demand formal verification of an entire codebase. It is to build a layered system in which cheap techniques run continuously, experts spend their time on the hardest questions, fixes move quickly, and the most critical properties receive the strongest guarantees we can give them. Finding bugs became cheap. Building confidence is still hard. That is the work ahead. If you are building critical cryptographic infrastructure and want help deciding which layers make sense for your stage, risk, and budget, [we would be happy to talk](https://zksecurity.xyz/contact). #### Acknowledgements *Thanks to Vitalis Salis and Hao Pham for reviewing this post and for the feedback.* --- 1. [PeckShield](https://x.com/PeckShieldAlert/status/2094631045845164273) tracked 16 hacks in January 2026, 15 in February, 20 in March, around 40 in each of April, May, and June, and a record 50 in August. August losses were \$136M, down 49.5% from July, so attackers are striking far more often while taking less from each incident. CoinGecko's [2026 State of Crypto Security Report](https://assets.coingecko.com/reports/2026/2026-State-of-Crypto-Security-Report.pdf) counts 245 incidents and \$3.63B lost between January 2025 and July 2026.qq3936677670287331zz[zz1337820767766393qq](#fnref:numbers) [PeckShield](https://x.com/PeckShieldAlert/status/2094631045845164273) tracked 16 hacks in January 2026, 15 in February, 20 in March, around 40 in each of April, May, and June, and a record 50 in August. August losses were \$136M, down 49.5% from July, so attackers are striking far more often while taking less from each incident. CoinGecko's [2026 State of Crypto Security Report](https://assets.coingecko.com/reports/2026/2026-State-of-Crypto-Security-Report.pdf) counts 245 incidents and \$3.63B lost between January 2025 and July 2026.qq3936677670287331zz[zz1337820767766393qq](#fnref:numbers) 2. In June 2026 the deprecated Aztec Connect rollup was drained twice within a few days, for roughly \$2.2M each time. The first exploit was a [settlement boundary bypass](https://slowmist.medium.com/analysis-of-the-2-19-million-asset-theft-from-aztec-connect-d867c59b1fc6) in the rollup processor contract, the second a [missing equality constraint in the escape hatch circuit](https://www.darknavy.org/web3/exploits/aztec-private-rollup-bridge-escape-hatch-claim-proof-drain/) that let the caller substitute arbitrary outputs for a victim's note. On the MPC side, THORChain lost \$10.8M in May 2026 to a [known vulnerability in the GG20 threshold signature scheme](https://blog.thorchain.org/thorchain-exploit-report-1) used by its vaults.qq3936677670287331zz[zz1337820767766393qq](#fnref:morezk) In June 2026 the deprecated Aztec Connect rollup was drained twice within a few days, for roughly \$2.2M each time. The first exploit was a [settlement boundary bypass](https://slowmist.medium.com/analysis-of-the-2-19-million-asset-theft-from-aztec-connect-d867c59b1fc6) in the rollup processor contract, the second a [missing equality constraint in the escape hatch circuit](https://www.darknavy.org/web3/exploits/aztec-private-rollup-bridge-escape-hatch-claim-proof-drain/) that let the caller substitute arbitrary outputs for a victim's note. On the MPC side, THORChain lost \$10.8M in May 2026 to a [known vulnerability in the GG20 threshold signature scheme](https://blog.thorchain.org/thorchain-exploit-report-1) used by its vaults.qq3936677670287331zz[zz1337820767766393qq](#fnref:morezk) 3. there might be need for non-AI-assisted audits but that is a different topic.qq3936677670287331zz[zz1337820767766393qq](#fnref:nonai) there might be need for non-AI-assisted audits but that is a different topic.qq3936677670287331zz[zz1337820767766393qq](#fnref:nonai) --- This article was published on the [ZK/SEC Quarterly](https://blog.zksecurity.xyz) blog by [ZK Security](https://www.zksecurity.xyz), a leading security firm specialized in zero-knowledge proofs, MPC, FHE, and advanced cryptography. ZK Security has audited some of the most critical ZK systems in production, discovered vulnerabilities in major protocols including Aleo, Solana, and Halo2, and built open-source tools like [Clean](https://github.com/Verified-zkEVM/clean) for formally verified ZK circuits. For more articles, see the [full list of posts](https://blog.zksecurity.xyz/llms.txt).