A reckoning for the cyber industry
On April 7, 2026, Anthropic released a technical assessment (see here) that would send chills down every cybersecurity professional – their newest model, Claude Mythos Preview, can perform cybersecurity tasks autonomously, at scale, and with a level of sophistication that eclipses anything that was possible earlier. In one example, the model when pointed at FreeBSD’s NFS server code with the simple instruction “find a security vulnerability” fully autonomously discovered a 17-year-old remote code execution flaw — CVE-2026-4747 — and then wrote a working exploit using a 20-gadget ROP chain split across multiple packets, granting unauthenticated root access to any internet-facing machine running NFS. No human involvement was needed after the initial prompt.
CVE-2026-4747: A 17-year-old memory corruption bug in FreeBSD’s svc_rpc_gss_validate(). The oa_length field arrives directly from the network packet without bounds checking. Mythos chained this into a full ROP chain split across multiple NFS packets to achieve unauthenticated remote root. Affected: any FreeBSD host with NFS enabled. Patch status at disclosure: coordinated, but thousands of unpatched hosts remain.
Mythos also wrote a web browser exploit that chained four separate vulnerabilities, deploying a JIT heap spray to escape both the renderer sandbox and the OS sandbox. It autonomously produced local privilege escalation exploits on Linux by threading together race conditions with KASLR bypasses. It found a 27-year-old bug in OpenBSD — a system whose entire identity is built on security hardening. And across Anthropic’s own internal benchmark of roughly 7,000 entry points into open source repositories, Mythos reached Tier 5 — complete control flow hijack — on ten fully patched targets. The previous generation of models achieved Tier 3 once.
Key stats as per Anthropic’s Project Glasswing launch announcements:
- 1,000s of zero-days found across every major OS and browser
- Less than 1% patched at time of Glasswing announcement
- 181 times more working Firefox exploits versus the previous best model
- 27 years: age of the oldest zero-day found (OpenBSD SACK bug)
Anthropic formed Project Glasswing in direct response: a restricted preview program granting Mythos access to AWS, Apple, Microsoft, Google, CrowdStrike, Cisco, NVIDIA, JPMorganChase, Palo Alto Networks, and 40 additional critical infrastructure organizations. The stated goal is to let defenders patch the most dangerous systems before Mythos-class capabilities proliferate to adversaries. But even this optimistic framing contains a hard truth: fewer than 1% of the vulnerabilities Mythos has found have been patched.
This is not a detection problem. This is an investigation and remediation capacity problem — and the gap is about to be measured in thousands of critical CVEs.
Understanding the actual threat surface
To understand what a Mythos-class vulnerability flood means for your team, you need to understand the technical profile of the bugs being found — and why your existing tooling was not designed to handle this volume.
Memory Corruption at Depth
The majority of Mythos-discovered vulnerabilities are memory safety bugs in C and C++ codebases — the kernel, libc, NFS, NTP, DNS resolvers, browser JIT engines, and parser libraries that underpin essentially everything. These are not trivial buffer overflows. They are subtle type confusion errors, UAF (use-after-free) conditions in complex state machines, and race conditions in kernel locking paths that have survived decades of manual code review and fuzzing because their preconditions are difficult to construct.
For the full technical breakdown of how Mythos discovers and exploits these bugs, including details on CVE-2026-4747 and other patched findings, see Anthropic’s Red Team post referenced earlier.
Browser Exploitation: Four-Vulnerability Chains
The browser exploit Mythos constructed is the more concerning demonstration. A working browser sandbox escape requires chaining multiple distinct vulnerability classes: a memory corruption bug to gain an initial write primitive, a type confusion or UAF to elevate that to a read/write primitive within the renderer, an information leak to defeat ASLR, and a sandbox escape primitive targeting a kernel interface exposed to the renderer process. Writing a JIT heap spray that reliably places attacker-controlled JIT-compiled code at a predictable address — then pivoting that into a renderer escape and an OS-level privilege escalation — is the kind of multi-week project that characterizes nation-state offensive toolkits. Mythos did this in a single agentic run, starting from source code (see technical details here).
The N-Day Weaponization Problem
Beyond zero-days, Mythos demonstrated the ability to take known-but-unpatched vulnerabilities (N-days) and reverse-engineer working exploits from patch diffs and binary analysis. This matters enormously for your patch management posture. The window between a CVE being published and a working exploit appearing in the wild — historically measured in days to weeks for critical vulnerabilities — may collapse to hours when adversaries gain access to Mythos-class models.
For every CVE you have not patched, this is your exposure window under the new threat model.
Why your investigation workflow breaks at this scale
Here is the scenario your team is about to face. Over the coming months, Project Glasswing partners will responsibly disclose thousands of vulnerabilities in operating systems, browsers, and critical infrastructure software. NVD will be flooded. Your vulnerability scanner will light up. Your threat intelligence platform will ingest advisories faster than your team can read them.
Every one of those CVEs triggers the same investigation question: Are we affected? Where? How badly?
To answer that question for a single CVE — say, a kernel use-after-free in the io_uring subsystem of Linux 6.1–6.8 — your analyst needs to do the following:
- Enumerate every Linux host in the environment running an affected kernel version (CMDB, EDR, cloud inventory — often three separate systems).
- Determine which of those hosts are exposed — internet-facing, running vulnerable services, accessible from a compromised network segment.
- Check whether the exploit requires local access or is remotely triggerable. If local: which users have shell access to the affected hosts?
- Search EDR and SIEM telemetry for indicators of pre-exploitation reconnaissance — anomalous
io_uringsyscall patterns, unexpected privilege escalation sequences, lateral movement from affected hosts. - Cross-reference with threat intelligence: is there an in-the-wild exploit? Which threat actors are known to weaponize this class of vulnerability?
- Produce a prioritized remediation list and document the blast radius.
A skilled analyst can do this for one CVE in two to four hours. At Glasswing scale — hundreds of critical disclosures over weeks — that math does not work.
If Project Glasswing leads to 500 high-severity CVE disclosures over a 90-day window, and each takes three analyst-hours to investigate, that is 1,500 analyst-hours — roughly nine months of a single analyst’s time, compressed into three. Most SOCs do not have that capacity.
The bottleneck is not intelligence. Your threat intel platform will have the CVE details. The bottleneck is data access and correlation: being able to query across all of your telemetry sources, simultaneously, to answer the blast radius question for each new disclosure — fast enough to matter.
Why a SIEM-centric architecture fails here
Most enterprise security architectures were designed around a hub-and-spoke data model: ingest everything into a SIEM, normalize it, write detection rules, alert on matches. That model has significant structural problems in the Glasswing era.
Ingestion cost constrains coverage. Every major SIEM charges by data volume. Security teams have already responded to cost pressure by selectively reducing the data they send to their SIEM — dropping verbose process execution logs, skipping cloud API telemetry, archiving old endpoint data to cold storage. This means the SIEM does not have a complete picture of the environment. When a new CVE requires searching two years of kernel syscall logs across your entire Linux fleet, that data simply may not be there.
Normalization pipelines are brittle. Your SIEM normalizes data at ingestion time. When a new vulnerability class emerges — say, exploitation via a novel operation type that your parser was not built to handle — your normalized schema may not have the right fields. Answering the blast radius question requires raw telemetry that the normalization pipeline discarded.
Context lives in disconnected systems. The data required to investigate a kernel privilege escalation spans your EDR (process tree, syscall telemetry), your CMDB (host ownership, OS version, patch status), your identity provider (which users have shell access), your cloud infrastructure API (is this host internet-facing?), your network flow data (what lateral movement is possible from this host?), and your vulnerability scanner (is the specific vulnerable version confirmed?). None of these systems speak to each other natively. Each pivot requires a separate query in a separate tool with a separate data model.
This is the architectural problem that Mythos-scale disclosure makes urgent. The answer is not a bigger SIEM. The answer is a fundamentally different relationship with your security data.
The Security Data Mesh: the architecture for this moment
A security data mesh inverts the traditional architecture. Instead of moving all data to a central store and querying it there, a data mesh federates your queries out to where the data already lives — EDR platforms, cloud logs, data lakes, SaaS security tools, on-premises log archives — and brings normalized, enriched results back in a single unified interface. The data does not move. The query does.
// OLD: All data must be ingested before it can be queried
EDR → Cloud Logs → Network Flow → SIEM (ingest $$) → Alert
// Problem: incomplete data, brittle pipelines, cost-driven blind spots
// NEW: Query data where it lives, results returned normalized
EDR | S3/Data Lake | Cloud APIs | Identity | Vuln Scanner
↑
Query Security Data Mesh (federated search + OCSF normalization)
↑
Query Workers (AI Agents) → CVE Blast Radius ReportQuery’s Security Data Mesh is purpose-built for this architecture. Pre-built API connectors normalize telemetry from your EDR, SIEM, data lake, identity provider, cloud infrastructure, and vulnerability scanner into OCSF (Open Cybersecurity Schema Framework) at search time — not at ingestion time. This means you can ask a single investigation question and get a unified answer that draws on your entire security data estate, including the cold-archive logs you stopped ingesting into your SIEM years ago.
When a new Glasswing-disclosed CVE drops and you need to answer “which of our Linux hosts running kernel 6.1–6.8 with io_uring exposed are also accessible from our DMZ, and have had anomalous privilege escalation events in the last 72 hours?” — you ask that question once, in one place, and Query federates it across every data source simultaneously.
A security data mesh is not about consolidating your data. It is about a consolidated way to access and investigate your data. The data stays distributed and cost-efficient; the query plane is unified. This is the only architecture that scales to Glasswing-level disclosure volumes without a proportional increase in SIEM ingestion costs.
Query Workers: Automated Investigation at machine speed
Having federated data access is necessary. It is not sufficient. A human analyst still has to formulate the right queries, interpret the results, correlate across data sources, and produce a prioritized investigation report. At Glasswing scale — dozens of critical CVE disclosures per week — that human-in-the-loop bottleneck remains.
This is where Query Workers close the loop. Query Workers are mission-specific AI agents built on top of the Query Security Data Mesh. Each Worker is designed to automate a specific, well-defined investigation task — and because they operate over Query’s federated data layer, they have access to your entire security data estate, not just what happens to live in your SIEM.
In the context of a Mythos-driven CVE flood, here is what an automated investigation workflow looks like in practice:
# Worker invocation for CVE-2026-4747 (FreeBSD NFS RCE)
CVE_BLAST_RADIUS_WORKER({
cve_id: "CVE-2026-4747",
affected_product: "FreeBSD",
affected_versions: ["13.0", "13.1", "13.2", "14.0"],
attack_vector: "NETWORK",
attack_prerequisite: "NFS_PORT_EXPOSED",
severity: "CRITICAL",
tasks: [
"enumerate_affected_assets", # EDR + CMDB + cloud inventory
"assess_network_exposure", # Firewall rules + network flow data
"check_exploitation_indicators",# SIEM + EDR for anomalous NFS traffic
"correlate_threat_intelligence",# TI platforms for in-the-wild IOCs
"generate_prioritized_patch_list"# Ranked by exposure + asset criticality
]
})
# Output: structured blast radius report, ready for analyst review
# Time: minutes, not hoursThe Worker Roster for Glasswing-Scale Response
Vulnerability Intelligence Agent — Ingests a new CVE, identifies affected assets across your environment via federated search, scores exploitability in your specific context, and outputs a prioritized remediation list with patch guidance. Replaces CVE research, spreadsheet triage, and patch prioritization guesswork.
Asset Info Agent — Builds a real-time 360° profile of any host: OS version, installed software, owner, applied controls, open network ports, current vulnerability posture. Replaces CMDB lookups and console pivots across disconnected systems.
Detection Triage Agent — Automatically investigates detection findings, maps tactics to MITRE ATT&CK, correlates evidence across EDR and SIEM data, and produces an actionable triage report — including whether an indicator matches a known Glasswing-disclosed exploit pattern.
Network Activity Agent — Given a host or IP, surfaces traffic patterns, firewall exposure, asset-to-asset communication paths, and threat context — answering whether a vulnerable host is reachable from an adversary-controlled network segment.
File Hash Search Agent — Sweeps your entire environment for a known exploit binary or payload hash — across EDR, email security, endpoint DLP, and cloud storage — with first-seen/last-seen timestamps and asset correlation.
Threat Research Agent — Parses Glasswing advisories and threat intelligence reports, extracts IOCs, maps them to ATT&CK techniques, and immediately checks whether any indicators are present in your environment.
Most AI security agents are only as good as the data they can access. An agent that can only query your SIEM misses the 60–70% of your security-relevant telemetry that never gets ingested. Query Workers operate over the full Security Data Mesh — every connector, every data source, every archive — which means the blast radius analysis they produce reflects your actual environment, not your SIEM’s approximation of it.
A representative Glasswing response workflow
Here is a representative example of what it would look like end-to-end for a security operations team when a new Glasswing or other advanced LLM-driven disclosure drops:
Hour 0 — Disclosure. NVD publishes CVE-2026-XXXX: a critical use-after-free in the Linux kernel’s io_uring subsystem, affecting kernels 6.1 through 6.8. Exploitable locally by unprivileged users for full kernel privilege escalation. CVSS 9.8. Proof-of-concept available.
Hour 0–15 min — Automated blast radius analysis. The Query Vulnerability Intelligence Worker fires automatically (or on analyst trigger). It federates queries across the CMDB connector, the EDR connector, the cloud infrastructure connector, and the identity connector. Within minutes it returns: 847 affected hosts identified; 312 are internet-facing cloud instances; 89 have container workloads with user-namespaced io_uring access; 14 are classified as Tier 1 critical assets. Patch status: 0 of 847 have the backported fix applied.
Hour 15 min — Exposure scoring. The Network Activity Worker cross-references the 312 internet-facing hosts against firewall rule telemetry and recent network flow data. It identifies 22 hosts with anomalous outbound traffic patterns in the past 48 hours — potential pre-exploitation reconnaissance or post-compromise beaconing.
Hour 30 min — Threat hunt. The Detection Triage Worker sweeps EDR telemetry across all 847 hosts for privilege escalation indicators consistent with io_uring exploitation: unexpected transitions from UID 1000+ to UID 0, anomalous kernel call stacks originating from io_uring_enter(), spawning of privileged shell processes from unprivileged parent processes. Two hosts return suspicious matches.
Hour 1 — Human analyst in the loop. Your analyst receives a structured report: affected hosts ranked by risk, two hosts flagged for potential active exploitation, patch prioritization list, MITRE ATT&CK mapping (T1068 — Exploitation for Privilege Escalation), and IOC list cross-referenced against threat intelligence. The analyst’s job is not to gather this information. It is to decide what to do with it.
This is what machine-speed investigation looks like. And in a Glasswing world where this workflow needs to run for a new critical CVE every few days, it is the only model that keeps your team ahead of the curve.
What security teams should do right now
Project Glasswing is ongoing. The vulnerability disclosures have not yet peaked. Here is a concrete preparedness checklist:
1. Audit your investigation data coverage. Map the data sources required to answer the blast radius question for a critical CVE in each of your major technology stacks — Linux, Windows, your primary cloud provider, your browser stack, your container orchestration layer. Identify which of those sources are not currently queryable in a unified investigation surface. Those gaps are your exposure.
2. Assess your patch velocity. Glasswing-scale disclosure will stress your patch management process. Baseline your current mean time to patch for critical CVEs. If it is measured in weeks, it needs to come down. The N-day weaponization capability of Mythos-class models means the exploitation window after disclosure will shrink dramatically.
3. Build CVE investigation playbooks now. Define the standard queries and data sources required to investigate a critical kernel CVE, a browser sandbox escape, and a network service RCE — before you are doing it under pressure. Query Workers can automate these playbooks, but the playbook logic needs to be defined by your team based on your environment.
4. Move archival data into federated reach. If your retention policy archives endpoint telemetry older than 90 days to S3 or a cold data lake, ensure that archive is accessible via federated search. Glasswing disclosures will require retrospective threat hunting — looking for exploitation of vulnerabilities that were silently active before they were discovered.
5. Plan for human-AI teaming, not human replacement. Query Workers automate the data gathering and correlation work. The prioritization, escalation, and remediation decisions remain human. Design your workflow so that Workers surface actionable, structured investigation packages to analysts — not raw query results that require further manual interpretation.
The ethos from this Mythos moment
There is something worth sitting with in the name “Project Glasswing” from Anthropic’s Mythos model. The glasswing butterfly’s wings are nearly transparent — fragile-looking, but extraordinarily resilient. The transparency is the defense. Anthropic’s framing is intentional: the defensive response to AI-enabled vulnerability discovery is visibility, not opacity. Find the bugs. See them clearly. Fix them before an adversary does.
Get ready with expanding your visibility and getting your infrastructure ready to act on what you see. Thousands of Glasswing-disclosed zero-days are about to become thousands of investigation tasks, spread across a security data estate that most teams still cannot query in a unified way.
The security teams that will navigate this transition well are the ones that solve the data access problem before the CVE flood arrives — the ones building on a security data mesh that lets their analysts ask any investigation question and get an answer that draws on their entire environment, and that deploys AI Workers to automate the investigation groundwork so humans can focus on judgment.
The capability advantage now belongs to whoever can move fastest. That is no longer just about detection. It is about investigation infrastructure.
Ready to investigate at machine speed?
See how Query’s Security Data Mesh and Workers can give your team unified visibility across your entire security data estate — and automate CVE blast radius analysis before the next Glasswing disclosure. Book a demo here.
