On July 7, 2026, zkSecurity published the first post in a series: AI meets Cryptography 1: What AI Found in Cloudflare's CIRCL. Their pipeline — LLMs plus the zkao audit agent — confirmed seven real vulnerabilities in Cloudflare CIRCL, an experimental post-quantum and advanced cryptography library. All seven are fixed upstream; most earned bounties under Cloudflare's HackerOne program.
The HN thread (July 8, 2026, 86+ points) asked the right meta-questions: how many AI candidates vs confirmed bugs, why some flaws lacked tests, and what zkao actually is versus a one-shot LLM prompt. This guide answers those from the primary source — no invented CVEs or severity claims.
TL;DR
| Question | Answer (from zkSecurity) |
|---|---|
| What was scanned? | Cloudflare CIRCL — threshold RSA, BLS, HPKE, CP-ABE, DLEQ proofs |
| Confirmed bugs | 7 — all fixed; bounty-confirmed for most |
| What is zkao? | zkSecurity's continuous AI audit agent — ~9h scan → report; better at crypto bugs + false-positive filtering than raw frontier prompts (per their team on HN) |
| Human role? | AI → candidates; experts → validation, PoC minimization, disclosure |
| Scale | 200+ crypto projects scanned, 1000+ candidates — triage is the bottleneck |
| AI severity | Unreliable — often over-rates; underrated the BLS rogue-key flaw |
| Best model (then) | Opus 4.6 + skills found 5/6; zkao alone found the CP-ABE break |
What zkao is (and is not)
Not: a single ChatGPT paste of your repo.
Is: zkSecurity's product for compounding security coverage — described in their zkao: Security That Compounds post as analogous to continuous fuzzing, but with AI reasoning over code.
From the July article and an HN reply by a zkSecurity team member:
- You start a scan; roughly ~9 hours later you get a report
- Tuned to find cryptographic bugs better than frontier models alone
- Tuned to discard false positives better than naive LLM output
- Built by encoding zkSecurity researcher skills into the pipeline
For CIRCL, the workflow was experimental: LLM-only vs LLM + expert skills, then zkao on the same codebase. zkao found all six LLM-confirmed issues plus a seventh the LLM pass missed.
The seven bugs — severity at a glance
zkSecurity's table compares AI-assigned severity vs Cloudflare confirmed severity after fix:
| # | Bug | AI | Cloudflare | Fix | Found by |
|---|---|---|---|---|---|
| 1 | float64 precision loss in TSS/RSA polynomial eval | Critical | Low | f7d2180 | Opus 4.6 + skills |
| 2 | qndleq forgery via prover-controlled SecParam | High | Low | 757dde4 | Opus 4.6 + skills |
| 3 | BLS aggregate missing message distinctness (rogue key) | Medium | High | 9798df7 | Opus 4.6 + skills |
| 4 | DLEQ soundness break via FillBytes sign collision | High | Low | 19848a5 | Opus 4.6 + skills |
| 5 | HPKE PSK validation bypass (Go | vs , in switch) | Medium | Medium (dup) | a3b4fa3 | GPT-5.3 + skills |
| 6 | TSS/RSA Lagrange coefficients in int64 (overflow + truncation) | High | Medium | 751e372 | Opus 4.6 + skills |
| 7 | CP-ABE access-control break via AND-share bug | Critical | Critical | def2fd3 | zkao |
Takeaway: treat AI severity as noise. Cloudflare's bounty lens also weights live service impact — a soundness-breaking proof bug can still rate Low if unused in Cloudflare's deployment. Library consumers may face different risk.
Bug highlights (why they matter)
1. Float64 in threshold RSA — "people do crypto using floats?"
Deal() evaluated polynomial terms with math.Pow(float64(x), float64(i)) — 53-bit mantissa silently rounds before cast to integer. Wrong key shares for moderate player counts. Fix: Horner's method in big.Int (f7d2180).
HN note: Falcon (FN-DSA) legitimately uses floats in some deployments — but requires hand-implemented constant-time float ops. CIRCL's case was simply wrong tool choice.
3. BLS — the one AI underrated
VerifyAggregate checked the pairing equation but not message distinctness — enabling textbook rogue key attacks without proof-of-possession. AI named the attack but downgraded severity because BASIC mode docs put distinctness on the caller. Cloudflare fixed by rejecting duplicate messages (9798df7).
4. DLEQ — algebra meets serialization
Valid proof for (g, gx, ...) accepted for forged (g, -gx, ...) when challenge c is even: algebraic cancellation plus FillBytes stripping sign in the hash. ~50% success on honest proofs. Fix: checkBounds rejects negative inputs (19848a5).
5. HPKE — Go switch trap
case modePSK | modeAuthPSK: // single case value 0x03, NOT two cases
modePSK alone matched no branch — SetupPSK with nil PSK slipped through. One-character-class fix: case modePSK, modeAuthPSK: (a3b4fa3).
7. CP-ABE — full access-control break (zkao find)
CP-ABE encrypts under policies like (usa AND finance) OR admin. AND gates must split the parent secret; one child gets r, the other parent - r.
The bug gave In0 the full parent and In1 zero — one AND leaf alone reconstructs the message key. Worse: Boneh-Katz CCA wrapping puts a wildcard leaf every user key satisfies as In0 of an outer AND. Every issued key decrypts regardless of policy.
Fix: one line — shares[gate.In1].sub(shares[gate.Out], shares[gate.In0]) (def2fd3).
HN testing question: regression test added at fix time — a higher-level "wrong attribute cannot decrypt" test is harder because the sharing scheme's correctness is subtle; zkSecurity credits zkao for reasoning through CP-ABE impact, not dismissing as hygiene.
What zkSecurity learned
1. AI severity is asymmetrically wrong
Over-rates local scary bugs (float64 → Critical). Under-rates known attack classes when responsibility is "on the caller" (BLS). Hypothesis: library bugs need system-level threat modeling the model cannot see. zkao lets devs supply threat context via zkao.md config.
2. Model pairings are unstable
Initial run: Opus 4.6 discovers, GPT-5.3 mostly validates (except HPKE). Weeks later with Opus 4.7 / GPT-5.4: roles reversed. Implication for builders: do not hard-code "best auditor model" — zkao aims to stay model-agnostic.
3. AI gathers but does not always chain
Bug 6 packed overflow and truncation as one finding without relating them into a chained exploit narrative. zkao is building composition steps for multi-bug chains.
4. Candidate volume vs confirmed reports
"We scanned more than 200 cryptographic projects … over a thousand candidate findings. The biggest bottleneck today is triage."
zkSecurity has not published exact candidate counts for CIRCL alone in the article — but the ratio is clearly many candidates → seven ship-quality reports. That human-in-the-loop gap is what zkao productization targets.
Implications for AI-assisted security
| For maintainers | For teams buying AI audit |
|---|---|
| Crypto libraries need domain tests — "can't decrypt without policy" integration tests catch AND-share class bugs late | Demand PoCs — zkao emphasizes reproducible exploits to kill false positives |
| Never float64 for integer crypto math | Do not trust AI severity — map to your deployment threat model |
| Verifier must own security parameters — not proof structs | Continuous scans beat one-shot pen tests for moving frontiers |
| Language traps (Go switch OR) still fool humans and AI alike | Model-agnostic pipelines — frontier leadership rotates monthly |
Pair with MCP security guidance if agents touch crypto tooling — different surface, same triage discipline.
Related on explainx.ai
- MCP security guide — command injection and trust boundaries in agent tooling
- Fable 5 advisor patterns — cheaper executor + smarter advisor for code audit loops
- Agent harness engineering — tool loops for long-horizon review
- Claude for Open Source — grants for maintainers securing ecosystems like CIRCL
- Kokoro local TTS — unrelated stack, same "local vs cloud" sovereignty theme
Official sources
- AI meets Cryptography 1: CIRCL — zkSecurity
- zkao: Security That Compounds
- Cloudflare CIRCL — GitHub
- zkao.io
Bug counts, severities, model names, and commit SHAs follow zkSecurity's July 7, 2026 article. Cloudflare bounty ratings reflect their deployment context — assess impact in your own integration before prioritizing patches.