{"slug": "the-year-finding-and-exploiting-bugs-became-cheap-and-what-to-do-about-it", "title": "The Year Finding and Exploiting Bugs Became Cheap, and What to Do About It", "summary": "AI-assisted bug finding and exploit development became cheap and practical toward the end of 2025, according to security researcher and ZKSecurity author, with the cost of finding and exploiting bugs falling exponentially while total losses have not been reduced and exploits of smaller projects are increasing exponentially. In 2026 the first two known exploits against live ZK circuits occurred: one was exploited by white hats to rescue roughly $1.5 million and the other was drained for 5 ETH, both rooted in Groth16 verifiers generated from trusted setups that had not been finalized correctly. The author's AI-assisted pipeline found real vulnerabilities in Cloudflare's CIRCL, OpenVM's zkVM, and Bron Labs's MPC library, and argues security strategy must combine testing, AI tools, manual reviews, and formal verification continuously rather than relying on one perfect audit.", "body_md": "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.\n\nToward 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<sup>[1](#fn:numbers)</sup>.\n\nIn my opinion three effects are already visible:\n\n- Total losses have not been reduced.\n- Beyond the largest and most obvious targets, we see exploits of smaller projects increasing exponentially.\n- Bug bounty programs are filling with a mix of valuable findings, duplicates, and AI slop.\n\nAll 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.\n\nWe 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.\n\nAI 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.\n\nAI 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.\n\nThat 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.\n\nAI 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.\n\nIn 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.\n\n## Advanced cryptography is losing its accidental shelter\n\nThe 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.\n\nFrom an attacker's perspective, why spend weeks understanding a ZK protocol when a simpler contract might secure more money?\n\nThat 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<sup>[2](#fn:morezk)</sup>.\n\nOn 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.\n\n## Is AI the problem or the answer?\n\nStrangely, nowadays AI seems to be both the cause of every new (security) problem and the proposed solution to it.\n\nBug 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.\n\nAttackers can use AI to understand code and develop exploits faster. The proposed answer is to use AI to find the vulnerabilities before they do.\n\nThat sounds circular because it is. Security has always been a cat-and-mouse game. AI has simply accelerated both sides.\n\nSo, 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.\n\nBut 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.\n\n## What is the state today and where things going?\n\nThe 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.\n\nVery 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.\n\nIt is much less effective when attackers have a much higher throughput for attacking protocols.\n\n**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. \n\nWhen 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.\n\nThe estimates below are deliberately directional. They are my view of adoption among security-conscious cryptography projects, not the result of thorough research or survey.\n\nTests, 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.\n\nThird-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.\n\nFor 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.\n\nLet's go over the layers one by one.\n\n### 1. Tests, fuzzing, and traditional hardening\n\nLLMs 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.\n\nFor 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.\n\nThis layer should be adopted by everyone. It is cheap, repeatable, and useful to every layer above it.\n\n### 2. Custom AI harnesses\n\nA 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.\n\nOne 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.\n\nThe 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.\n\n### 3. Third-party AI auditing tools\n\nThis 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.\n\nOne question I often get is:\n\nif a team already has its own harness, why should it use an external AI auditor?\n\nThe 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.\n\nThis 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.\n\nWe 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.\n\n### 4. Manual audits\n\nManual 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<sup>[3](#fn:nonai)</sup>).\n\nBut 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.\n\nFor 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.\n\n### 5. Formal verification\n\nFormal 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.\n\nAt 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.\n\n### 6. Assurance for formal verification itself\n\nFormal 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.\n\nThis 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?\"\n\nWe 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.\n\n### 7 and 8. Bug bounties, monitoring, and incident response\n\nThese are not our main focus, but weaknesses here can erase the value of every earlier layer.\n\nClosing 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).\n\nProduction 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.\n\n## What happens next\n\nHere are my current bets for the next few years:\n\n1. \n**Offensive capability becomes abundant.** More people/automated systems will be able to inspect every valuable project even specialized code, and exploit vulnerabilities.\n2. \n**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.\n3. \n**Audits become continuous.** Point-in-time review will basically have an expiration day, for live protocols re-audit every X months would be needed.\n4. \n**Security harnesses become product infrastructure.** In an era where exploitation becomes almost free, having good security infrastructure and integration will become a must.\n5. \n**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.\n\nThe 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.\n\nThe 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.\n\nFinding bugs became cheap. Building confidence is still hard. That is the work ahead.\n\nIf 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).\n\n#### Acknowledgements\n\n*Thanks to Vitalis Salis and Hao Pham for reviewing this post and for the feedback.*\n\n1. \n[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.[↩](#fnref:numbers)\n2. \nIn 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.[↩](#fnref:morezk)\n3. \nthere might be need for non-AI-assisted audits but that is a different topic. [↩](#fnref:nonai)", "url": "https://wpnews.pro/news/the-year-finding-and-exploiting-bugs-became-cheap-and-what-to-do-about-it", "canonical_source": "https://blog.zksecurity.xyz/posts/the-year-finding-bugs-became-cheap/", "published_at": "2026-09-07 00:00:00+00:00", "updated_at": "2026-09-21 16:24:28.224541+00:00", "lang": "en", "topics": ["ai-safety", "artificial-intelligence", "ai-agents", "ai-tools"], "entities": ["ZKSecurity", "Cloudflare", "CIRCL", "OpenVM", "Bron Labs", "Groth16", "Ethereum"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/the-year-finding-and-exploiting-bugs-became-cheap-and-what-to-do-about-it", "markdown": "https://wpnews.pro/news/the-year-finding-and-exploiting-bugs-became-cheap-and-what-to-do-about-it.md", "text": "https://wpnews.pro/news/the-year-finding-and-exploiting-bugs-became-cheap-and-what-to-do-about-it.txt", "jsonld": "https://wpnews.pro/news/the-year-finding-and-exploiting-bugs-became-cheap-and-what-to-do-about-it.jsonld"}}