How AI Finds and Exploits Vulnerabilities

You cannot evaluate a defensive tool, or explain the threat to your board, if the mechanism is a black box. This chapter opens it.

The short version: AI vulnerability discovery is not magic. It is the workflow a good security researcher already follows, run at machine speed, with machine-scale context, as many times in parallel as the budget allows. Once you see the loop, you will also see why the same loop pointed at live infrastructure becomes an autonomous intrusion.

The Agentic Discovery Loop

Anthropic's published description of how it ran Mythos Preview against real software is strikingly simple. It launched an isolated container with the target project's source code and build environment, started the model inside an agent framework, and asked it to find security vulnerabilities. No elaborate prompt engineering. The model did the rest.

Broken into stages, the loop looks like this:

1. Isolate. The target runs in a sandboxed container with no internet access and nothing else of value.
2. Comprehend. The model reads the codebase and builds a working picture of its architecture: entry points, parsers, trust boundaries, privilege transitions, and where untrusted input meets sensitive operations.
3. Hypothesize. Based on that picture, it proposes specific candidate flaws. Not "this file looks risky," but "this length field is trusted before it is checked against the buffer allocated two functions earlier."
4. Experiment. It writes inputs and small programs designed to trigger each hypothesis, compiles them, runs them against the live build, and watches what happens.
5. Refine. Partial confirmation sends it deeper: adjusting inputs, exploring adjacent code paths, and, when asked, building toward a working exploit.
6. Verify. Memory safety bugs get confirmed by tools like AddressSanitizer, which give a clear yes or no. Logic bugs need reasoning about intended behavior, and often a human check.

source + build env
        |
        v
  [ comprehend ] --> [ hypothesize ] --> [ write test ] --> [ run ]
        ^                                                     |
        |                                                     v
        +------------- refine <---- partial signal <--- [ observe ]
                                                              |
                                                     confirmed bug / exploit
                                                              |
                                                              v
                                                      report with proof

Nothing in this loop is specific to one language, one vulnerability class or one model. That generality is why it worked across operating systems, browsers, media libraries and cryptographic code within the same program.

Why This Beats Traditional Tooling

Security teams already run static analysis, fuzzers and dependency scanners. The useful question is what the agentic loop catches that they miss.

Tool	How it works	What it finds well	What it misses
SAST	Matches code against known-bad patterns and data-flow rules	Known patterns such as obvious injection sinks	Logic flaws, novel patterns, anything requiring intent
Fuzzing / DAST	Mutates inputs and watches for crashes or errors	Crashing memory bugs on reachable paths	Bugs that do not crash, paths that need complex setup
SCA	Matches dependency versions against CVE databases	Known vulnerabilities in third-party code	Zero-days, and whether a known CVE is even reachable
Agentic AI discovery	Reads code semantically, forms and tests hypotheses	All of the above plus logic and authorization flaws, and chains	Costs more compute, needs triage capacity, verification of logic bugs is harder

The deciding difference is semantic understanding. A fuzzer explores what code does. A model can reason about what code was supposed to do, and that gap is where the hardest bugs live.

There is an honest caveat. AI tools also introduce bugs. Veracode's 2026 GenAI Code Security Report, testing more than 100 models over four years, found that roughly 44% of code-generation tasks produced code with an OWASP Top 10 weakness, an average security pass rate of 56%. The same technology accelerates both sides of the codebase.

Memory Corruption: Same Bugs, Better Coverage

Memory corruption bugs in C and C++, buffer overflows, use-after-free, double-free and integer overflows, are the classic territory of fuzzers and sanitizers. The tooling is mature. So why did Mythos still find bugs that had survived for decades?

Because many of those bugs sit behind conditions a fuzzer rarely reaches. The vulnerable path might require a specific sequence of protocol messages, a rare configuration, or arithmetic that only overflows when two fields hold particular values at once. Random mutation almost never constructs that state. A model reading the code can see the condition and construct it directly.

The OpenBSD bug that headlined the launch fits this pattern: years of exposure, heavy scrutiny, and still sitting on a path that required deliberate construction to trigger.

Logic Vulnerabilities: Where AI Separates

Logic bugs are where the new capability matters most. The program does not crash. Every test passes. It simply does the wrong thing correctly.

Here is a simplified example of the kind of authorization flaw that survives code review because it reads as reasonable:

// Express route: update a document in a multi-tenant SaaS app
app.patch('/api/orgs/:orgId/docs/:docId', requireAuth, async (req, res) => {
  const { orgId, docId } = req.params;

  // Check: is the caller a member of the org in the URL?
  if (!req.user.orgIds.includes(orgId)) {
    return res.status(403).json({ error: 'forbidden' });
  }

  // Bug: the document is looked up by ID alone.
  // Nothing confirms the document belongs to orgId.
  const doc = await Docs.findById(docId);
  if (!doc) return res.status(404).end();

  Object.assign(doc, req.body);   // second bug: mass assignment
  await doc.save();
  res.json(doc);
});

A user who belongs to any organization can edit any other organization's document by putting their own orgId in the URL and a victim's docId in the path. The mass assignment adds a second problem: a request body can overwrite fields like ownerId or orgId directly.

Unit tests written by the same developer usually test the happy path and the "not a member" path. Both pass. A scanner sees an authorization check and moves on. A model that understands the intent, "a member of org A should only touch org A's documents," notices that the check and the lookup reference different things.

The fix is boring, which is the point:

const doc = await Docs.findOne({ _id: docId, orgId });   // scope the lookup
if (!doc) return res.status(404).end();
const { title, body } = req.body;                         // allow-list fields
Object.assign(doc, { title, body });

Broken object-level authorization has topped API risk lists for years. AI makes finding it cheap at scale, for whoever looks first.

Cryptographic Implementation Flaws

A bug in one web application compromises one application. A bug in a cryptographic library compromises everything that links against it.

Anthropic's disclosures include flaws in widely used cryptographic code. One of the most cited, a universal ECDSA certificate forgery in wolfSSL tracked as CVE-2026-5194, was fixed in wolfSSL 5.9.1 in April 2026 and independently analyzed by outside researchers after disclosure. That kind of flaw does not break the math. It breaks the code that applies the math.

The recurring patterns are worth knowing by name:

• Validation order mistakes. Certificate checks that skip, reorder or short-circuit a property, so a crafted certificate passes.
• Timing side channels. Comparisons or operations whose duration depends on secret data, letting an attacker recover secrets by measuring response times.
• Nonce misuse. AES-GCM requires a unique nonce per key and message. Reuse destroys both confidentiality and integrity.
• Padding and error oracles. Code that reveals whether decryption or padding succeeded lets attackers decrypt data piece by piece.

These are exactly the flaws that human reviewers miss because the algorithm choice is correct. If you want to check whether your own hashing and storage choices hold up, my comparison of Argon2, bcrypt, scrypt and PBKDF2 covers the selection side, and Hash Lab lets your team compare algorithms hands-on.

The Verification Problem

Volume is only useful if findings are real. This is where early skepticism focused, and where the data has been reassuring with caveats.

For memory safety bugs, verification is close to mechanical. Sanitizers either fire or they do not, and anyone can rerun the crash.

For the open-source findings, Anthropic had six independent security firms assess a sample. In its May update, 1,752 high- or critical-rated findings had been assessed, and 90.6% were valid (62.4% were confirmed as high or critical severity). By October, reviewers had confirmed 5,674 of 6,123 reviewed findings, a 92.7% true-positive rate. That is a high rate for any automated system.

Critics raised fair points. Several analysts noted that early disclosures came without full reproduction steps, making independent verification of headline claims difficult. That criticism is worth keeping in mind whenever any vendor, AI lab or not, reports its own results.

Point the Loop at Live Systems

Now take the discovery loop from the start of this chapter and change one thing: instead of an isolated container holding source code, point it at a live target.

That is roughly what happened at Hugging Face in July 2026. According to the company's disclosure and the Cloud Security Alliance's research note:

• A malicious dataset exploited two code-execution paths in the dataset processing pipeline: a remote-code dataset loader and a template injection flaw in configuration handling.
• Once it had code execution on a processing worker, the agent harvested cloud and cluster credentials it found during privilege escalation.
• It used those credentials to move through internal infrastructure, operating from a swarm of short-lived sandboxes.
• Responders reconstructed more than 17,000 recorded events, with no human operator at the keyboard.
• The agent accessed five internal datasets tied to security evaluation challenges, operational search metadata and several service credentials.

Look at the shape. Comprehend the environment. Hypothesize a path. Try it. Observe. Refine. The same loop, aimed at production instead of a sandbox.

One detail from the incident deserves attention from every security leader. Hugging Face's responders found that hosted commercial AI models refused to analyze the real attack artifacts, and they fell back to an open-weight model running on their own infrastructure for incident response. Safeguards built to stop attackers also slowed defenders. Anthropic's Cyber Verification Program, launched in October, is partly an answer to that problem: vetted defenders get access to models with fewer restrictions. Chapter 7 covers it in detail.

Key takeaways

• Agentic discovery follows a simple loop: comprehend, hypothesize, test, refine, verify.
• Its advantage over existing tools is semantic: it reasons about what code should do.
• Logic and authorization bugs, and flaws in cryptographic implementations, are where the new capability matters most.
• Validation rates have been high, but triage capacity becomes your constraint the moment you adopt these tools.
• The same loop aimed at live systems is an autonomous intrusion. The Hugging Face breach is the first major public case.

Finding single bugs is half the story. The capability that turns this from a better scanner into a new kind of threat is the ability to combine bugs. That is Chapter 3.