This issue was quickly fixed and disclosed as “CVE-2026-34219” with credit to the team. The broader concern, however, was separating the real agent bugs from the ones posing as such.
“The surprise was how little work was put into finding them, and how much was spent distinguishing real bugs from those that seemed real,” wrote Nikos Baxevanis, author of the post.
The difficulty began with what an agent produces. A fuzzer, the standard tool that sends malformed data to software until something breaks, returns a crash and a record of where it happened, which an engineer can confirm within minutes.
However, an agent returns a created story. It traces how the flaw could have been reached, explains why it is important, offers a severity assessment, and provides working code that demonstrates the attack. All of this happens in flowing prose, reading the same whether the bug is real or invented.
Three types of false positives are recurring, according to the Foundation.
The first was a crash that only happens in a test build, where the compiler enables security checks that the bundled software doesn’t have, so nothing breaks for real users.
The second was an attack that only works if the dangerous value is manually inserted into the program, because any path an outsider might take to transmit it first rejects the value. The third came from formal verification, the practice of mathematically proving that code behaves correctly, where a proof succeeded by demonstrating something trivially true and told reviewers nothing about the software.
