Generative AI is accelerating exploit development and shrinking the window between vulnerability disclosure and real-world attacks. OEMs and suppliers must move beyond CVSS-centric operations to stay ahead.
Key Points of This Blog
While AI enhances the efficiency of defenders, it is also undoubtedly beginning to lower the cost of exploit development for attackers.
This shift has a significant impact, particularly in the automotive industry, where fixes take time.
Future vulnerability management must incorporate not only severity but also the perspective of "how quickly it can be turned into an attack."
The Reality of an Era Where "It Doesn't Stop at PoC" — An Era AI Has Begun to Reshape
Note: In this blog, the term "exploit" refers not only to proof-of-concept (PoC) code used to confirm the existence of a vulnerability, but also to attack code and techniques designed to cause actual harm, such as privilege escalation or arbitrary code execution.
In recent years, the evolution of generative AI has begun to have a significant impact not only on software development and operational efficiency but also on the feasibility of cyberattacks.
Until the first half of 2025, the focus was on AI generating PoCs based on CVE (Common Vulnerability and Exposures) information and patch diffs. This alone was a significant change, as it drastically reduced the time and cost for attackers to develop proof-of-concept code after vulnerability information was disclosed.
However, what has become apparent since the start of 2026 is the next stage.
The shift is that AI is no longer limited to simply generating PoCs; it is now venturing into the development of more practical exploits, and even remote kernel exploits.
A symbolic example of this is CVE-2026-4747 in FreeBSD, reported in April 2026. According to the researcher's published report, the AI used a vulnerability advisory as a starting point to proceed with building a verification environment, triggering the vulnerability, adjusting offsets, and creating an exploit, including ROP (Return-Oriented Programming), ultimately resulting in the acquisition of a reverse shell with root privileges. Furthermore, it is reported that the AI carried out these tasks even when a human was not actively operating the terminal (AFK, or "away from keyboard").
Note: This finding is based on a single researcher's published account and has not been independently verified.
What is noteworthy is that the cost of exploit development for attackers is beginning to decline even further.
What Were the Assumptions Up Until Now?
The perception that "even if a proof-of-concept is released, it will take time to develop a stable exploit"
Traditionally, in many manufacturing industries, including the automotive sector, the following was a realistic assumption regarding vulnerability management:
A CVE is published.
A PoC may appear.
However, turning it into a stable exploit still requires significant technical expertise and time.
While this premise has not completely disappeared, as AI becomes capable of handling part of exploit development, the gap between PoCs and exploits narrows.
It is understood that the AI did not simply generate code snippets, but rather sequentially addressed multiple technical challenges, such as the following:
Setting up a FreeBSD environment for verification.
Preparing an accessible lab environment, including NFS (Network File System) and Kerberos.
Delivering the payload in multiple stages.
Offset adjustment.
Transition from the kernel context to userland.
In other words, AI is not merely stating that "there appears to be a vulnerability"; it is actively engaging in the process of refining exploits by correcting failures to bring them closer to success. This is a change that defenders cannot afford to ignore.
What Changes for Attackers?
Parts of advanced exploit development will begin to be carried out more quickly and at lower cost
The key point is that certain aspects of advanced exploit development may begin to operate more quickly and at lower cost than before.
If attackers leverage this AI capability, the time between a vulnerability being disclosed and actual damage occurring could become even shorter.
Until now, exploit development required more than just reading CVEs; it involved building a reproduction environment, analysis, debugging, code modification, and repeated trial and error. As a result, there were certain bottlenecks on the attacker's side.
Once AI can assist with this process, attackers gain meaningful advantages across the entire exploit development cycle. Attack strategy formulation accelerates based on public advisories, while vulnerable area identification via patch diffs becomes faster and more precise. Verification environment setup and debugging, previously among the most time-consuming steps, can be compressed significantly. And when an attempt fails, AI shortens the correction cycle, making it easier to iterate across multiple targets in parallel.
The change for attackers is not that previously impossible attacks suddenly become possible. Rather, exploit development that until now could only be carried out in a short timeframe by a select few experts will now proceed more widely, more quickly, and in greater parallel.
Why Is This Important for the Automotive Industry?
Attacks are accelerating, while fixes cannot be completed immediately
In the automotive sector, this impact is even greater.
Vehicles take time to patch, and the exposure period after a vulnerability is disclosed tends to be longer. This extended exposure window is a recurring concern in automotive cybersecurity and is also reflected in the VicOne 2026 Automotive Cybersecurity Report. If attackers can develop exploits faster while defenders remain slow to patch, that gap becomes a direct risk.
The following factors explain why the cycle from vulnerability disclosure to resolution tends to be longer for automotive systems than for general IT systems:
Multi-tiered lines of responsibility spanning component suppliers.
Complex interdependencies among ECUs (Electronic Control Units), gateways, telematics, IVI (In-Vehicle Infotainment), and the cloud.
Update processes involving safety assessments and quality assurance.
Configurations that cannot be immediately patched via OTA (over-the-air software updates).
The reality that deploying updates to vehicles already on the market takes time.
Development and mass production systems that require not only fixes but also re-verification and approval.
If the speed at which attackers can exploit vulnerabilities is accelerated by AI, the disadvantage faced by the defense side will widen further.
In future vulnerability management, simply assessing severity will no longer suffice. Priorities must be reassessed based on how quickly a vulnerability can be exploited from publicly available information.
What Will Be Missing in Vulnerability Management in the AI Era Under Traditional CVSS-Centric Operations?
Issues that are difficult to identify using CVSS alone are increasing
In traditional vulnerability management, metrics such as CVSS (Common Vulnerability Scoring System), EPSS (Exploitability Prediction Scoring System), the presence or absence of published PoCs, internet exposure, and the criticality of affected assets have been commonly used. These will remain important.
However, in an era where AI is accelerating exploit development, the following additional perspectives are necessary.
1. Assessment of Exploitability
Going forward, it will be necessary to assess not only whether a proof-of-concept (PoC) exists, but also whether an exploit can be easily created using publicly available information alone.
Vulnerabilities that meet the following conditions are considered more dangerous:
Detailed information about the vulnerability has been made public.
Patch tracking is straightforward.
Similar exploits have existed in the past.
It is easy to set up a debugging or reproduction environment.
Mitigation mechanisms are weak.
Known exploitation techniques are easy to repurpose.
2. Ease of Chaining Vulnerabilities
Even vulnerabilities that appear moderate on their own can become extremely dangerous when combined with other weaknesses or vulnerabilities.
AI excels at combining known attack patterns. Therefore, the limitations of an approach that focuses on individual CVEs will become increasingly apparent.
3. Accessibility and Lateral Movement Potential
The danger posed by a vulnerability cannot be determined by CVSS alone. It is necessary to consider attack entry points and chains, such as via diagnostics, OTA, Bluetooth/Wi-Fi/cellular communications, from IVI to gateways, from the cloud to vehicles, and from supplier tools to manufacturing and maintenance networks.
4. Presence of Hardening Measures
Even if a vulnerability exists, exploitation becomes difficult if measures such as privilege separation, memory protection, execution control, enhanced authentication, network segmentation, and anomaly detection are in place. Conversely, if these measures are weak, the effectiveness of AI-assisted exploitation increases.
What Should Manufacturers and Suppliers Review?
"Managing CVEs" alone is not enough
Given these changes, vulnerability management in the automotive industry must move beyond CVE registry management.
1. Move Away from CVSS-Centric Operations
CVSS is necessary, but it is not sufficient on its own. Going forward, each vulnerability must be evaluated against four additional questions: whether it is susceptible to AI-assisted exploitation, whether it can be reached by reusing known techniques, whether the attack surface is remotely exposed, and whether lateral movement is feasible after exploitation. Any vulnerability that checks multiple boxes here warrants elevated priority regardless of its raw CVSS score. Structured penetration testing and vulnerability assessment can help teams systematically evaluate these dimensions across ECUs and connected systems.
2. Accelerate Collaboration Between PSIRT and Development/Design Teams
Immediately after vulnerability information is disclosed, the priority is not to add the CVE number to the management ledger but to determine whether the vulnerability affects the company's products or supply chain and could lead to actual damage in the short term.
To do this, cross-functional decision-making is essential, involving not only the PSIRT (Product Security Incident Response Team) but also product design, software development, architects, the SOC (Security Operations Center), the CSIRT (Computer Security Incident Response Team), and quality assurance.
3. Do Not Treat TARA as a One-Time Compliance Artifact
TARA (Threat Analysis and Risk Assessment) is the risk assessment process required by ISO/SAE 21434, and it is intended to be conducted repeatedly from the early stages of design. Compliance with WP.29/UN-R155 similarly mandates that cybersecurity risk management be treated as a continuous process, not a one-time activity. If the assumptions regarding attacker capabilities change, the feasibility of an attack should be reevaluated.
AI has changed the very premises of risk assessment across four dimensions: it reduces the time required for exploit development, lowers the expertise threshold for attackers, accelerates vulnerability chaining exploration, and removes barriers to setting up experimental environments. Each of these shifts directly affects how realistic a previously theoretical attack path becomes.
4. Prioritize Designs That Are Difficult to Exploit Even When Vulnerabilities Are Found
The goal going forward is not to assume zero vulnerabilities — it is to ensure that a single vulnerability does not immediately lead to actual harm. Three categories of measures will become more critical than ever:
Separation and isolation: Strong privilege separation, hardened boundaries between ECUs, and strict authentication of diagnostic and maintenance functions.
Memory and execution hardening: Improved memory safety, exploit mitigation mechanisms (memory protection, execution control, code integrity protection), and minimized attack surfaces for OTA and maintenance systems.
Detection and containment: Enhanced logging, monitoring, and anomaly detection, combined with active prevention of lateral movement through communication control and detection of abnormal behavior.
This Is an Equally Critical Issue for Suppliers
Attackers target the weakest points
This issue is not limited to OEMs. It is also extremely important for Tier 1 and Tier 2 suppliers, software vendors, verification vendors, and maintenance tool providers.
Attackers target the weakest point. This applies not only to the vehicle's ECU. The following will also become targets for exploitation more quickly in the AI era:
Development tools.
Diagnostic tools.
OTA-related backends.
Dealer systems.
Supply chain connection points.
Shared libraries and middleware.
Suppliers must therefore adopt a mindset that goes beyond ensuring the software they deliver to OEMs functions properly. They must consider how to maintain a security buffer in a world where the time between a vulnerability's disclosure and its exploitation has grown shorter.
Vulnerability Management Will No Longer Be About Maintaining a List — It Will Become a Race Against Time
To put this shift plainly: vulnerability management is evolving from a task of confirming how many systems are affected to one of identifying which vulnerabilities will be exploited the fastest.
In the first half of 2025, the focus was on AI accelerating the process from CVE information to proof-of-concept (PoC) creation. What is beginning to emerge as of 2026 is a stage where AI can go from CVE information all the way to exploit code.
This difference is significant. While a PoC may remain merely a verification tool, a practical exploit directly leads to real-world damage.
Automakers and suppliers have now reached a point where they must reevaluate their approaches to vulnerability management, PSIRT operations, design principles, TARA, and supply chain management to align with the AI era. The ability to anticipate which vulnerabilities can be exploited, through which pathways, and how quickly, will be more critical than ever.
Summary
While AI enhances the efficiency of defenders, it is also undoubtedly beginning to lower the cost of exploit development for attackers. This shift has a particularly significant impact on the automotive industry, where patches take time to implement. Moving forward, vulnerability management must go beyond severity ratings and incorporate the ability to assess how quickly a vulnerability can be turned into an attack.
Reference Article
Calif, "MAD Bugs: Claude Wrote a Full FreeBSD Remote Kernel RCE with Root Shell (CVE-2026-4747)"
About the Author
Seigo Yamamoto is a Principal Security Researcher from the Threat Research Group of the Engineering Department at VicOne. After working in IT system operations and development, Seigo Yamamoto has been conducting security assessments, penetration testing, and security consulting for systems in IT, cloud, IoT, and automotive sectors since 2014. He is currently responsible for automotive vulnerability research, security consulting, and penetration testing at VicOne.
