Notifications
Clear all
Topic starter
01/08/2026 8:54 pm
TL;DR: An apparent Fiat-Shamir ordering issue chained with a Dory polynomial commitment binding gap can let an invalid Jolt proof be forged, according to VERIA LABS. The result underscores that application security now has to reason about chained weaknesses, not isolated alerts.
NHIMG editorial — based on content published by VERIA LABS: Hacking a16z Breaking Jolt and Dory
Questions worth separating out
Q: What fails when security tools evaluate findings one at a time?
A: They miss exploit chains where each issue is only dangerous in combination with the next one.
Q: Why do dependencies create hidden security risk in application security?
A: Because the dependency may implement the actual trust decision, not just support the application.
Q: How can security teams know if a proof or verification flow is actually safe?
A: By checking that the same statement is bound through every stage of the flow, from transcript generation to final verification.
Practitioner guidance
- Map multi-stage exploit paths across dependencies Review security findings as potential chains, not isolated issues.
- Audit verification boundaries, not just application code Identify where the real trust decision occurs in cryptographic and delegated systems.
- Require dependency-level exploitability testing Test whether an imported library is merely vulnerable in theory or actually reachable from your code path.
What's in the full article
VERIA LABS's full analysis covers the technical detail this post intentionally leaves at the governance and security-implication layer:
- Step-by-step traces of how the agent chained the Jolt and Dory weaknesses into a forged proof path.
- Code-level explanation of the Fiat-Shamir ordering observation and why it was not exploitable on its own.
- Detailed walk-through of the Dory binding gap and the alternate opening point the agent used to satisfy the final proof.
- The exact program and verifier behaviour used to demonstrate a false accepted output.
👉 Read VERIA LABS's analysis of the Jolt exploit chain and Dory binding gap →
AI pentesting agents in zkVM codebases: what changed for security teams?
Explore further
01/08/2026 9:03 pm
Chained assurance failure is the real security problem here. The exploit did not depend on one dramatic break. It depended on two smaller weaknesses becoming exploitable only when the agent reasoned across stages and across a dependency boundary. That is a useful warning for any programme evaluating cryptographic systems, NHI workflows, or delegated machine trust: local correctness does not equal system safety. Practitioners should treat multi-stage reasoning as a first-class governance requirement.
A question worth separating out:
Q: What should teams do when an exploit seems to require multiple small weaknesses?
A: Treat the combination as the risk, not the individual findings. Validate whether the weaknesses can be chained by an attacker, prioritise the dependency or control that closes the last verification gap, and keep a human review path for high-value codebases where automated scoring is too coarse.
👉 Read our full editorial: AI pentesting agents exposed a two-step exploit chain in Jolt
