AI-Accelerated Vulnerability Discovery: An Emergency in Software Security. Is Hardware Next?

By Andreas Kuehlmann

May 27, 2026

Frontier AI has crossed a major capability threshold in security research, identifying vulnerabilities in production software at a speed, scale, and cost no human team can match. Anthropic’s Claude Mythos and OpenAI’s GPT-5.5-Cyber are gated distributions because public release was judged too risky. This month, Google’s Threat Intelligence Group confirmed the first case of a threat actor weaponizing an AI-developed zero-day.

This article summarizes what frontier AI has demonstrated for software security, considers whether hardware will follow, and what might be done about it. In this context, the term “hardware” refers specifically to semiconductor chips, the parts where security exposure is most relevant.

Frontier AI capabilities and their impact on cybersecurity

Mythos achieves 93.9% on SWE-bench, the standard benchmark of real-world software-engineering tasks drawn from open-source GitHub issues. It achieves 73% on the “expert-level cybersecurity tasks” on which every prior LLM (large language model) scored zero. It is the first model to complete the UK AI Security Institute’s 32-step “The Last Ones” network-takeover range end-to-end.

Mythos’s security findings span several categories of software. Among others, it found bugs in OpenBSD and the Linux kernel. It found 271 zero-day bugs in the popular Firefox web browser. In cryptographic libraries, it found bugs in TLS, SSH, and AES-GCM. And in firmware, it found chains that allowed root access on smartphones.

Why can’t AI do the same for hardware (yet)

Notably, neither Mythos nor GPT-5.5-Cyber has produced any hardware security vulnerability such as Spectre/Meltdown-class CPU side channels, GPU shader-compiler exploits, baseband modem bugs, or UEFI/BIOS findings. Three structural asymmetries between software and hardware help explain why AI frontier models have, so far, surfaced no notable hardware security issues.

The first is the history. Software security has been accumulating defenders, tooling, and conventions for nearly four decades. For example, the CVE program standardized vulnerability tracking in 1999. Hardware as a recognized security category is barely older than Spectre and Meltdown, both of which landed in January 2018. The hardware security community is still early in the maturation cycle of a discipline that software security has been developing for decades.

The second is the openly available corpus. Open-source software from which LLMs can learn includes, among many others, 3.1 million npm packages, 820,000 PyPI packages, and 395 million public GitHub repositories. In contrast, open-source hardware is orders of magnitude smaller: 850+ archived OpenCores cores, a few dozen open RISC-V designs and other similar initiatives.

The third is the usage gap. The 2026 Black Duck OSSRA report found open-source software in 98% of 947 audited commercial codebases, averaging 911 components per codebase. One flaw in a widely used component becomes a vulnerability in tens of thousands of software products at once. Production silicon, built almost entirely from third-party or in-house proprietary IP (intellectual property), has no such impact radius.

Figure 1: Hardware Security — Emerging Frontier for Cyber Attacks, Source: Arteris, Inc.

How AI might trigger a hardware security emergency

The historical record on hardware vulnerabilities suggests an industry already in the early phase of the same trajectory the software industry has followed for more than fifteen years.

As the single most important trigger, in 2018, Spectre and Meltdown fundamentally overturned the assumption that hardware was inherently more secure than software. Similarly, for most of the CVE era, hardware barely registered. In 2014, the NVD listed only a single CVE tagged with a hardware-security common weakness enumeration (CWE). Since then, they have grown exponentially, see Figure 2.

Figure 2: CVEs by NIST National Vulnerability Database, Source: https://nvd.nist.gov

The path through which the power of AI could transform hardware security is likely different from what has been experienced for software. Here are four components to closely monitor:

Learning from open-source designs. Security-relevant open-source designs such as OpenTitan, Caliptra, OpenSPARC, and others teach LLMs general architectural and design patterns and related potential security weaknesses. As such patterns are utilized in proprietary designs, these weakness candidates can be applied in comprehensive attack experiments described below.

Absorbing published research. The bottleneck on academic hardware security work has historically been how many papers, errata, and patents researchers could read, digest and then apply to find new attacks. An LLM can ingest the full body of openly available hardware-security research, patents, and the entire hardware CWE and CVE databases. With this, the labor-intensive bottleneck disappears.

Accelerating tedious manual work. Hardware security research today is mostly manual: studying vendor documentation, reverse-engineering errata, building fuzzing harnesses, and large amounts of trial and error. AI is well suited for automating the high-effort steps and broadening the search to thousands if not millions of variations, compressing months of work into hours.

Automating synthesis and execution of live attacks. AI could perform a massive number of attack experiments by rapidly generating candidate scripts and executing them automatically. Using the above-mentioned resources, it can combine known and zero-day software and hardware vulnerabilities into complex attack scenarios and then apply them against remote targets. Every partial success of an attack experiment can add lessons to the model’s knowledge corpus, making it increasingly powerful for ultimate success.

How to prepare for accelerated hardware security discoveries

While the software and hardware “bug fixing lifecycle” are quite similar during the development process, they vastly differ once the product is shipped. Urgent software vulnerabilities can be resolved and distributed in days, if not hours. In contrast, vulnerabilities in silicon can sometimes be mitigated by microcode, firmware, or compiler updates. Yet, many silicon bugs cannot be patched at all without replacing the chip.

Given the significant economic impact, preparing for an acceleration of hardware security discoveries means treating security assurance as a first-class business objective, on par with innovation, quality, time-to-market, and budget allocation. Below are four areas to pay increased attention to.

Proactive prevention. Shift security verification left by applying it during the design phase in lockstep with functional verification, from block to system-on-chip (SOC) to firmware. Formal tools (Cadence, Synopsys, Siemens) cover block-level concerns; information-flow methods, for example in Arteris Radix, scale from blocks to full-system signoff before tape-out. Asset- and CWE-based methodologies (such as this guide) turn high-level security goals into verifiable requirements.

Comprehensive incident response. Build a hardware-side incident response comparable to what software organizations have built over years. Engineering, legal, and customer-communication teams must act quickly. Root-cause analysis, mitigation, and customer notification need to compress from quarters to weeks or days.

Upstream and downstream supply-chain visibility. Build supply-chain visibility in two directions. Upstream: which third-party components (IP blocks, firmware modules) sit inside each chip and their security posture. Downstream: which products and customers include each chip and how to reach them with a fix. Establish a security-annotated bill of materials (BOM) with an HBOM (hardware bill of materials) alongside the established SBOM (software bill of materials). Without it, incident response cannot scale.

Standards and regulatory compliance. Apply relevant standard frameworks. They provide structure for a comprehensive hardware security program and legal cover in the event of a breach. Examples include Common Criteria (ISO/IEC 15408), FIPS 140-3, IEC 62443, PSA Certified, ISO/SAE 21434 (automotive), FDA Section 524B (medical), UN-ECE R155/R156, the EU Cyber Resilience Act (CRA), and more. AI-accelerated discovery will compress incident-response timelines and significantly raise the compliance bar.

Conclusion

Recent frontier AI models have triggered a wake-up call in the software security industry. The drastic acceleration of vulnerability discoveries is changing the entire dynamic of the software development, delivery, and maintenance lifecycle.

Semiconductor executives have been alarmed by recent AI cybersecurity news. While notable hardware vulnerabilities discovered or exploited by AI models have yet to be reported, it’s reasonable to assume they will occur soon, though not necessarily in the same way as in software.

There are multiple opportunities to prepare for such a scenario. Most important, semiconductor companies need to treat security assurance as a first-class business objective, on par with innovation, quality, and time-to-market. This includes instituting rigorous security verification with crisp security signoff during the chip design phase, establishing a comprehensive incident response program, maintaining upstream and downstream supply-chain visibility supported by a security-annotated HBOM, and meeting regulatory compliance requirements.

The risk on the horizon is that sophisticated AI-automated attacks combining known and zero-day software and hardware vulnerabilities could impact the industry in ways it has not seen before. Preparing now is significantly cheaper than reacting after the first headline-grabbing hardware security emergency.

To learn more about semiconductor cybersecurity solutions, visit arteris.com.