How to Defend Against AI-Discovered Vulnerabilities: A Practitioner Guide

The Glasswing findings differ from traditional CVEs in two structural ways that matter for operational response. First, scale: more than 10,000 high/critical vulnerabilities identified, most still unpatched. Traditional vulnerability management processes handle dozens of high/critical per quarter. A program calibrated for that throughput will fail under Glasswing-scale disclosure volume. Triaging, assigning, tracking, and verifying patch status for high/critical CVEs at this volume requires automation at stages that most programs still rely on human analysts to manage.

Second, novelty: Mythos is finding bugs in old, rarely-audited subsystems that traditional scanning, fuzzing, and code review never reached. The 17-year FreeBSD NFS bug and the 27-year OpenBSD TCP SACK flaw survived decades of expert security review. They represent a class of vulnerability that is not on any existing CVE radar and that existing vulnerability management processes would never have prioritized for audit -- because the systems were old and therefore assumed to be well-understood.

The combination means security teams are facing both a volume problem and a novelty problem simultaneously. The four defensive actions below address each directly.

Mythos's capability to find multi-decade-old bugs means age is no longer a proxy for audited status. A software component that has not received a security-focused audit in more than five years should be treated as potentially vulnerable regardless of its CVE history -- the absence of CVEs in old code is evidence that no one has looked carefully, not evidence that there are no bugs to find.

Practical implementation steps: (a) Inventory operating system and library versions with explicit age tracking -- when was each component last the subject of a security-focused audit or formal review? Most vulnerability management platforms track CVE counts but not audit history. Build the age dimension explicitly. (b) Apply expedited patch SLAs to CVEs affecting components older than five years. A 24-48 hour SLA for high/critical in legacy components is defensible given Mythos N-days research showing working exploits within hours of vulnerability information becoming available. (c) Prioritize network-accessible services in legacy subsystems: NFS, SMB, LDAP, and similar protocol implementations. These are precisely the code paths Mythos targets, and they are the most exposed to exploitation without lateral movement being required.

Anthropic's explicit recommendation to the security community is direct: integrate frontier AI into your defensive workflows immediately, not after the tooling matures. The same capability that found 10,000+ vulnerabilities in partners' software can be directed at your own codebase, your own infrastructure, and your own threat hunting workflows. Claude Security (public beta) patched 2,100+ vulnerabilities in its first three weeks. That rate is only possible because AI can operate continuously across a codebase at a depth and breadth that human reviewers cannot match.

The competitive dynamics argument is specific. Anthropic projects that Mythos-class capability will be accessible to adversaries within 6-12 months. Organizations that have already built AI into their vulnerability research, code review, and threat hunting workflows by that point will have a structural advantage -- they will have baseline familiarity with the tooling, established workflows, and accumulated institutional knowledge about how AI findings integrate into their specific security operations. Organizations waiting for tooling to mature are ceding that runway.

The practical starting point for most teams is integrating AI-assisted code review into the CI/CD pipeline for high-risk components, starting with network-facing services in the legacy subsystem categories that Glasswing has shown are most productive. The incremental investment is low. The baseline familiarity it builds is high.

Action 3: Automate incident response triggers. Mythos N-days research found first working exploits in 12 minutes for Firefox and 31 minutes for Windows kernel vulnerabilities. IR playbooks that assume days of analyst review before a threat is weaponized are structurally wrong for a world where working exploits exist within an hour of vulnerability information becoming available. The fix is pre-staged automated containment: network isolation for critical systems triggered by EDR behavioral detection, automated quarantine rules in SIEM that fire on known-bad behavioral patterns without waiting for analyst approval, and response playbooks that execute on high-confidence signatures. The goal is not to remove human judgment from IR -- it is to remove human latency from the containment decision when the threat pattern is unambiguous.

Action 4: Review disclosure posture. The 90-day coordinated vulnerability disclosure window was calibrated for a world where exploit development is expensive and measured in weeks of senior researcher time. That assumption is no longer valid. If your organization participates in coordinated disclosure as a reporter, push vendors for shorter patch commitments and treat non-response past 30 days as grounds for disclosure rather than grounds for extension. If your organization receives disclosures, treat Day 1 as the start of an active race. The embargo window is not a 90-day buffer -- it is the window before a Mythos-class system can produce a working exploit from the public vulnerability description. That window may be shorter than the disclosure timeline your vendor policy assumes.