Lean’s recent triumph—an AI‑driven team building and proving a fully verified zlib clone called lean‑zip—has drawn attention. The project, backed by 10 autonomous agents, delivered a version that Lean guarantees free of implementation bugs. The claim rests on a theorem that compressing and then decompressing any <1 GB byte array restores the original data in this.

But a weekend fuzzing campaign revealed a flaw. A Claude‑powered fuzz harness ran 105 million executions against a stripped‑down lean‑zip binary, uncovering a heap buffer overflow in Lean 4’s runtime allocator lean_alloc_sarray and a denial‑of‑service in the library’s ZIP archive parser. The overflow affects every Lean 4 release up to the latest nightly in the development cycle.

The runtime bug stems from a wrap‑around in lean_alloc_sarray when allocating near SIZE_MAX, causing a tiny 23‑byte buffer to be read as if it held gigabytes of data. A crafted 156‑byte ZIP file triggers the issue, proving that even formally verified code can suffer from unverified runtime dependencies across all Lean 4 applications worldwide.

Verification only protects the parts that are proved. Lean‑zip’s compression logic was formally verified, but its ZIP header parser was left unproven, allowing the denial‑of‑service. The discovery underscores that formal methods must encompass both algorithmic logic and trusted runtime components to deliver truly secure software for developers and users worldwide.