The Reality Check of AI-Turbocharged Vulnerabilities

Project Glasswing brought to light what many security teams already suspected: AI is changing the economics of vulnerability discovery. Anthropic described Claude Mythos Preview as an unreleased frontier model capable of finding and exploiting software vulnerabilities at a level that can surpass all but the most skilled human researchers. Through Project Glasswing, Anthropic is giving selected enterprises and major technology partners early access so they can identify and remediate weaknesses in critical software before similar capabilities proliferate more broadly.

For automotive, mobility and physical AI ecosystems, the question is not only: “What does this mean for Linux, browsers, OpenSSL, Android, or other global software foundations?” The more urgent question is: what happens when the same AI-assisted research techniques are applied to product-specific software, embedded protocol stacks, diagnostic tooling, OTA clients, gateways, and legacy ECUs?

Was Project Glasswing really the first warning?

Automotive and smart mobility received several warnings in 2025. Public reporting around a UK OEM’s ransome attack included claims that attackers used an ERP zero-day. Separately, Google Threat Intelligence Group and Mandiant reported another large ERP extortion campaign in which different actors exploited what may have been CVE-2025-61882 as a zero-day weeks before a patch was available.

While there is no public evidence that these zero-days were created by AI, we cannot help but wonder about the sudden abundance of zero-days targeting legacy enterprise software in a short time period. We learned that attackers are increasingly willing to use enterprise-platform zero-days against: ERP, CRM and other legacy systems, suppliers, dealers, logistics, and manufacturing environments.

The OpenSSL signal

In January 2026, OpenSSL became another strong signal. The OpenSSL project released a security advisory covering 12 CVEs; Node.js assessed that three of them affected Node.js, mainly around PFX / PKCS#12 certificate processing. AISLE stated that its autonomous analyzer found all 12 CVEs in the January 2026 coordinated OpenSSL release, including high, moderate, and low severity findings, and that some bugs had existed for years in one of the most scrutinized security libraries in the world.

The practical implication: a surge of vulnerabilities in a foundational component does not stay “IT only.” It can cascade into connected-product operations, OTA readiness, supplier risk, dealer portals, certificate lifecycle management, diagnostic tooling, and long-lived embedded software.

Connected products are not patched like web applications 

Project Glasswing and similar initiatives will naturally focus on critical open source infrastructure: operating systems, browsers, cryptographic libraries, cloud platforms, and widely deployed frameworks. That is necessary,  but insufficient for automotive and smart mobility.

A recent analysis of 39 public CVEs disclosed between April 22 and May 1, 2026, highlighted that 18 of them were in automotive and embedded software, across projects tied to Open-SAE-J1939, ISO-TP, UDS, socketcand, cannelloni, OpenAMP, OVMS3, Automotive Grade Linux, and Vanetza. The same analysis points to surfaces such as CAN parsers, diagnostic request builders, gateways, PCAP/GVRET import paths, V2X packet processing pipelines, embedded ELF loaders, local supervision sockets, and widget installation paths.

Connected products are not patched like web applications. Stakeholders may need to support multiple platforms, ECU generations, supplier-owned components, homologated software, regional variants, aftersales tooling, and systems already in production for 10–15 years.

AI-assisted vulnerability discovery compresses the time between “unknown bug” and “actionable exploit.” Anthropic says Mythos Preview has already found thousands of zero-day vulnerabilities across major operating systems, browsers, and other important software, and that it does not plan to make Mythos generally available yet because of the risk profile. But Anthropic also warns that frontier AI capabilities are advancing quickly and that similar capabilities may not remain limited to safety-aligned defenders.

A reasonable planning assumption is that Mythos-class or near-Mythos-class vulnerability discovery capabilities could become more broadly available within the next 6–12 months, possibly much sooner. That timeline should be treated as a risk-planning assumption, not a forecast. The point is not to predict the exact date. The point is to test whether the organization can respond if the vulnerability discovery curve steepens abruptly.

How can security teams prepare for an expected surge of vulnerabilities?

Awareness and readiness are a must, starting with asking the right questions and challenging assumptions and capabilities for what’s to come:

1. Exposure and ownership
Can the organization identify which products, ECUs, backend systems, diagnostic tools, dealer platforms, and supplier components use the affected libraries? Is the SBOM complete enough to support this in hours, not weeks?

2. Exploitability and prioritization
Can the product-security team distinguish between theoretical presence and reachable exposure? Which vulnerabilities affect externally reachable systems, local wireless interfaces, diagnostic paths, OTA flows, or safety-relevant components?

3. Patch feasibility
Which components can be patched through OTA, which require dealer intervention, which depend on supplier releases, and which are effectively legacy or end-of-life but still deployed in the field?|

4. No-warning disclosure
What happens if the vulnerabilities are not disclosed privately in advance? Can stakeholders move from public CVE to exposure assessment, mitigation, supplier coordination, customer communication, and regulatory decision-making within a compressed window?

5. Legacy compromise
Is the organization prepared to patch or isolate old components if they become seriously compromised? This includes components that were never designed for rapid patching but may become attractive once AI-assisted research makes their bug families easier to find.

6. Early-warning channels
Is the organization connected to the right disclosure communities, open source maintainers, Project Glasswing participants, industry ISACs, supplier PSIRTs, and threat-intelligence channels to receive early signals?

7. Proactive timelines
What can be done in 30, 60, and 90 days? The answer should include SBOM validation, parser fuzzing, protocol-stack review, supplier evidence requests, OTA-readiness checks, and escalation playbooks.

Cyber threat intel serves as a catalyst 

The key question is no longer only “who is targeting us?” It is also: “Who is trying to turbocharge vulnerability discovery against the assets we depend on?”

That means tracking chatter and capability development around product protocols, diagnostic stacks, infotainment software, OTA clients, charging infrastructure, ERP platforms, supplier portals, dealer systems, and embedded Linux components. It also means monitoring whether criminal groups begin advertising AI-assisted vulnerability discovery, variant hunting, or exploit development as part of their offering.

Beyond Project Glasswig: securing AI modules alongside legacy systems

AI-assisted vulnerability discovery will improve defensive security. It will help open source maintainers find bugs that humans and traditional tools missed. It will help vendors harden code, scale triage, and reduce exposure.

But organizations should not assume that the benefit will be evenly distributed.

Large, globally important projects may receive early attention through initiatives like Project Glasswing. Automotive and smart mobility software may not.
Legacy components may not.
Supplier-maintained diagnostic tools may not.
Internal gateways, protocol converters, engineering parsers, and test utilities may not.

That is where organizations need to act.

The next wave of automotive cybersecurity will not be defined only by connected APIs, mobile apps, or cloud accounts. It will also be defined by the parser below the API, the library below the product, the diagnostic path below the service flow, and the legacy component below the modern software-defined narrative.

In today’s reality, vulnerabilities are not just being discovered at the rate and depth they used to. They are being turbocharged.