Incident Response Playbook: How to Respond When an AI Discovers a Vulnerability in Your Stack

Understanding which scenario you are in determines the urgency and sequencing of your response. Scenario One: Private CVD Notification. You receive a notification from Anthropic's security team (or an authorized Glasswing partner) that Claude Mythos has identified a vulnerability in software you operate. The notification includes a technical description of the vulnerability, a severity assessment, and a disclosure timeline (typically 90 days from initial notification). This scenario gives you a meaningful response window. You have time to assess whether the software is present in your environment, develop or obtain a patch, test it in a representative environment, and deploy it before the CVE is public. The urgency is high but not emergency: you should initiate your vulnerability response process within 24 hours of notification, but you are not in active incident mode. Scenario Two: Public Glasswing CVE Affecting Your Stack. You discover through your vulnerability management process, threat intelligence feeds, or vendor notification that a published Glasswing CVE affects software running in your environment. This scenario is materially more urgent. The CVE details are publicly available. Adversaries with AI tools can develop working exploits from the CVE details in hours to days for exploit-amenable vulnerability classes. You are now in a race between your patch deployment and adversary exploitation. Threat hunting for active exploitation should run in parallel with patch development. The response to Scenario Two is emergency-tier, not standard vulnerability management.

The first 24 hours of response, whether you are in Scenario One or Two, are the most critical. The immediate triage checklist for an AI-discovered vulnerability has six steps. Step One: Verify the notification. Confirm that the CVD notification or CVE is legitimate. For Glasswing notifications, verify the sending domain and confirm through Anthropic's published security contact channels. For public CVEs, confirm the CVE entry in the NVD and correlate with the Glasswing attribution. Step Two: Identify affected assets. Run queries against your CMDB, vulnerability scanner database, and software inventory to identify all systems running the affected software, version ranges, and configurations. This is the most time-consuming step and is where asset inventory gaps create risk. Step Three: Assess exposure. For each affected system, determine whether it is internet-facing, internal-only, or isolated. Internet-facing systems require immediate compensating controls regardless of patch availability. Step Four: Assess data sensitivity. Determine whether affected systems store, process, or transmit regulated data (ePHI, PCI data, personal data subject to breach notification laws). This assessment determines your breach notification obligations if exploitation occurs. Step Five: Assess exploit availability. Determine whether working exploit code is publicly available (Metasploit, ExploitDB, threat intelligence feeds). If exploit code is available, your response timeline is hours, not days. Step Six: Initiate parallel workstreams. Launch patch development or vendor patch acquisition, compensating control implementation, and threat hunting as concurrent workstreams rather than sequential steps.

Asset inventory gaps are the single most common reason vulnerability response fails. Organizations that cannot answer 'which systems are running version X.Y.Z of this software' within hours of receiving a CVD notification cannot respond effectively to AI-era vulnerability disclosure. The asset inventory requirements for effective Glasswing vulnerability response include software inventory that tracks installed packages and versions across all managed endpoints and servers (commercial tools: Flexera, ServiceNow ITOM, or open-source alternatives like osquery), container image registries that track which container images incorporate which base layers and third-party libraries (critically important for organizations running microservices architectures where a vulnerable library like wolfSSL can be embedded in dozens of containerized services), and network exposure mapping that documents which services are internet-facing, which are internal, and which are isolated. Organizations that discover their asset inventory is insufficient during a Glasswing response have an opportunity to address this gap after the immediate response is complete. Asset inventory is the most impactful foundational investment for vulnerability management program maturity. In the interim, broad-spectrum scanning using vulnerability scanners with updated plugins for the specific CVE will compensate partially for incomplete CMDB data, though it will miss systems that are not regularly scanned.

Stakeholder communication for an AI-discovered vulnerability response must be calibrated to the scenario and the actual risk level. For a Scenario One (private CVD notification) with low internet exposure and a patch available, communication is primarily internal: CISO and security leadership briefing on day one, affected system owner engagement for remediation planning, and a brief update for the board's risk committee at the next scheduled meeting. For a Scenario Two (public CVE affecting internet-facing systems with confirmed exploit code), communication is broader and faster. CISO and security leadership briefing is immediate and should include the technical details of the vulnerability, affected systems, exposure, and the response plan. Legal and compliance counsel engagement is same-day: they need to assess regulatory reporting obligations before any exploitation occurs, not after. General counsel and board notification depend on materiality: publicly traded companies should consult their SEC reporting counsel on whether the situation meets the materiality threshold for cybersecurity incident disclosure under the SEC's 2023 rules. Communications and PR should be briefed if there is any possibility of external disclosure, customer impact, or media inquiry. The fundamental communication principle is that stakeholders need enough context to make decisions, not a technical deep dive. The CISO communication should cover: what software is affected, how many and which of our systems are affected, whether it is exploitable from the internet, whether we have a patch, what compensating controls are in place, and what the timeline is for remediation. Board communication should cover: potential business impact, regulatory reporting assessment, and remediation timeline.

The patch timeline decision for a Glasswing-attributed vulnerability is a risk decision that involves factors beyond standard SLA compliance. The framework for making this decision has three branches. Branch One: Emergency patch deployment (target 24-72 hours). Criteria: internet-facing system, confirmed working exploit available or AI-amenable vulnerability class in post-disclosure scenario, CVSS 9.0 or higher, or confirmed active exploitation in the wild. For emergency patch deployment, standard change management processes should be bypassed with documented risk approval from the CISO or delegated authority. Branch Two: Expedited patch deployment (target 7-14 days). Criteria: internal system with significant network connectivity, CVSS 7.0-8.9, no confirmed exploit available but in AI-amenable vulnerability class, or high-criticality asset with any exploit availability. Expedited deployment uses an accelerated change management process with shorter testing cycles and reduced approval tiers. Branch Three: Standard patch deployment (standard SLA). Criteria: isolated or low-criticality system, CVSS below 7.0, no exploit availability, not in AI-amenable vulnerability class. Standard deployment follows the normal change management process. The critical insight is that Branch One must exist as a documented, practiced process before you need it. An emergency patching process that is invented during the emergency fails because the organizational friction points (CAB approval, testing requirements, change freeze policies) cannot be navigated quickly without pre-established exception criteria and approver designations.

Compensating controls are temporary risk reduction measures implemented while a patch is being prepared and deployed. The key principle is that compensating controls must be implemented with the understanding that they reduce risk but do not eliminate it, and they must be documented as part of your response record. The most effective compensating controls depend on the vulnerability type. For network-reachable service vulnerabilities, firewall rules or WAF rules that restrict access to the vulnerable service to trusted source IP ranges reduce the exposed attack surface. For authentication bypass vulnerabilities, requiring additional authentication factors (MFA) for the affected service provides meaningful risk reduction. For remote code execution vulnerabilities in internet-facing applications, disabling or removing the vulnerable functionality is the strongest compensating control, though it may not be operationally feasible. For privilege escalation vulnerabilities, enhanced monitoring for unusual privilege elevation events and endpoint detection and response (EDR) coverage of affected systems provides detection capability. Every compensating control should be documented with: the control implemented, the date and time it was implemented, the residual risk it leaves, the expected duration, and the patch or permanent remediation that will replace it. This documentation serves as both the IR record and the risk acceptance documentation for your risk management program.

For Scenario Two (public CVE affecting your environment), threat hunting for active exploitation should run concurrently with patch development and compensating control implementation, not after patching is complete. The goal is to determine whether exploitation has already occurred before you were aware of the vulnerability. Threat hunting for AI-discovered vulnerabilities in the Glasswing context should prioritize the following hunts. Examine web server and application logs for requests matching the vulnerability's exploitation characteristics during the period between public CVE disclosure and the current date. For Glasswing CVEs affecting services that have been public for a defined period, you can scope the hunt temporally. Review authentication logs for anomalous successful authentication events on affected systems, particularly from unusual source IPs or at unusual times. Examine process execution logs on affected systems for unusual child processes, particularly command interpreters or network connections spawned by services that should not be invoking them. Check outbound network traffic logs for unexpected connections from affected systems to external IP addresses, which may indicate post-exploitation C2 communication. Review file system logs for unusual file creation or modification in sensitive directories on affected systems. The specific threat hunt queries depend on the vulnerability type and the logging and monitoring capabilities in your environment. SIEM platforms with good log coverage and EDR tools are the most effective hunting environments.

The breach notification assessment determines whether exploitation of a Glasswing-attributed vulnerability has triggered any mandatory reporting obligations. This assessment should be conducted by legal counsel in consultation with security and compliance teams, and it should be documented regardless of the conclusion. The assessment framework has three questions. First: was the vulnerability exploited? This is answered by your threat hunting activities and forensic investigation. If you find no evidence of exploitation, document that conclusion with the scope of your investigation. If you find evidence of exploitation, proceed to question two. Second: was sensitive data accessed, exfiltrated, or exposed? This depends on what data the affected system stores or processes. If the affected system does not store regulated data (ePHI, PCI cardholder data, personal data subject to breach notification), the reporting obligation set is narrower. If regulated data was accessible on the affected system, assess whether the exploitation reached that data. Third: what are the applicable notification obligations? For healthcare covered entities, HIPAA's four-factor risk assessment determines whether ePHI exposure is a reportable breach. For public companies, SEC rules require a materiality determination for cybersecurity incidents. For retailers and any company with consumer personal data, applicable state breach notification laws (California CCPA/CPRA, New York SHIELD Act, etc.) and GDPR if European personal data is involved. The breach notification assessment must be completed promptly because most notification obligations have short timelines that begin from the date of discovery, not the date of determination.

Every significant vulnerability response, whether or not exploitation occurred, should be followed by a post-incident review (PIR) that captures lessons learned and drives program improvements. For Glasswing-attributed vulnerabilities, the PIR should address the following questions. How long did it take to identify all affected systems in your environment after receiving the CVD notification or CVE publication? If the answer is more than 24 hours, the asset inventory program needs investment. How long did it take to implement compensating controls on internet-facing affected systems? If the answer is more than 24 hours, the emergency response process needs to be documented and practiced. Were all required stakeholders notified within appropriate timelines? If legal, compliance, or CISO notification was delayed, the escalation criteria need to be documented. Was a breach notification assessment completed before exploitation evidence was ruled out or confirmed? If not, the assessment process needs to be built into the response playbook. How does the actual response timeline compare to your patch SLA targets? If you missed SLA for a finding that warranted emergency treatment, the emergency tier criteria and process need adjustment. PIR outputs should be tracked as action items with owners and due dates, and progress should be reviewed at the next security leadership meeting. Vulnerability response capabilities improve through deliberate after-action review, not through the assumption that the next incident will go better.

The Mythos Brief includes the complete IR playbook for AI-discovered vulnerability response, including timeline templates, stakeholder communication scripts, and documentation templates. The following components are available to Mythos Brief subscribers.