AI has made finding vulnerabilities cheap. Exploiting them easier. Fixing them is still expensive.

For CPOs, CISOs, CIOs and CEOs, the gap between finding and fixing is where the risk now lives.

Discovery got an upgrade. Remediation didn’t.

In its first month, Anthropic’s Project Glasswing pointed a frontier model, Claude Mythos Preview, at partner systems and open-source code and surfaced more than 10,000 high- or critical-severity vulnerabilities. By Anthropic’s May 22, 2026 update, 530 of the high- and critical-severity open-source bugs had been reported to maintainers. Only 75 had been patched.

That ratio is the story of application security in 2026. Finding vulnerabilities has become a compute problem. Fixing them is still a people problem, and people don’t scale on the same curve as GPUs.

As findings explode, fixing them at the speed of code change can’t stay a people problem.

Four forces, one storm

Four changes are arriving at the same time, and each one makes the others worse.

1. More code, less visibility. Claude Code, Cursor, OpenAI Codex and GitHub Copilot let teams ship more code than anyone can read line by line. Velocity went up. Vulnerabilities shipped right along with it.
2. Novel vulnerabilities with no CVE. Frontier models reason across code paths and find flaws before they reach any public database. The absence of a CVE no longer means the absence of risk as undisclosed vulnerabilities pile up.
3. Faster exploitation of known flaws. In 2024, University of Illinois researchers showed that a GPT-4 agent could exploit 87% of 15 real one-day vulnerabilities when given the CVE description. Unsurprisingly, Mandiant’s M-Trends 2026 now puts mean time to exploit at an estimated −7 days: exploitation routinely starts before a patch exists.
4. Shrinking compliance windows. On May 25, 2026, CERT-In set indicative timelines of 12 hours to contain or remediate known exploited vulnerabilities on internet-facing and crown-jewel systems, 1 day for critical externally exposed flaws, 3 days for critical internal ones and 5 days for high severity. In the EU, the Cyber Resilience Act has required a 24-hour early warning for actively exploited vulnerabilities since September 11, 2026.

The board is asking a different question

For a decade, the AppSec question was “How many findings do we have?” Prioritization tools answered it, mostly by producing well-argued reasons why most findings could wait.

That approach assumes reachability and exploitability hold still. They don’t. Every commit can change what’s reachable, and every new model changes what’s exploitable. The question leadership now asks has three parts:

1. Which findings are actually exploitable in our environment?
2. How quickly can we patch them without breaking the application?
3. What proof do we have that the exploit is closed?

A severity score answers none of these. A reproduced exploit, a patch and a re-run of that exploit against the patch answer all three.

The only constant is the next model

Mythos won’t be the last frontier model. Better models will keep arriving, each with different strengths in code reasoning, exploit generation, context handling and remediation. There are already better frontier models that can ‘find’ at a cheaper cost. Committing a security program to one model is like having a single friend.

The lasting capability is model flexibility: bringing new commercial and open-source models into a controlled workflow and turning whatever they find into verified fixes.

Introducing Frontier Defense

Lineaje Frontier Defense™ is an AI-native security intelligence engine that continuously discovers novel vulnerabilities, validates exploitability, generates verified exploits, creates compatible patches, and verifies successful remediation at scale. Frontier Defense adds an autonomous, multi-agent AI harness that orchestrates the discovery, validation, verification, and remediation of novel vulnerabilities in first-party code. It leverages multiple frontier AI models, such as Opus and Fable, with Mythos where access allows, to continuously assess code in any Git repository.

Lineaje Frontier Defense overlays the AppSec tools you already run, including SAST, SCA and container scanners, and adds frontier-model scanning where you don’t have it. The job is simple to state: take vulnerable code in and send verified patches out.

Under the hood, an autonomous harness spins up and tears down nine isolated AI sandboxes. Each stage of the pipeline has three roles:

1. Create: discover the vulnerability, write a working exploit, draft a patch.
2. Judge: score severity and impact of the vulnerability, drop false positives and duplicates, judge if an exploit is closed when a patch is created, and then review the patch for regressions.
3. Verify: confirm the flaw at runtime, reproduce the exploit reliably, then re-run it against the patched code until it no longer works.

Exploits are detonated in gVisor-based, network-isolated, single-use containers with no egress, and memory-safety exploits are confirmed with ASAN-instrumented crash validation. The patch loop iterates up to five times per finding. Humans are needed at one point: approving the pull request.

Case study: WordPress 6.9.4

WordPress is one of the most widely deployed and most scrutinized PHP codebases, which makes it a hard test. We scanned the WordPress 6.9.4 source (GitHub tag, March 11, 2026) and the official wordpress:6.9.4 container image from Docker Hub.

Source code: 246 alerts in, 4 verified findings out

A standard SAST ruleset raised 246 alerts: 193 in PHP, 50 in JavaScript, 2 in package-manager configuration and 1 in the Dockerfile. Without triage, that’s 246 tickets for developers. Frontier Defense checked every one.

Table 1. WordPress 6.9.4 SAST alerts after Frontier Defense adjudication. The full per-alert record, with verifier reasoning, is available on request.

That’s 98.4% of the noise closed with a written reason, not a suppression flag. A typical example: the unlink-use rule fired 58 times. Frontier Defense traced whether a caller could ever control the deleted path. It can’t. WordPress passes the name through basename() and wp_tempnam(), so an input of ../../etc/passwd becomes /tmp/passwd-<random>.tmp. The file you wanted to delete stays exactly where it is.

The 4 verified alerts reduce to 2 distinct weaknesses, both of which Frontier Defense exploited, patched, and re-tested.

Weakness 1: credentials sent in cleartext (CWE-319, LVE-5151)

A WordPress core component can transmit administrator credentials and file contents without encryption under a common configuration. An attacker on the network path can read both. Three separate SAST alerts pointed at this one weakness.

The fix: Frontier Defense reproduced the exploit, generated a patch, and re-ran the exploit against it: closed, with normal operation unaffected. We reported the issue to the WordPress security team. We’ll publish technical details once coordinated disclosure is complete.

Weakness 2: the container runs as root (CWE-250, LVE-5434)

The container definition inherits the root user from its PHP base image and never sets a USER directive, so the application process runs as UID 0. Container root isn’t automatically host root, but it turns any other bug in the stack into full control of the container, and it amplifies every misconfigured mount or excess capability. Everyone who deploys that container inherits the problem.

The fix: a single line, USER www-data, before the container starts. After the rebuild, the exploit could not regain root.

Container: 156 CVEs the source scan never sees

The source code isn’t the whole attack surface. The official wordpress:6.9.4 image carries 156 critical, high or exploitable CVEs in its operating system packages and runtime utilities, none of which appear in a scan of WordPress’s own code. Frontier Defense fixed all 156 automatically, using Lineaje Gold Open Source packages.

Table 2. The developer’s view, before and after.

All fixes land in a fix branch, each followed by a build and test run to confirm the application still works. The pull request is raised only after every fix passes. (Because WordPress was scanned from its public repository, the pull request was produced as a sample rather than submitted.)

SAST handed developers 246 tickets. Frontier Defense handed them 2 real problems, already fixed.

The broader data: 29 projects, zero clean ones

WordPress isn’t an outlier. Across 29 Python, Java, and C++ projects, Frontier Defense produced these results:

Table 3. Frontier Defense results across 29 projects.

Three numbers in that table matter most:

1. 0 of 29 projects came back clean. Every one had at least one novel vulnerability, averaging 5.7 per project.
2. 52% of novel findings did not survive judging as reachable or exploitable. That’s half the queue your developers never have to see.
3. 21 patches closed 22 exploits. One well-placed fix often closes several exploit paths, which is where most of the developer time goes back.

Across the CVEF, Lineaje customers eliminate 85% of developer toil on vulnerability remediation.

What makes Frontier Defense different

1. Bring your own model. Anthropic, OpenAI, Llama, Gemini, Gemma, OpenRouter and Bedrock are supported, along with LLM-based vulnerability detection platforms. Select a model, select a project, and Frontier Defense does the rest.
2. Runtime proof, not probability. Every exploit is detonated in an isolated, single-use sandbox with no network egress.
3. Verified patch closure. The original exploit is re-run against the patched code until it can no longer be reproduced.
4. Evidence-backed pull requests. Each PR includes the vulnerability details, exploit evidence, patch diff, verification result, and audit trail.
5. One lifecycle view. Novel vulnerabilities, verified exploits, patches, false positives, and PR status are tracked across every model run, with duplicates removed between runs.
6. Disclosure-ready. Immutable evidence repositories and VEX and CSAF support through Lineaje XBOM Manager let you manage what you share with customers, auditors, and regulators.
7. Deploy where your code lives. Lineaje SaaS, your cloud, on-premises, or hybrid. In hybrid mode, code and scan execution never leave your environment; only findings metadata reaches the control plane.

The mandate: eliminate exploitable risk at AI speed

AI has compressed the time between discovery and exploitation, and regulators have compressed response windows to match: 12 hours in India, 24 in the EU. The operating model has to compress with them: test continuously with frontier models, verify what’s exploitable, patch what matters, and keep the proof for engineering, customers, auditors and regulators.

Frontier Defense is built for that model. Point Frontier Defense at one project and see how quickly your team moves from vulnerable code to verified, evidence-backed patches.

Try it. Eliminate exposure in your first-party code at the speed of AI.

Sources

1. Anthropic, “Project Glasswing: An initial update,” May 22, 2026. https://www.anthropic.com/research/glasswing-initial-update
2. Fang et al., “LLM Agents can Autonomously Exploit One-day Vulnerabilities,” 2024. https://arxiv.org/abs/2404.08144
3. Google Cloud (Mandiant), “M-Trends 2026: Data, Insights, and Strategies From the Frontlines,” 2026. https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026/
4. Infosecurity Magazine, “India’s CERT-In Sets 12-Hour Patch Deadline for Exposed Flaws,” 2026. https://www.infosecurity-magazine.com/news/cert-in-12-hour-patch-deadline-ai/
5. WordPress 6.9.4 source. https://github.com/WordPress/WordPress/tree/6.9.4
6. Official WordPress container image, 6.9.4 tags. https://hub.docker.com/_/wordpress/tags?name=6.9.4

WordPress and 29-project results are from Lineaje's internal assessment

‍