TL;DR
- Mean time-to-exploit (the gap between a vulnerability existing and attackers using it) has gone from 63 days in 2018 to an estimated -7 days in 2025, per Mandiant's M-Trends 2026 report. Negative means exploitation now typically starts before a patch exists.
- Through Project Glasswing, Claude Mythos was put to work directly against that reality. It surfaced 23,000 vulnerabilities across every major operating system and browser, cracked the core bare-metal security architecture of Apple's most advanced silicon in under five days, and uncovered zero-day flaws inside AWS and Google's cloud dependency stacks.
- Google's Big Sleep (DeepMind + Project Zero) has independently found and helped stop a critical SQLite flaw before it was exploited, and discovered 20 previously unknown vulnerabilities in a single batch in 2025, real, independent confirmation that AI-driven discovery is already outpacing what patch-first defense assumes.
- Median remediation time for critical and high-severity vulnerabilities still sits around 74 days at large organizations, while 45% of known vulnerabilities in large orgs are never remediated at all. The patch cycle isn't just slow; it often doesn't happen.
- Firefly’s answer isn't faster patching; it's recovery capability. Cloud Resilience Posture Management (CRPM) and CAIRS rebuild infrastructure into a clean, isolated environment using immutable IaC snapshots, so recovery doesn't depend on winning a race that's already been lost on average.
Getting Started: What a Zero-Day Actually Is
A zero-day is a vulnerability that's being exploited, or could be exploited, before a fix exists. The name comes from the defender's side of the clock: zero days of warning, zero days to patch before it's already a live problem. That's different from an "n-day" vulnerability, one that's already been disclosed and patched, but still gets exploited against organizations that haven't applied the fix yet.
For most of the last two decades, security programs were built around the assumption that there'd be at least some window between disclosure and exploitation, time to patch, time to test the patch, time to roll it out across a fleet. Project Glasswing was built to test whether that assumption still holds, using Claude Mythos, Anthropic's frontier-tier model, to see exactly how far AI-driven vulnerability discovery has already moved past it. This piece walks through what we found, how it aligns with independently documented industry data, and what a strategy looks like once the patch window can no longer be relied on.
What We Found Through Project Glasswing
Project Glasswing put Claude Mythos to work against real infrastructure at scale, and the results were decisive. It surfaced 23,000 vulnerabilities across every major operating system and browser. It cracked the core bare-metal security architecture of Apple's most advanced silicon in under five days. It uncovered zero-day flaws hidden deep inside the cloud dependency stacks at AWS and Google, the kind of hardened, high-value infrastructure that's supposed to be the hardest place to find something nobody else has already found.
That result answers a specific question directly: if AI-assisted offensive security research continues to accelerate as Project Glasswing demonstrates, is patch-first defense still a sufficient strategy on its own? The independently reported industry data in the next section says no, and it says so without relying on Project Glasswing's numbers at all.
The Industry Data Confirms the Same Trend
Google's Big Sleep, a collaboration between Google DeepMind and Google Project Zero, is a separate, independently documented example of the same underlying shift. In November 2024, Big Sleep found its first real-world vulnerability, a stack buffer underflow in SQLite, before the flawed code was even publicly released. In July 2025, it identified CVE-2025-6965, a critical SQLite memory-corruption flaw Google described as "known only to threat actors and at risk of being exploited," and the discovery let Google patch it before it was exploited, the first documented case of an AI agent directly foiling an in-progress exploitation attempt. A month later, Big Sleep found CVE-2025-9478, a use-after-free vulnerability in Chrome's ANGLE graphics library, and by August 2025 it had found 20 previously unknown vulnerabilities in a single batch across projects including FFmpeg and ImageMagick.
Big Sleep and Project Glasswing arrived at the same conclusion from two different directions: AI-driven vulnerability discovery isn't a research demo anymore; it's already finding flaws human researchers miss, at a pace that's reshaping what "patch-first" defense can realistically promise.
Why the Patch Cycle Can't Keep Up in Real Numbers
Mandiant's M-Trends 2026 report, drawn from more than 500,000 hours of incident response work conducted in 2025, is the most current large-scale dataset on this question, and the trend line is stark. Mean time-to-exploit tracked by the Google Threat Intelligence Group has moved from 63 days in 2018 to roughly 5 days in 2023, to -1 day in 2024, and to an estimated -7 days in 2025. A negative number means that exploitation is already underway, on average, before a patch is publicly available.
This isn't an isolated data point. Exploitation of vulnerabilities has been the single most common initial infection vector in Mandiant's incident response caseload for six consecutive years, accounting for 32% of intrusions with a root cause attributable in 2025. Verizon's 2025 Data Breach Investigations Report found that exploitation of vulnerabilities now accounts for 20% of all breaches, a 34% year-over-year increase. CrowdStrike's 2026 Global Threat Report separately documented a 42% increase in zero-day vulnerabilities exploited before public disclosure.
The other half of the problem is that even the vulnerabilities organizations do know about often don't get fixed quickly, or at all. Median remediation time for critical and high-severity vulnerabilities at large organizations is around 74 days, and roughly 45% of known vulnerabilities are never remediated. Put those two numbers together with a negative time-to-exploit, and patch speed stops being a meaningful defense on its own, not because patching doesn't matter, but because the race it depends on winning is one the data says defenders are already losing on average.
What This Actually Looked Like in 2025
Google's Threat Intelligence Group tracked 90 zero-day vulnerabilities exploited in the wild during 2025, with 48% targeting enterprise technologies specifically, an all-time high share for that category. Three of the most frequently exploited vulnerabilities in Mandiant's 2025 caseload make the pattern concrete rather than abstract: CVE-2025-31324 (SAP NetWeaver Visual Composer), CVE-2025-61882 (Oracle E-Business Suite), and CVE-2025-53770 (Microsoft SharePoint, nicknamed "ToolShell"). All three share the same profile: unauthenticated, internet-exposed enterprise platforms, each exploited as a genuine zero-day before any vendor patch existed, then weaponized at scale as an n-day by multiple separately tracked threat clusters once the patch made the vulnerability's shape public.
That pattern, a handful of sophisticated actors moving first while a patch doesn't exist, followed by a much wider wave of opportunistic exploitation once it does, is why median dwell time (how long an attacker sits inside an environment before being detected) still runs around 14 days industry-wide, and considerably longer for espionage-motivated intrusions specifically. A zero-day doesn't need to be exploited by everyone on day one to cause damage; it needs to be exploited by someone quietly enough, for long enough, before detection catches up.
The Supply Chain Angle: When the Zero-Day Isn't in Your Code
Cloud-native environments add a wrinkle that pure endpoint or browser security doesn't have to deal with as directly: most production infrastructure depends on a long chain of third-party modules, providers, and packages that a platform team didn't write and often hasn't fully audited. Malicious packages published to public repositories reached 454,600 in 2025, up 726% from roughly 55,000 in 2022. A zero-day doesn't have to exist in an organization's own code to become that organization's incident; it just has to exist somewhere in the dependency graph a Terraform module, a container base image, or a CI/CD pipeline step pulls in automatically.
This is precisely why "what's actually running, and what does it depend on" is as important as "is it patched." A vulnerability discovery process, whether it's Project Glasswing, Big Sleep, or anything else, is only useful to a defender if there's an accurate, current map of every resource and dependency it could apply to. An environment with a large percentage of undocumented or unmanaged infrastructure has no reliable way even to ask "are we exposed to this," regardless of how fast the fix is available. That map has to extend beyond cloud infrastructure, too: Firefly’s own inventory scope covers AWS, Azure, GCP, and Kubernetes, along with more than 14 connected SaaS applications, since a vulnerable dependency is just as likely to sit in a connected identity provider or CI/CD tool as in a Terraform module.
Reconstructing exactly when a vulnerable configuration was introduced is worth answering just as directly. Firefly’s Codify Revision capability lets a team select a past point in time on a resource's mutation log and generate the IaC exactly as it existed at that moment, turning "when did this drift into its current, vulnerable state" from a manual log-diffing exercise into a direct query against the resource's own history.
What Recovery Actually Looks Like: A Worked Example
Take CVE-2025-53770, the SharePoint flaw discussed in the section above, as a concrete example. Two organizations are both hit in the same week the exploit goes public. The first has SharePoint running on infrastructure that was never fully codified; nobody has a current record of every dependent resource, so the incident response team spends the first several hours just establishing what's actually connected to the compromised server before they can even plan a clean rebuild. The second has that same environment continuously scanned and mapped, with a Resiliency score that already flagged any recovery-blocking gaps before the incident happened.
For the second organization, recovery doesn't start with discovery; it starts with a decision: restore from the last known-good snapshot into a clean, isolated account, using the dependency graph already in place rather than one assembled under pressure. That's the practical difference between "recoverable" as a claim and "recoverable" as a number checked continuously, and it's the gap that Project Glasswing's own numbers make more urgent to close, not less.
From Prevention to Recovery: Why the Strategy Has to Shift
None of this means prevention stops mattering. Encryption, least-privilege IAM, network segmentation, and patching, where it's still possible, all reduce the odds and the blast radius of a given incident. But a strategy that depends entirely on prevention holding is now betting against data that says the prevention window has, on average, already closed by the time a patch ships.
That's the practical argument for treating recovery capability as a first-class part of a security strategy rather than an afterthought bolted onto disaster recovery planning. If an organization can't reliably prevent every compromise, and the data says it increasingly can't, the variable actually within its control is how fast and how cleanly it can rebuild once something gets through. That's a different question from "did we patch in time," and it's the one we built Firefly to answer.
How Firefly Operationalizes a Recovery-First Strategy
Firefly’s answer to this shift centers on two capabilities: Cloud Resilience Posture Management (CRPM) for visibility into how recoverable an environment actually is, and CAIRS (Cloud Application Infrastructure Recovery), the rebuild mechanism itself, a category Gartner has recognized us in directly.
CRPM scores the environment against built-in resiliency policies under the Firefly Governance dashboard, things like missing snapshot policies, S3 buckets without Object Lock, or RDS clusters skipping final snapshots on deletion, the specific configurations that would block a clean recovery if an incident hit today. That score is continuous, not a point-in-time audit result, so a team knows before an incident, not during one, which parts of the environment would actually fail to come back.
When recovery is actually needed, Firefly doesn't restore into the same compromised account or region, which would often mean restoring straight back into an attacker's continued reach. Recovery rebuilds into a clean, isolated region or account using immutable, versioned IaC snapshots. The immutability isn't just a label; it has a specific mechanical effect: a snapshot stored this way can't be modified or deleted by the same credentials that manage production, so an attacker who has fully compromised a production account, including its IAM roles and admin access, still has no path to reach or corrupt the recovery snapshot sitting outside that blast radius. Ransomware that encrypts everything it can access in production simply can't encrypt what was never within its reach to begin with. Every restore generates Terraform and routes it through a pull request, rather than making direct cloud API calls, so the rebuilt environment is reviewable and auditable, not a black-box emergency action.
A Resiliency check that catches a backup configuration exposed to this exact risk, a snapshot repository still reachable by the same account that could be compromised, looks like this:
package Cx
import data.generic.common as common_lib
import data.generic.terraform as tf_lib
CxPolicy[result] {
resource := input.document[i].resource.aws_backup_vault[name]
resource.iam_role_arn == input.production_account_role_arn
result := {
"documentId": input.document[i].id,
"resourceType": "aws_backup_vault",
"resourceName": tf_lib.get_resource_name(resource, name),
"searchKey": sprintf("aws_backup_vault[%s].iam_role_arn", [name]),
"issueType": "IncorrectValue",
"keyExpectedValue": sprintf("aws_backup_vault[%s].iam_role_arn should differ from the production account role", [name]),
"keyActualValue": sprintf("aws_backup_vault[%s].iam_role_arn matches the production account role, defeating isolation if that account is compromised", [name]),
"searchLine": common_lib.build_search_line(["resource", "aws_backup_vault", name], []),
"remediation": json.marshal({
"before": "shared IAM role with production",
"after": "dedicated IAM role scoped to backup vault only",
}),
"remediationType": "replacement",
}
}Firefly targets an RTO (recovery time objective) under one hour for this recovery process, even mid-incident. For teams that want to check recovery readiness without waiting for an incident to force the question, AI SRE answers questions like "which of our production applications would fail to recover cleanly right now" by cross-referencing Inventory, Governance, and Backup & DR data directly, turning "are we recoverable" from an assumption into a number that gets checked continuously.
Where Should You Start With This
Checking actual recovery readiness beats debating patch speed in the abstract. The Mandiant data is clear that the discovery-to-exploitation window keeps shrinking, which makes the more useful question not "how fast can we patch" but "if prevention fails today, how fast and how cleanly do we actually come back?" Explore the Firefly Governance dashboard to see that number for a live environment, or read more about Project Glasswing directly.
FAQs
What is a zero-day vulnerability?
A zero-day is a vulnerability that is being exploited or exploitable before a fix exists, meaning defenders have had zero days of warning to patch it. This differs from an n-day vulnerability, which has already been disclosed and patched but still gets exploited against systems that haven't applied the fix.
What is time-to-exploit and why has it gone negative?
Time-to-exploit (TTE) measures the gap between a vulnerability existing and attackers first exploiting it. Mandiant's data shows this has fallen from 63 days in 2018 to an estimated -7 days in 2025, meaning exploitation now typically begins before a patch is even publicly available, largely driven by faster vulnerability research and exploit development on the attacker side.
Is AI actually being used to find real vulnerabilities today?
Yes. Project Glasswing’s work with Claude Mythos surfaced 23,000 vulnerabilities across major operating systems and browsers. Independently, Google's Big Sleep found a critical SQLite vulnerability before it could be exploited, discovered a Chrome use-after-free flaw, and identified 20 previously unknown open-source vulnerabilities in a single batch, all in 2025.
What did Project Glasswing find using Claude Mythos?
Project Glasswing surfaced 23,000 vulnerabilities across every major operating system and browser, cracked the core bare-metal security architecture of Apple's most advanced silicon in under five days, and uncovered zero-day flaws inside AWS and Google's cloud dependency stacks.
If patching can't keep up, what should security teams actually do?
Prevention controls still reduce risk and should stay in place, but a strategy solely dependent on patching winning a race that the data shows is now typically lost needs a recovery-focused complement: knowing in advance which systems can be cleanly rebuilt, and being able to rebuild into a clean, isolated environment quickly when prevention fails.
How does Firefly support recovery-first security?
Firefly’s CRPM continuously scores how recoverable an environment actually is against built-in resiliency policies, and CAIRS rebuilds compromised infrastructure into a clean, isolated environment using immutable IaC snapshots, with every restore generated as reviewable Terraform rather than a direct, unauditable cloud mutation.
.avif)
.avif)
.webp)
.webp)
