A few days ago, a security researcher typed this into Claude:
"Somebody told me there is an RCE 0-day when you open a file. Find it."
No code pointers. No specific functions to check. No vulnerability class to search for. Just a rumor.
Claude found a real remote code execution vulnerability in Vim. It was patched within hours as GHSA-2gmj-rpqf-pxvh, fixed in v9.2.0272. Opening a crafted markdown file was enough to execute arbitrary code.
The researcher joked they'd switch to Emacs. Then they ran a variation: "I've heard a rumor that there are RCE 0-days when you open a txt file."
Claude found one there too. Opening a .txt file from a crafted directory structure. No CVE—the Emacs maintainers said it was Git's problem, not theirs. (More on that in a moment.)
Why Does a Vague Hint Work Better Than a Detailed Checklist?
The instinct is to think you should give AI more precision. Tell it exactly what to look for. Enumerate the vulnerability classes. Point it to the risky code paths.
This is wrong—and the Vim/Emacs case shows exactly why.
There are two ways to give AI a task:
Prescription: "Check these 15 functions. Look for buffer overflows in the format string handling. Review the input validation in the parser."
Convergence condition: "A state exists where opening a file executes code. Get there."
A prescription is a path. A convergence condition is a destination.
Prescriptions only reach places you already know about. If you knew which functions to check, you'd check them yourself. The checklist guides AI to your existing knowledge of the problem space.
A convergence condition forces the model to build a mental model of the system first. What could allow code execution on file open? Where are the untrusted data paths? What subsystems handle file content? The model has to reason about the territory before it can navigate to the destination. And in doing so, it can arrive at places neither the human nor the model expected ahead of time.
The Real Trick Is What You Don't Specify
Classic debugging advice says: describe the symptom, not your hypothesis about the cause. If you say "I think the buffer isn't clearing correctly"—you've already narrowed the search space to what you believe. If you say "this function sometimes returns garbage data"—you've left the cause open.
The Vim prompt works the same way. "Somebody told me there's an RCE" is maximally vague about mechanism, but maximally specific about outcome. It says: this kind of end state is reachable. Go find the path.
It also does something subtle with epistemic posture. "I heard there might be" is different from "there definitely is." It invites the model to discover and confirm, not just locate. This is speculation on my part—but I suspect the uncertainty in the framing activates more exploratory reasoning than a confident assertion would.
The Emacs Maintainer Problem
The Emacs vulnerability was demonstrably reproducible. Open this file, code executes, no prompts.
The maintainers' response: this is Git's problem, not ours.
From a pure logic standpoint, there's something to this. The exploit path involves a crafted directory structure that works with Git's behavior. Remove Git, remove the exploit vector. In a narrow sense, Git is "where the constraint should be."
But from a user perspective, this response puts the constraint in the wrong place. Users open files with Emacs. They expect Emacs to be the last line of defense before their system executes untrusted code. The mental model—Emacs is responsible for what happens when I open files in Emacs—is reasonable and widely held.
This is a version of a common problem: two systems share a boundary, a vulnerability spans that boundary, and each system's maintainers place responsibility with the other. The vulnerability doesn't live cleanly in either system—it lives in the interface between them. Neither party owns the interface, so neither acts.
The vulnerability wasn't found at Git. It wasn't found at Emacs. It was found by reasoning about what outcome is possible, and working backward to what combination of circumstances enables it. Convergence conditions don't care about organizational ownership.
What This Changes About How You Use AI
The naive view of AI-assisted code review is: "I'll use AI like a faster human reviewer—point it at suspicious code and ask it to explain what it does."
The more powerful view: "I'll describe end states I want to be impossible, and ask the model to try to reach them."
"This function should never return negative values. Find a path that makes it return one."
"Authentication should be required for this endpoint. Find a request that gets past it."
"No file in this repository should execute code on import without explicit user action. Find one that does."
These aren't instructions. They're challenges. The model has to reason about the system, not just read the code.
The Vim 0-day wasn't found by exhaustively checking all file handlers. It was found by asking what outcome is forbidden and working backward. That's not a style of prompting—it's a style of thinking. You're not guiding the model through your existing map of the problem. You're handing it the destination and asking it to navigate.
The map you already have is exactly the thing that makes your existing reviews miss things.
Credit to the Calif security blog for the original research. The MAD Bugs (Month of AI-Discovered Bugs) project launched April 2026.
