Canonical’s security philosophy has always been built on the premise that vulnerabilities exist and will be discovered. Our response relies on defense-in-depth architecture, rapid patch deployment, and strict adherence to Coordinated Vulnerability Disclosure (CVD).

AI changes vulnerability discovery volume and speed. We have a robust vulnerability management process that is backed by rigorous compliance certifications. These processes have demonstrated robustness in stringent ecosystems and we are adapting them with more exposure mapping, better customer guidance, and clearer remediation paths. This is where AI makes our customer service and internal responses more efficient.

To address real-world security we contain the blast radius of newly weaponized legacy bugs using our historically proven confinement tools, enforcing strict kernel-level boundaries with AppArmor and native container isolation (LXD). Building on this securely-designed foundation, we continue to modernize and harden Ubuntu by championing memory-safe languages like Rust.

We align our multi-tiered risk model with upcoming compliance requirements like the EU Cyber Resilience Act (CRA) focusing on actual threat impact rather than blindly chasing raw CVSS scores. Because AI will continuously unearth decades-old dormant flaws, we secure this foundation and your long-term compliance with up to 15 years of security maintenance through Ubuntu Pro.

Additionally, through the Ubuntu Security Research Alliance Program we’re partnering directly with leading security scanning providers in order to improve how accurately our data is presented in scan results, and to ensure that every piece of open source software distributed by Canonical is properly assessed.

1. What is Canonical’s  current awareness of the Mythos / Glasswing CVE disclosure? 

Canonical’s Security Team is transforming its processes and infrastructure to adapt to the scale and speed of new frontier models, such as Mythos, GPT-5.5, and open-weight models. This ensures our incident response teams are fully prepared to triage and remediate the anticipated influx of AI-generated vulnerability reports.

2. Has Canonical conducted any internal AI-assisted vulnerability analysis across its own product estate? 

Yes, we are actively integrating agentic AI frameworks to conduct independent vulnerability analysis across our estate. This evolution builds directly on our strict, foundational quality management practices, such as the extensive package auditing required by our Main Inclusion Review process.

3. Do you have a list of products that you would consider most exposed to the latest frontier-model vulnerability categories? 

Because the foundational Linux stack is historically written in non-memory-safe C/C++, exposure to these classes of vulnerabilities is systemic across the entire open source ecosystem. Rather than maintaining a flat, theoretical “exposed list,” Canonical mitigates these risks structurally. First, we enforce mandatory compiler-level protections that go hand in hand with Linux kernel features for application hardening across the entire Ubuntu archive to reduce exploitability.

Furthermore, we evaluate exposure and prioritize our engineering response through a multi-layered risk model, ensuring that a massive influx of AI-discovered CVEs does not lead to a panicked, one-size-fits-all response. Instead, we right-size our response based on the component at hand:

• Critical Foundation: Core components that could have significant impact on a system. This includes the kernel, glibc, OpenSSL, systemd, sudo, PAM, and core container runtimes.
• Infrastructure & Orchestration: Canonical’s management, isolation, and deployment layers. This includes snapd, AppArmor, cloud-init, LXD, MAAS, Juju, and MicroK8s. These tools govern how the infrastructure is secured and scaled.
• Application Ecosystem: The thousands of open-source applications and dependencies residing in the Universe repository, which are covered under Ubuntu Pro. While an AI-discovered CVE here might impact a specific business service, the threat might be contained by the structural protections (like AppArmor) established by the tiers above it.

and

• Custom Workloads: Customer-specific applications and proprietary code operating outside of Canonical’s scope.

4. What is Canonical’s typical turnaround time for releasing CVE fixes, and how do you prioritize which vulnerabilities get patched first?

While we do not treat every vulnerability with a uniform SLA, our focus is on rapid remediation for high-risk threats. We aim to prepare, test, and release the most vital security updates within 24 hours on average.

In the event of a true zero-day vulnerability or evidence of active exploitation in the wild, we push expedited, emergency fixes to our users as fast as possible.

Because we understand that not all CVEs carry the same real-world risk, we do not prioritize fixes based strictly on raw CVSS scores. Instead, we triage vulnerabilities based on their specific impact on Ubuntu users. Fixes are expedited for vulnerabilities that present the highest actual risk and affect the largest number of installations, ensuring that your most critical systems receive protection first.

5. Where a software patch cannot be deployed within the required window, what compensating controls or virtual patching capabilities does Canonical have available? 

Ubuntu’s default implementation of AppArmor profiles and snap confinement act as strict structural compensating controls, isolating vulnerable services and protecting against privilege escalation or arbitrary file access. Kernel Livepatch applies permanent kernel vulnerability fixes in-memory without requiring a system reboot.

Furthermore, in instances where a formal fix is not yet available, we aim to provide clear, actionable mitigation strategies – such as specific system workarounds or configuration changes – directly on our CVE trackers (e.g., our published mitigations for CVE-2022-23960) to help you secure your environment in the interim. 

Finally, we frequently publish detailed blog posts breaking down the vulnerabilities, including impact assessments, real-world scenarios, and potential mitigations, to help our users fully understand the risk and secure their environments.

6. What is Canonical’s responsible disclosure process for Glasswing-identified vulnerabilities in your products? 

Canonical does not maintain a separate, specialized vulnerability management process specifically for Project Glasswing. Consequently, we do not provide exclusive early notifications, out-of-band updates, or bypass standard community embargoes for individual partners prior to the Coordinated Release Date (CRD). We adhere to the best-practices recognized by the security community in Coordinated Vulnerability Disclosure (CVD) and we handle embargoes according to our Disclosure Policy.

Canonical’s Security Team ensures that patches are actively developed, thoroughly tested, and pre-staged within the standard embargo window. These fixes are released globally and simultaneously with the public CVE disclosure, ensuring our customers and partners can confidently deploy updates at “day zero.”

7. How is Canonical evolving its development and architectural practices to defend against the class of vulnerabilities that Mythos-like projects uncover?

Canonical is actively modernizing its products to address decades-old paradigms. We are championing the integration of memory-safe languages into the core OS by enabling Rust support in our kernels and providing the complete toolchain for developers. We encourage the community to build in Rust, and our own engineering efforts are focused on rewriting critical user-space components. 

For legacy C/C++ code that cannot be immediately rewritten, we rely on defense-in-depth. Assuming legacy code will inevitably have flaws, we engineer the Ubuntu environment to prevent those logic flaws from becoming viable, chained exploits. 

To achieve this, Ubuntu natively supports robust isolation technologies like snaps and LXD. When users wrap their legacy applications in these secure sandboxed environments, strict kernel-level boundaries – such as cgroups, namespaces, and AppArmor profiles – are enforced, ensuring that even if a legacy application is compromised, the blast radius is tightly contained and the underlying host remains protected.

8. Does the advent of Glasswing mean previously secure Ubuntu systems are now suddenly vulnerable?

The threat landscape timelines are compressing. AI tools are unearthing “N-days” and legacy logic errors that survived conventional human review.

However, a vulnerability does not automatically equal a system compromise. Canonical’s fundamental security architecture, leveraging AppArmor confinement, minimal yet comprehensive images, strict namespace isolation, and proactive memory protections, was specifically designed on the assumption that zero-days and undiscovered flaws will always exist. This defense-in-depth approach is built to tightly contain the “blast radius” when a dormant bug is suddenly weaponized, preventing an attacker from escalating a single flaw into full system control.

Because AI will inevitably accelerate the volume of these historical bugs coming to light, the speed and duration of your patching lifecycle is more critical than ever. Ubuntu Pro provides up to 15 years of security maintenance and support. This ensures that when a decades-old vulnerability is suddenly surfaced with a working exploit, your infrastructure receives rapid, tested patches for years to come, without forcing you into disruptive, premature upgrades.

9. Is Canonical a direct participant in Anthropic’s Project Glasswing or actively using Claude Mythos?

Canonical is currently not a direct participant in Project Glasswing. We engage with all major security initiatives through our established Coordinated Vulnerability Disclosure (CVD) processes. We do not bypass these protocols or grant exclusive early access to any single AI vendor or participant. Our priority is taking security and vulnerability disclosures seriously, independent of the reporting source.

10. What happens if Canonical receives a severe vulnerability report that comes from an AI or model-based discovery tool?

We evaluate the technical merit of the finding, regardless of the entity or method that found it. If an AI tool discovers a severe vulnerability, Canonical conducts a risk assessment based on the specific environmental context of the open source project, and the actual exploitability of the bug. 

11. How should researchers or partners report vulnerabilities they discover in Ubuntu using AI tools?

Our process is governed by the official Ubuntu Security Disclosure Policy. Canonical Security Team participate in responsible disclosure and collaborate closely with the wider open-source community.

When a vulnerability is identified (whether internally, by a partner, or through a researcher, using AI or not), our protocol is as follows:

• Initial Response: We prioritize rapid assessment and prompt initial response to security reporters. 
• CVE Assignment: Canonical acts as a CVE Numbering Authority (CNA) and can directly assign CVE numbers.
• Embargo Adherence: Canonical’s Security Team manages embargo vulnerabilities in coordination with the broader open source community. For issues that are not yet publicly known, we strictly abide by agreed-upon timelines and information-handling. This ensures patches can be safely developed and released simultaneously with the public announcement (“day zero”) without tipping off malicious actors.
• Emergency Releases: We reserve the right to release fixes immediately if there is evidence of an embargo being broken that leads to a significant risk to our users.
• Transparency: All Ubuntu vulnerabilities fixed by Canonical’s Security Team are publicly documented and credited via Ubuntu Security Notices (USNs), ensuring our customers have a clear, auditable trail of our security interventions.
• Accuracy: Information on all vulnerabilities affecting Ubuntu is distributed through industry-standard machine-readable data feeds: OSV, VEX, and OVAL.