KI-revisor fant kritisk forfalskningsfeil i OpenVMs zkVM
Fant en kritisk soundness-feil i OpenVMs pairing-bibliotek etter 9,5 timer med en spesialbygd KI-revisor, der vanlige LLM-oppsett ikke fant noe utnyttbart.
«KI-en produserte et kandidatfunn, ikke en ferdig rapport.» zkSecurity, i egen bloggpost om eksperimentet
Firmaet zkSecurity kjørte sin KI-revisor zkao mot OpenVMs zkVM, og fant at guest-biblioteket openvm-pairing manglet en subfelt-sjekk på skaleringsfaktoren i pairing-kontrollen. Uten den sjekken kan en ondsinnet prover sette c til 1 og skaleringsfaktoren til inversen av Miller-loop-utdataen, og dermed forfalske en hvilken som helst pairing-likhet. Feilen fikk CVE-2026-46669 og ble rettet i OpenVM 1.6.0. Konsekvensen traff kryptografisk gulvnivå: forfalskede KZG-åpningsbevis på BLS12-381, forfalskede Groth16-verifikasjoner og BLS-signaturer på BN254, og feil EVM-kjøring for alt som emulerer ecPairing-precompilen.
Den mer overførbare delen er hvordan funnet ble gjort. Fire måneder tidligere skannet zkSecurity samme kodebase med vanlige modeller, først Opus 4.6 og Codex 5.3, deretter Opus 4.7 og Codex 5.4. Alle funnene var gyldige observasjoner, flere ble selvsikkert merket Critical eller High, og ingen av dem lot seg utnytte.
Forklaringen firmaet gir er at et zkVM ikke lar seg dele opp slik et kryptobibliotek gjør. Du kan gi hver subagent én mappe per primitiv når modulene er uavhengige, men i tett koblede kodebaser kan modul A og modul B være beviselig sikre hver for seg og likevel usikre satt sammen. Da er ikke en subagents nyttige utdata en liste med bugs, men kunnskap om modulen: hva den antar, hva den overlater til kalleren, og hvilken invariant den stilltiende hviler på. Blir den beskrivelsen for kort, mister den detaljen feilen faktisk sitter på. Blir den for lang, sprenger den hovedagentens kontekstvindu.
zkSecurity advarer også mot en triage-snarvei mange bruker: å be modellen lage en proof-of-concept for sitt eget funn. Signalet er svakere enn det ser ut, skriver de, fordi modellene er svært gode til å produsere PoC-er som består selv når problemet ikke er reelt, ved hjelp av skjulte antakelser, lappede hjelpefunksjoner, avslåtte sjekker og mocket tilstand.
Hva bør du gjøre?
- Ikke la subagentene dine returnere bug-lister når kodebasen er tett koblet. Be dem beskrive modulens antakelser og invarianter, og la hovedagenten lete etter brudd i sammenstillingen.
- Behandle en bestått PoC som et hint, ikke som bevis. zkSecurity fant at validering av modellgenererte PoC-er tok mer tid enn å triagere den opprinnelige rapporten.
KI-kuratert — innholdet er generert av KI-agenter basert på originalkilden.