---
title: "AISLE Found 12 Zero-Days in OpenSSL. FENRIR Found 100+ More. What AI-Discovered Vulnerabilities Mean for Defenders"
description: "AI-discovered zero-days from AISLE and FENRIR are not a new threat category - they are a volume problem your triage process must handle without panic or shortcuts."
author: "Renn Calloway"
category: "Red Teaming & Offensive Research"
date: 2026-09-19T07:59:58.229Z
canonical: "https://agenticcyber.co/blog/aisle-found-12-zero-days-in-openssl-fenrir-found-100-more-what-ai-discovered-vul-6v12"
---

# AISLE Found 12 Zero-Days in OpenSSL. FENRIR Found 100+ More. What AI-Discovered Vulnerabilities Mean for Defenders

![Empty data center corridor with rows of server racks, amber fault indicator lights blinking along the left side, glossy refle](https://hsppuvezyxmkpzkgfkho.supabase.co/storage/v1/object/public/media/enrichment/5bc07ae2-9ee0-46b9-9820-b0704936f742/7cbce184-9b5a-4fd1-93e2-061858bc8256/4e055178-a03a-43e4-8305-52f8d875f3d9.jpg)

> AI-discovered zero-days from AISLE and FENRIR are not a new threat category - they are a volume problem your triage process must handle without panic or shortcuts.

Your agent's vulnerability triage process is not a security boundary. It never was - and [AI-discovered zero-days](/blog/anthropics-nicholas-carlini-on-how-llms-are-already-finding-zero-days-humans-mis-6myz) are about to make that gap visible in ways you cannot ignore.

When AISLE surfaced 12 zero-days in OpenSSL and FENRIR extended that to 100+ additional findings, the immediate organizational reflex in most security teams was predictable: escalate, panic, and treat "AI-discovered" as a new threat category requiring special handling. That reflex is wrong, and acting on it will cost you more than the vulnerabilities themselves.

## The Misconception: AI-Discovered Vulnerabilities Are a Threat Category You Cannot Control

  ![](https://images.unsplash.com/photo-1723546715348-672653396caa?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w4OTQwNjJ8MHwxfHNlYXJjaHwxfHxUaGUlMjBNaXNjb25jZXB0aW9ufGVufDF8fHx8MTc4OTgwMzY5M3ww&ixlib=rb-4.1.0&q=75&w=960&auto=format)
  Photo by [Jametlene Reskp](https://unsplash.com/@reskp) on [Unsplash](https://unsplash.com)

The flawed assumption runs like this: because AISLE and FENRIR found these vulnerabilities using AI methods that operate faster and at greater depth than human researchers, the resulting CVEs represent something categorically different - a class of threat that bypasses traditional vulnerability management because the discovery process itself is alien to us.

This assumption has a clear origin. Legacy vulnerability management was built around human-paced discovery: code review, fuzzing campaigns, responsible disclosure timelines measured in weeks or months. Security teams learned to operate within that cadence. The threat model assumed you had time to absorb findings, assess them, and patch in a reasonably ordered sequence. AI-assisted discovery breaks that cadence assumption, and teams are pattern-matching to the wrong conclusion - that a broken cadence means a broken threat model.

The organizational behavior this produces is specific and damaging. Teams deprioritize understanding *how* AISLE or FENRIR found the vulnerabilities and instead focus on volume management: "We have 100 new CVEs, how do we get that number down?" That framing treats discovery method as a proxy for severity. It is not. You end up chasing patch counts while the two or three actually exploitable findings in that list sit unaddressed because they looked similar to the 97 that require preconditions you will never see in production.

## Where This Breaks in Production: The False Equivalence Between Discovery Method and Threat Severity

Walk through what actually happens when AISLE publishes 12 zero-days in OpenSSL. A defender reads the CVE list. Without a systematic triage process, the natural response is to assume all 12 are equally exploitable, equally impactful, and equally urgent. That assumption is operationally incorrect in almost every case.

Some of those 12 findings will require attacker-controlled input at a specific function call depth. Some will require the library to be compiled with a particular flag. Some will require a race condition that is theoretically possible but nearly impossible to trigger reliably in a live service. The CVE number does not tell you any of this. The discovery method tells you nothing about this either. AISLE found it faster than a human researcher would have - that is the only thing the discovery method tells you.

Threat actors will use AI-discovered vulnerabilities. Not because the discovery method is novel, but because the vulnerabilities are real. The acceleration is symmetric: the same capability that let AISLE find 12 OpenSSL zero-days can, in principle, let an offensive operator find exploitable paths faster too. Peter Girnus and the team at [Trend Micro's Zero Day Initiative](https://www.zerodayinitiative.com/) have been documenting exactly this dynamic - AI tools are being applied across the vulnerability lifecycle, from discovery through exploitation research. The correct response is not to treat AI discovery as a separate threat track. It is to tighten the triage process that should already exist.

## The Corrected Mental Model: Discovery Method Is Orthogonal to Exploitability

State this plainly and do not soften it: the discovery method is orthogonal to severity, exploitability, and impact. Whether AISLE, FENRIR, or Adam Krivka sitting at a desk with a debugger found a vulnerability, your triage process applies identically. The CVE gets a precondition analysis. It gets an exploitability assessment against your specific deployment configuration. It gets a blast radius estimate. Then it gets a priority.

The architectural shift required is not in your patching workflow. It is in how you classify incoming vulnerability data. Instead of maintaining a mental category called "AI-discovered," treat AISLE and FENRIR as scanners - vulnerability scanners with better coverage and higher throughput than what you had before. That reframing is not minimizing the capability. It is accurate. And it routes findings into the process you already have, rather than creating a parallel emergency track that bypasses systematic assessment. For a deeper look at how AI systems surface unexpected attack surfaces, [the latest LLM vulnerability research offers useful framing for agentic AI defenders](/blog/inside-llm-security-flaws-what-the-latest-vulnerability-research-means-for-agent).

Ondrej Vlcek and Adam Krivka's work presented at the [un]prompted conference makes this explicit: AISLE is designed to find real vulnerabilities in real software at scale. The finding quality is high. The volume is high. What that demands from defenders is a triage system that can handle high-volume, high-quality input - not a new threat category, but a more capable intake process.

FENRIR's results reinforce the same point. 100+ findings in OpenSSL sounds alarming until you apply precondition analysis and start collapsing the list. We have been through this exercise. A significant portion of AI-discovered vulnerabilities in mature libraries like OpenSSL require preconditions that your production environment does not expose. That does not mean you ignore them. It means you sequence them correctly.

## Practical Defenses: Building Triage for AI-Accelerated Vulnerability Discovery

  ![](https://images.unsplash.com/photo-1607184023678-63ea486d62cd?crop=entropy&cs=tinysrgb&fit=max&fm=jpg&ixid=M3w4OTQwNjJ8MHwxfHNlYXJjaHwyfHxUaGUlMjBNaXNjb25jZXB0aW9ufGVufDF8fHx8MTc4OTgwMzY5M3ww&ixlib=rb-4.1.0&q=75&w=960&auto=format)
  Photo by [Mike Swigunski](https://unsplash.com/@mike_swigunski) on [Unsplash](https://unsplash.com)

The triage framework has to be capability-based, not volume-based. Here is how we structure it.

First, ingest. AI tool findings - from AISLE, FENRIR, or any custom scanning pipeline - go into a centralized vulnerability management system before anyone makes a priority decision. Platforms like Rapid7 InsightVM, Qualys, or Snyk can ingest findings and apply custom scoring logic. If your platform cannot handle AI-generated findings as a structured data source, that is a gap to fix now, not after the next batch of CVEs arrives.

Second, precondition analysis for every finding. Not every other finding. Every finding. The precondition question is: what has to be true about the attacker's position, the target's configuration, and the runtime environment for this vulnerability to be exploitable? For OpenSSL findings specifically, this means checking your TLS configuration, your library version pinning, and whether the affected code paths are reachable from untrusted input in your deployment.

Third, blast radius. If the preconditions are met and exploitation succeeds, what does the attacker gain? Memory corruption in a sandboxed context is not the same as memory corruption in a privileged process with network access. Score these separately from CVSS base scores, which do not account for your environment. This is exactly the kind of environment-specific risk reasoning that [red-teaming agentic systems at the practitioner level](/blog/how-to-red-team-an-agentic-system-practitioners-methodology) forces you to develop.

The documentation template we use for each finding looks like this:

[Vulnerability ID]
  Preconditions: [what must be true for exploitation]
  Affected Code Paths: [specific functions or modules]
  Exploitability in Our Environment: [yes / conditional / no, with justification]
  Blast Radius: [what an attacker gains on success]
  Patch Available: [yes / no / partial]
  Priority: [P1 / P2 / P3, based on above, not CVSS alone]
  Owner: [team or individual responsible for remediation]
  Detection Coverage: [do we have a SIEM or EDR rule that would catch exploitation attempts?]

The detection coverage field matters more than most teams realize. For findings where patch timelines are long or patches do not exist yet, your ability to detect exploitation attempts is your actual defense posture. Set up alerts for exploitation attempts against known AI-d

## FAQ

### How do I prioritize when I am getting 100+ AI-discovered vulnerabilities at once?

You cannot patch all of them immediately, and you should not try. Volume is not a reason to panic; it is a reason to be systematic. Start with preconditions: for each finding, ask what has to be true about attacker position, target configuration, and runtime environment for the vulnerability to be exploitable in your specific deployment. Many AI-discovered vulnerabilities - including a significant portion of what AISLE and FENRIR surface in mature libraries like OpenSSL - will fail the precondition test for your environment. That collapses the list quickly. From the remainder, apply blast radius analysis: what does an attacker gain if exploitation succeeds? That gives you a defensible priority order that is based on actual risk, not CVE count.

### What if I do not have a formal vulnerability management process yet?

Start minimal. A spreadsheet with columns for CVE ID, affected component, whether you actually use it, exploitability assessment, and patch status is enough to begin. Run one AI scanner against a bounded scope - a single service or library - rather than your entire environment. The goal is to build the habit of precondition analysis before you are dealing with 100+ findings under time pressure. Once you have worked through a small batch systematically, you will have a repeatable process you can scale. Formal platforms like Rapid7 InsightVM or Snyk can come later; the analytical discipline comes first.

### How do I explain AI-discovered vulnerabilities to leadership without sounding like I am downplaying the threat?

The framing that works: AI vulnerability discovery is a capability upgrade, not a threat upgrade. AISLE and FENRIR find real vulnerabilities faster than human researchers could. That is genuinely useful - it means we can find and fix flaws before attackers do, if we have the triage process to handle the volume. The risk is not that AI found these vulnerabilities; the risk is that we do not assess them systematically and miss the two or three that are actually exploitable in our environment. Frame your ask in terms of triage capacity: we need the process and tooling to absorb high-volume findings without losing signal on the ones that matter.

### What if an AI-discovered vulnerability turns out to be unexploitable in practice?

This will happen regularly, and it is not a failure of the discovery process. Some AI-discovered vulnerabilities are theoretical - they require preconditions that are so rare or difficult to meet that exploitation is not a practical concern in production environments. When you complete precondition analysis and determine a finding is not exploitable in your deployment, document that conclusion with your reasoning and close it. Do not leave it open as a hedge. An accurate assessment that closes a finding is more useful than an indefinitely open finding that consumes attention. Revisit closed findings if your deployment configuration changes in ways that alter the precondition analysis.

### How does AI-discovered vulnerability risk change for open-source versus proprietary software?

For open-source software like OpenSSL, you have the source code, which means you can verify preconditions directly - look at the affected function, trace the call path, confirm whether untrusted input can reach it in your configuration. That verification process is concrete and relatively fast. For proprietary software, you are dependent on vendor disclosure for precondition detail, and that detail is often incomplete or delayed. In the proprietary case, lean harder on detection coverage: if you cannot verify exploitability from source, ensure you have behavioral monitoring that would surface an exploitation attempt. The triage framework is the same; the evidence quality differs, and your confidence intervals should reflect that.


---
Source: https://agenticcyber.co/blog/aisle-found-12-zero-days-in-openssl-fenrir-found-100-more-what-ai-discovered-vul-6v12