By now you have probably caught wind of the chatter around autonomous AI bug hunting, so let us zoom in on something that actually moved the needle this week for us as Web3 builders. According to a TechInformed write-up, researchers stitched together an LLM-driven pipeline that hunted down a real, multi-stage SQL injection zero-day in a WordPress plugin with more than 300,000 installs, end to end, with no human babysitting the loop. The bug got assigned CVE‑2026‑3985, lined up with an independent disclosure, and quietly underlined a point worth sitting with: the boring, helpful job an LLM does after a static scanner raises a flag is already good enough to weaponize a finding.
How the pipeline actually works under the hood
The setup is refreshingly boilerplate. You point a traditional code scanner, in this case Joern, at a codebase with a deliberately broad set of "look for interesting things" rules, and let it spit out code slices around each candidate finding. Then an LLM agent takes those slices, triages them, and walks the bug all the way to a working exploit. The researchers deliberately avoided narrow rules because LLMs are great at reasoning over small chunks of code but terrible at ingesting an entire repo, so the heavy lifting stays with the static engine while the model handles the fuzzy judgment call. They aimed it at the top 200 WordPress plugins, which are already picked over by bounty hunters, and still surfaced a high-impact SQLi in the Creative Mail plugin that needed multiple steps to exploit, exactly the kind of thing a classic SAST tool tends to wave through.
Why this matters for the oracle crowd
Here is the part I want you to chew on: nothing about this pipeline is WordPress-specific. Joern and friends understand plenty of languages, and the same recipe applies to your Solidity contracts, your off-chain adapter code, the TypeScript glue around your Chainlink nodes, even the Go services feeding price feeds. If a couple of researchers can pop a 300k-install plugin fully autonomously today, assume the same playbook is already being aimed at open-source oracle middleware, bridge relayers, and keeper bots. The new normal is here, the future-risk framing is just polite denial.
AgenticRepair raises the bar on the patching side
Meanwhile, The Cryptonomist covered a complementary piece of the puzzle from researcher Michael Fu. His framework, AgenticRepair, splits the work across three specialized LLM subagents that each gather one flavor of context security engineers normally piece together by hand: code-structure context (cross-file data flows and memory patterns), runtime-execution context (where the crash actually originates), and commit-history context (how the fragile pattern got introduced in the first place). A fourth repair subagent then synthesizes a context-conditioned patch from that briefing. On SEC-Bench, a 300-case benchmark of real vulnerabilities validated through sanitizer-based checks, the framework hit a 73 percent success rate, beating the strongest baseline by 29 percentage points. That gap is the headline, because it suggests that treating security bugs as a special category, rather than handing them to a generic bug-fixer, produces meaningfully better patches, not just marginally tidier ones.
What to check on your side this week
A few practical moves worth slotting into your sprint. First, audit the off-chain surface area around your oracles the same way the pipeline does: run Joern or a comparable slicer over your adapter repos, keep the rules broad, and let an LLM agent triage the noise rather than scrolling SAST output yourself. Second, if you maintain any open-source dependency that touches price feeds or signature verification, expect a patch wave, the NCSC has been warning about exactly this, and plan to test rather than auto-upgrade. Third, give AgenticRepair's framing a serious look the next time you are staring at a post-mortem: which of those three context layers did you actually have, and which did you reconstruct from memory under pressure? That single question tends to expose where your patching workflow is leaking hours.
We are going to keep poking at both ends of this loop, the discovery side and the repair side, because whichever piece you ignore is the one that will bite your oracle stack first. Drop your war stories in the comments, especially the gnarly multi-step bugs an LLM helped you reach, and let us build out a shared playbook together.