In April 2026, Anthropic disclosed Project Glasswing and introduced its preview of Mythos, an AI system capable of autonomously discovering zero-day vulnerabilities across software and platform layers. Anthropic’s initial findings included reports of long-standing flaws in systems such as OpenBSD and FreeBSD, alongside browser and media components, with at least one confirmed remote code execution path enabling unauthenticated root access (CVE-2026-4747)1.
Intel is a partner in both Project Glasswing and OpenAI’s Trusted Access for Cyber program2. The 2026 Intel® Platform Security Report identifies hardware-enforced software robustness as one of three foundational security capabilities engineered into Intel silicon, alongside Confidential AI and post-quantum-ready cryptography3. This article examines how those capabilities apply to the vulnerability classes the Mythos preview is surfacing and how they work together in practice.
As Anthropic noted, the results they saw were “primarily memory safety vulnerabilities”1. This is consistent with decades of industry measurement. Microsoft reports that approximately 70% of its CVEs each year are memory safety issues4. Google’s Chromium project puts the number at around 70% of serious security bugs5. Mozilla found that 32 of 34 critical and high severity bugs were memory related6. US Federal Government guidance has placed the share of memory safety vulnerabilities in the 66% to 75% range7.
Mythos did not change that distribution. It accelerated the discovery of the same underlying class of bugs at unprecedented speed and scale, collapsing the time between bug introduction and exposure.
The predominant issue is no longer finding bugs. It is surviving them at scale. When memory safety flaws can be surfaced quickly and at low cost, security cannot depend on patching alone. Defense becomes a layered enforcement challenge: memory safety, control-flow integrity, and exploit mitigation working together across the stack.
Case Study: Blocking an Exploit of a Mythos-Discovered Vulnerability
Anthropic described a Return-Oriented Programming (ROP) remote code execution exploit against FreeBSD, which Mythos generated, initiated by a kernel stack overflow. Calif subsequently used Opus 4.6 to generate an exploit that opens a root shell remotely, which they published1, 15. Intel generated proof-of-concept patches for the FreeBSD kernel to mitigate such exploits using Intel® Control-Flow Enforcement Technology (Intel® CET) and Flexible Return and Event Delivery (FRED).
The hardened kernel halts execution when Intel CET detects the first corrupted return address in the exploit. The technology includes supervisor shadow stack support to detect corrupted return addresses in the kernel. FRED is a complementary technology that is helpful for enabling supervisor shadow stack support16.
Intel applied the patches to a vulnerable version of the FreeBSD kernel and updated the addresses in the Calif exploit to match. Intel verified that the exploit still operated as expected in a baseline test with Intel CET disabled via a boot-time switch. Intel then re-ran the Calif exploit after booting with Intel CET enabled on an Intel Core Ultra Series 3 processor that includes both Intel CET and FRED and observed that the exploit was successfully blocked.
Intel CET: Control-Flow Integrity in the AI-Accelerated Exploit Chain
The exploit described above follows a recurring exploitation pattern: converting memory corruption into control-flow hijacking. A common path to successful remote code execution involves overwriting return addresses or chaining together code gadgets through Return-Oriented Programming (ROP), Call-Oriented Programming (COP), and Jump-Oriented Programming (JOP).
Intel CET is designed to disrupt this class of attacks. Anthropic’s latest research highlights hardware shadow stacks as one example of a mitigation that can significantly reduce attack surface even without eliminating every path to exploitation14. Intel CET blocks many of the exploit chains that convert memory corruption into reliable code execution through two protection mechanisms:
- Shadow Stack Protection: A shadow stack is a hardware-protected stack that stores a copy of each return address. On each RET (return) instruction, the processor verifies that the return address from the regular stack matches the corresponding entry on the shadow stack, helping prevent ROP-style control-flow hijacking.
- Indirect Branch Tracking (IBT): IBT defends against JOP and COP attacks by restricting indirect JMP and CALL instructions to designated code locations. When enabled, indirect branches can only target instructions marked with ENDBR, a special instruction that identifies valid branch targets. Attempts to branch to other locations are blocked.
Together, Shadow Stack and IBT disrupt the redirection techniques common to ROP, call-oriented attacks, and jump-oriented chains. This becomes more significant in an AI-assisted setting, where systems such as Mythos can accelerate the discovery and assembly of exploit chains, increasing the value of mitigations that break those chains even when the underlying bug remains. Intel CET directly targets this control-flow-hijacking stage.
Ecosystem Hardening
As Intel CET deployment has expanded, researchers have identified corner cases in how the Linux kernel uses Intel CET. Recent work from CISPA Helmholtz Center includes SFOP (Segmentation Fault Oriented Programming), which exploits weaknesses in Linux signal handling to chain code execution across segmentation faults13.
Notably, the SFOP researchers worked directly with the Linux kernel security team to develop patches addressing the underlying signal-handling weaknesses. This illustrates the defense-in-depth model at work: when researchers identify boundary conditions or integration weaknesses, the ecosystem responds by hardening the surrounding layers while preserving the value of the original protection.
Platform Deployment
Intel CET has shipped in production silicon since 2020, first in client platforms and subsequently extended to server platforms, and is supported by major operating systems today, with feature coverage varying by OS. The following table summarizes current Intel CET feature support across Linux and Windows.
| Intel CET Feature | Linux* Kernel | Linux* User | Win Kernel | Win User |
|---|---|---|---|---|
| Shadow Stack | No | Yes | Yes | Yes |
| IBT | Yes | No | CFG* | CFG* |
On Linux, Intel CET shadow stack currently protects userspace applications (e.g. browsers, media decoders, inference engines), while kernel IBT provides indirect branch validation at the kernel level8. As with other kernel hardening features, kernel IBT depends on compatible kernel-mode code: kernel modules built with older toolchains or without proper IBT annotations may require rebuilding before use in IBT-enabled environments. Windows supports hardware-enforced shadow stacks in both user mode and kernel mode through Hardware-enforced Stack Protection9.
Intel Memory Tagging (MTT): Strengthening Memory Safety at the Source
The Mythos disclosures also reinforce a broader reality: no single mitigation is sufficient. Several vulnerabilities from the same disclosure period included heap corruption and use-after-free (UAF) conditions in browser components, including CVE-2026-6746 (DOM/Core and HTML use-after-free), CVE-2026-6758 (WebAssembly use-after-free), and CVE-2026-6757 (invalid pointer vulnerability)10. Anthropic's kernel disclosures show the same pattern, with one chain leveraging a write to a previously freed heap object to escalate privileges1.
Intel CET focuses on preventing execution-flow hijacking after corruption occurs. Memory tagging approaches such as the upcoming x86 Memory Tagging Technology (MTT) target a complementary problem: detecting invalid memory accesses themselves, including use-after-free and buffer overflows11.
Intel MTT works by assigning hardware-enforced tags to memory allocations and checking them on subsequent accesses. If a program reads or writes memory through a pointer whose tag does not match the allocation’s, the hardware raises an exception. This catches the corruption at its origin, before an attacker can leverage it into control-flow hijacking.
MTT (previously known as ChkTag) was jointly announced by Intel and AMD in October 2025 through the x86 Ecosystem Advisory Group. The full specification is expected later in 2026. Linux kernel preparation is underway, with Intel posting patches in March 2026 adapting Linear Address Masking infrastructure for ChkTag12.
A Defense-in-Depth Stack
The technologies discussed throughout this article illustrate how layered protections address different stages of the exploit chain. Intel MTT is designed to detect invalid memory accesses at the point of corruption, often terminating execution before control-flow hijacking is possible. Intel CET helps prevent attackers from converting memory corruption into reliable code execution in environments where corruption still occurs. Together, these protections reduce exploit reliability by addressing both memory corruption and the control-flow hijacking techniques commonly used to exploit it.
This aligns with CISA’s memory safety guidance, which recognizes hardware capabilities as a valid compliance path, stating that organizations should eliminate memory safety vulnerabilities “either by using memory-safe languages or implementing hardware capabilities that prevent memory safety vulnerabilities”7.
The shift introduced by systems like Mythos is not only the scale of vulnerability discovery, but the speed at which exploitable conditions can be surfaced in long-lived software ecosystems. Large portions of critical infrastructure will continue running memory-unsafe code. These codebases cannot be rewritten overnight, and even systems that are rewritten or built from the ground up often still depend on memory-unsafe components.
As a result, defense cannot depend on any single mitigation layer. Pursuing multiple approaches is both worthwhile and complementary: catching memory corruption when it happens, breaking control-flow hijacking when corruption is leveraged, isolating workloads when all else fails, and continuing the transition toward memory-safe languages where feasible. These protections will proceed at different rates across platforms and codebases, but together they strengthen resilience.
The diagram below shows how memory safety, control-flow integrity, and memory-safe languages reinforce one another within a defense-in-depth stack.
AI is making vulnerability discovery faster, cheaper, and harder to outrun. The answer is not a single mitigation, but a stack that catches corruption, breaks exploit chains, and keeps inevitable bugs from becoming systemic compromise. In that environment, robustness must be engineered across the full stack, from hardware and firmware to the software that runs on top of them.
Share Your Feedback
We want to hear from you. Send comments, questions, and feedback to the INT31 team.
Acknowledgments
I thank Michael LeMay, Simon Johnson, Scott Constable, and Joe Cihula for their technical reviews and feedback. Brian Delgado built the Intel CET proof-of-concept discussed here.
About the Author
Asmae Mhassni leads Intel’s Software Robustness pillar, driving defense-in-depth strategies that strengthen software resilience from silicon through the broader ecosystem. Her work spans hardware-enforced software robustness, memory safety, and trust infrastructure for AI systems. She co-leads the Software Supply Chain Security Working Group within the Coalition for Secure AI (CoSAI), advancing industry-wide collaboration on securing AI systems, and previously led Confidential AI architecture efforts at Intel.
Sources
1 Nicholas Carlini et al., “Assessing Claude Mythos Preview’s cybersecurity capabilities”, https://www.anthropic.com/research/mythos-preview
2 Intel, “Securing Hardware and Software for the AI Era with Project Glasswing,” April 9, 2026. intel.com/content/www/us/en/security/security-practices/blogs/securing-hardware-software-for-ai-with-glasswing.html
3 Intel, “2026 Intel Platform Security Report,” March 2026. intel.com/content/www/us/en/content-details/915147/2026-intel-platform-security-report.html
4 Microsoft Security Response Center, “A Proactive Approach to More Secure Code,” July 2019.
5 Google Chromium Security, “Memory Safety.” chromium.org/Home/chromium-security/memory-safety/
6 CISA, “The Urgent Need for Memory Safety in Software Products,” September 2023. Citing Mozilla findings that 32 of 34 critical and high-severity bugs were memory-related.
7 White House ONCD, “Back to the Building Blocks: A Path Toward Secure and Measurable Software,” February 2024; CISA memory safety guidance, 2023; NSA/CISA joint guide, June 2025.
8 Linux kernel documentation, “CET Shadow Stack.” kernel.org/doc/html/v6.6/arch/x86/shstk.html
9 Microsoft, “Kernel Mode Hardware-enforced Stack Protection,” October 30, 2024. learn.microsoft.com/en-us/windows-server/security/kernel-mode-hardware-stack-protection
10 NVD, “CVE-2026-6746”; NVD, “CVE-2026-6758”; NVD, “CVE-2026-6757”; NVD, April 2026. nvd.nist.gov
11 Intel Community Blog, “ChkTag: x86 Memory Safety,” October 2025.
12 Phoronix, “Intel Adapting Linux’s LAM in Preparing for ChkTag,” March 2026.
13 Bajo et al., “Crashing Through Defenses: Exploiting Segfaults and Chaining Around Intel CET,” IEEE S&P 2026. DOI: 10.60882/cispa.32304933
14 Anthropic Frontier Red Team, “N-days,” June 8, 2026. red.anthropic.com/2026/n-days/
15 Calif, “MAD Bugs: Claude Wrote a Full FreeBSD Remote Kernel RCE with Root Shell (CVE-2026-4747)”, https://blog.calif.io/p/mad-bugs-claude-wrote-a-full-freebsd.
16 Peter Zijlstra, “Re: [PATCH v3 00/21] Enable CET Virtualization”, https://lore.kernel.org/lkml/20230720080947.GA3570477@hirez.programming.kicks-ass.net/