AI Found 12 Zero-Days In OpenSSL. What Does It Mean For The Industry?

AI Found 12 Zero-Days in OpenSSL. What Does It Mean for the Industry?

Speakers: Ondrej Vlcek, Co-Founder & CEO, AISLE; Adam Krivka, AI Security Researcher, AISLE

Conference: [un]prompted 2026 — The AI Security Practitioner Conference

Date: March 3–4, 2026, San Francisco

Watch on YouTube: https://www.youtube.com/watch?v=IjL2qN1KDe8

Reading time: ~9 minutes

TL;DR

AISLE, a one-year-old security startup, used a multi-stage agentic AI pipeline to discover 12 zero-day vulnerabilities in OpenSSL — including one 9.8-severity stack buffer overflow that some researchers are calling "the new log4j candidate." In six months of active operation, the same engine has found and verified more than 500 vulnerabilities totaling 133 CVEs across open-source software, all while maintaining a false positive rate below 5%.

Introduction

The pattern of vulnerability disclosure presentations at security conferences has been remarkably consistent for decades: a researcher takes the stage, reveals a clever finding, explains the trick, and the audience applauds. What makes AISLE's talk at [un]prompted 2026 different is not the findings themselves — though a 9.8-severity zero-day in OpenSSL would command attention at any conference — but what produced them.

Ondrej Vlcek, who spent more than three decades in cybersecurity including writing one of the original antivirus engines in the 1990s, framed it plainly: "This talk is going to be slightly different, even though we do have some real findings. The point really is not that much about the research itself. It is about the engine that actually allowed us to make those findings."

AISLE, the company Vlcek co-founded roughly a year before the conference, started with a different thesis entirely. The original plan was to build an automated remediation tool — ingest scanner outputs and fix the problems. But when the team ran commercial pattern-matching scanners against 100,000 historical CVEs to benchmark them, they found something alarming: "The efficacy of those scanners were close to zero. Even the historical vulnerabilities, that have been known — all of those were missed."

That discovery redirected the company toward building its own AI-powered discovery engine. What happened next set off a chain of findings that accumulated faster than anyone anticipated.

▶ Watch: Introduction — The Engine Behind the Findings (00:00)

From Benchmark Failure to Accidental Discovery

The commercial scanner failure forced AISLE's team to build an AI-based approach capable of finding the historical CVEs the commercial tools missed. They succeeded — and then the system started finding new ones.

"Our approach could now find vulnerabilities that we were looking for, the historical ones — the kind of gold ones as we call them — but they actually started identifying new vulnerabilities as well," Vlcek explained. "And that's really how we got into this."

The team began reporting findings to open-source maintainers starting around August–September 2025. Six months later, as of the conference:

• 500+ vulnerabilities found, verified, and disclosed
• 133 CVEs minted (a trailing indicator — CVE issuance typically lags months behind disclosure)
• 12 vulnerabilities found in OpenSSL alone
• The OpenSSL findings included one CVSS 9.8 severity stack buffer overflow

Vlcek noted the parallel to Anthropic's recent work: "Same number, coincidentally, five hundred vulnerabilities — that already resulted to about 133 CVEs." At conference time, the CVE count was continuing to grow.

▶ Watch: The Discovery Scale — 500+ Vulnerabilities (06:00)

The Specific Findings: What AI Found That Humans Missed

Adam Krivka, AISLE's AI Security Researcher, walked through several specific examples to ground the discussion.

The OpenSSL 9.8 Stack Buffer Overflow (CVE-2025-15467)

The most serious finding is a stack buffer overflow in a component of the OpenSSL library frequently used in email clients. An attacker can control the length of a field in a data structure notation to cause a stack overflow. Some researchers in the community have called this "the new log4j candidate" — not because of its technical similarity to log4j, but because of its high exploitability potential and the notorious difficulty of finding and patching all OpenSSL instances across a large organization. OpenSSL is everywhere; comprehensive patch deployment is notoriously slow.

The Traefik Logic Bug

Krivka specifically highlighted a Traefik vulnerability as illustrating why pattern-matching scanners fail. The bug involves a configuration flag in Kubernetes deployments where Traefik replaces NGINX as the ingress controller. The flag is intended to enable TLS authentication of the back-end service — but due to a logic inversion in the Go code, setting the flag to true actually disables TLS verification. In the code, if proxySSLVerify { insecureSkipVerify = true } — enabling the "verify" flag turns off verification.

"This is an interesting example of what LLMs can notice," Krivka said. No string pattern would catch this; it requires understanding the semantic intent of the flag name versus the actual effect of the code.

Other Findings

• A Samba CVSS 10.0 remote code execution vulnerability (CVE-2025-10230)
• Remote code execution in npm glob
• 34+ vulnerabilities in OpenClaw, making AISLE one of the most active security contributors to that project

▶ Watch: Specific Findings — OpenSSL, Traefik, and More (06:00)

The Engine: Multi-Stage Progressive Refinement

The key differentiator in AISLE's results is not using AI for vulnerability research — that's not new. Google's Project Naptime (which evolved into Big Sleep) demonstrated AI-driven vulnerability discovery, as did the DARPA/ARPA-H AI Cyber Challenge (42 teams, running 2023–2025, culminating at DEF CON). What sets AISLE apart is the pipeline architecture designed to achieve a sub-5% false positive rate while maintaining deep, novel findings.

The approach has two phases:

Phase 1: Breadth-First Broadening

The system generates as many hypotheses as possible about what could be wrong in a given codebase. At this stage, Krivka noted, the intrinsic knowledge of state-of-the-art models is sufficient to surface "quite deep and sophisticated vulnerabilities" — the models understand common vulnerability patterns, cryptographic protocols, and API contract violations well enough to generate useful leads.

Phase 2: Focused Narrowing

Once a lead is identified, the system does deep agentic exploration: running the code, crafting proof-of-concept exploits, fuzzing where applicable, and applying soft and hard verification checks. Multiple models assess each other's conclusions, "emulating the scenario where you would have a dedicated team of security engineers looking at the issue with different background skills and knowledge, and generating some informed consensus."

Key engineering principles Krivka outlined:

• Heavy parallelism — Unlike humans (who are "mostly single-threaded"), AI agents can investigate dozens of hypotheses simultaneously.
• Careful context construction — The codebase understanding improves through successive phases, with increasingly optimized context provided to LLMs at each stage.
• Human-in-the-loop at finalization — "We still have human-in-the-loop, especially in the final submission phase, though more and more we find that this is kind of a formal check."
• Specialized fine-tuned models — Experiments with models fine-tuned specifically for vulnerability research are ongoing.
• Robust sandboxed runtimes — Secure execution environments for running proof-of-concept code during verification.

▶ Watch: The Multi-Stage Discovery Pipeline (12:01)

The "No AI Slop" Principle

A theme running through the entire talk — and explicitly stated in both the slides and the Q&A — was AISLE's commitment to what they call "no AI slop." The open-source community is overwhelmed by AI-generated false positive vulnerability reports that add work to already resource-constrained maintainers without actually improving security.

Vlcek described learning this the hard way: "Especially with open source, there is this fine balance between sort of being useful but not really adding work to those already overworked people who do this basically in their free time."

The practical consequence is that AISLE always provides maintainers with the full contextual information they need to verify a finding, including a proposed fix. The sub-5% false positive rate is not just a technical achievement — it's a community relations strategy.

The impact is visible in changed minds. Daniel Stenberg, the original author of curl and a vocal critic of AI-generated security noise, had been publicly blogging about "AI slop" — bad AI vulnerability reports — for years. After receiving AISLE's reports, Stenberg "turned from a complete skeptic and naysayer to AI, to a huge fan and to someone who goes to conferences and talks about this publicly." Matt Caswell, CEO of the OpenSSL Foundation, similarly expressed strong endorsement of the quality of AISLE's findings.

▶ Watch: The No AI Slop Commitment and Community Impact (10:01)

The GitHub Bot and Commercial Product

AISLE's primary user-facing product is a GitHub bot that scans pull requests in real time, checking every new code change for security issues before it reaches production. As of the conference, the bot is in active use by:

• OpenSSL — every PR reviewed
• OpenClaw — every PR reviewed
• OpenEMR — healthcare software
• Apache ecosystem

Vlcek announced at the conference that the bot is now available to the general public at isle.com. The product works for both open-source and proprietary code repositories.

"The amount of code that's being added or modified in those repos is very, very large" with AI-generated code proliferation, Vlcek noted. Being present in the development pipeline — scanning before code reaches production — is essential given the pace at which AI coding assistants are producing new code.

▶ Watch: The GitHub Bot and Product Announcement (18:01)

The Industry Implications: A Fragile Equilibrium

The final section of the talk turned to consequences for the broader security industry. Vlcek's assessment was direct: AI has now demonstrated it can find real vulnerabilities in "the most hardened, well-audited codebases on the planet." But the same technology is available to adversaries.

"The bad guys, the bad actors, have access to that same technology as well, or even more so — they can be even more token heavy. Nation-state actors have almost unlimited resources when it comes to things like that, and it is already being weaponized."

The word used multiple times in the talk by multiple speakers across the day — "vuln-pocalypse" — captures the fear: a sudden surge of AI-discovered zero-days being exploited faster than the security community can patch them.

Vlcek's position: AI will ultimately advantage defense, but only if defenders move urgently. "We only prevent the vuln-pocalypse if we move with urgency and move very fast to really preempt the bad guys from exploiting those vulnerabilities."

▶ Watch: Industry Implications and Call to Action (20:01)

Notable Quotes

"The efficacy of those commercial scanners were close to zero. Even the historical vulnerabilities, that have been known — all of those were missed."

"CVE-2025-15467 — some researchers have called it 'the new log4j candidate' — because of the high exploitability potential, and notorious difficulty of finding and patching all OpenSSL instances across an organization."

"AISLE discovering vulns ... in ways no other tools previously could find. Sometimes it feels like magic."

"It is imperative that we all move with urgency and at max speed — otherwise, we're risking an unprecedented flurry of new zero-day exploits."

"Despite that, we believe that AI will ultimately advantage defense."

Key Takeaways

• Commercial pattern-matching scanners miss nearly all known vulnerabilities. When AISLE benchmarked them against 100,000 historical CVEs, efficacy was close to zero — a finding that redirected the company toward building its own AI-based discovery engine.
• Multi-stage agentic pipelines with multi-model cross-verification achieve sub-5% false positive rates. Breadth-first hypothesis generation followed by focused agentic exploration is the architecture that makes AI vulnerability research trustworthy enough for real open-source maintainers.
• Logic bugs and semantic inversions are uniquely visible to LLMs. The Traefik TLS flag inversion — where enabling "verify" actually disabled verification — is the type of finding that no pattern-matching tool can detect; it requires understanding code intent.
• "No AI slop" is both a technical and ethical commitment. Flooding under-resourced open-source maintainers with false positives undermines the security ecosystem. High precision is a community responsibility.
• The offensive/defensive equilibrium is fragile and urgent. Nation-state adversaries have access to the same AI capabilities. Defenders must move at maximum urgency to scan and patch before those capabilities are weaponized.

Slides Reference

Slides available: 2026-04-04-D1-S2-16-55-AI-Found-12-Zero-Days-In-OpenSSL-What-.pdf

Key slide topics include: The OpenSSL 9.8 stack buffer overflow (CVE-2025-15467) and "new log4j candidate" comparison; scale statistics (500+ total vulnerabilities, 125+ CVEs at time of slides); the Samba CVSS 10.0 RCE and npm glob RCE findings; 34+ OpenClaw vulnerabilities; AISLE's core pipeline (breadth-first broadening → focused narrowing) with multi-agentic workflows, soft and hard verifications, and sandboxed runtimes; the GitHub bot announcement and current OSS project integrations (OpenSSL, OpenClaw, OpenEMR, Apache); and the industry equilibrium slide on defensive vs. offensive AI usage.