Key points of this blog 

• Sony firmware version 3.04.00 addresses seven XAV-9500ES vulnerabilities discovered during Pwn2Own Automotive 2026, co-hosted by VicOne and TrendAI Zero Day Initiative (ZDI). 
• The flaws form four attack paths: network-adjacent Real-Time Streaming Protocol (RTSP), Bluetooth L2CAP, Bluetooth AVRCP, and physical or local access. The RTSP flaw scores 8.8 on CVSS. 
• Modern IVI security should be assessed across the full system, as one vulnerable interface can provide a path to broader device compromise. 

Sony has released firmware version 3.04.00 for the XAV-9500ES in-vehicle infotainment (IVI) system, addressing security vulnerabilities affecting its Bluetooth, Wi-Fi, and USB functions. 

On July 29, 2026, 13 days after Sony published the update, TrendAI Zero Day Initiative (ZDI) disclosed seven vulnerabilities: CVE-2026-18278 through CVE-2026-18284. Researchers discovered the vulnerabilities during Pwn2Own Automotive 2026, the automotive zero-day vulnerability discovery competition co-hosted by VicOne and ZDI.  

The findings show how vulnerabilities across different interfaces on the same IVI system can provide network-adjacent, Bluetooth-based, and physical or local paths to compromise a device. 

This blog examines the vulnerabilities addressed by firmware 3.04.00, how they could have affected the XAV-9500ES, and what users and organizations managing affected units should do next. 

What Sony patched in firmware 3.04.00  

Although Sony’s release notes do not identify the individual CVEs or affected components, all seven ZDI advisories point affected users to firmware version 3.04.00. 

Table 1. The seven vulnerabilities addressed in Sony’s firmware 3.04.00 

Rather than seven isolated issues, the vulnerabilities represent four practical attack paths: network-adjacent RTSP, Bluetooth L2CAP, Bluetooth AVRCP, and physical or local access. Their different prerequisites and how some flaws can be combined shape their potential impact.  

How each attack path works 

Wi-Fi attack path: Network-adjacent code execution through RTSP 

CVE-2026-18279 is the highest-severity vulnerability among the seven, carrying a CVSS score of 8.8. The flaw exists in the handling of Real-Time Streaming Protocol (RTSP) SETUP packets. According to the ZDI advisory, the system does not properly validate the length of attacker-controlled data before copying it into a fixed-length buffer. 

An attacker with network-adjacent access could send a malformed SETUP packet and execute arbitrary code in the device’s context.  

Why it matters: Unlike the other disclosed attack paths, CVE-2026-18279 requires no Bluetooth pairing, no USB access, no authentication, and no user interaction. The attacker only needs to reach the affected RTSP service over an adjacent network. 

Modern IVI head units are more than stereos. They are connected systems with services and components that manage navigation, smartphone integration, audio input, and other connected peripherals. A flaw in an unauthenticated network service can put more than media playback at risk, providing a path to broader device compromise once an attacker gains network-adjacent access. 

Bluetooth:  L2CAP and AVRCP vulnerabilities requiring device pairing 

Three of the seven vulnerabilities affect Bluetooth components and require an attacker to first pair a malicious Bluetooth device with the XAV-9500ES. Pairing authorizes the connection but does not protect the underlying parsers from malformed data sent by the paired device. 

Bluetooth L2CAP vulnerabilities (CVE-2026-18278 and CVE-2026-18281) 

These two vulnerabilities affect the processing of Bluetooth Logical Link Control and Adaptation Protocol (L2CAP) packets: 

• CVE-2026-18278 is an out-of-bounds read in prh_l2_decode_packet. It could disclose sensitive information that may support further exploitation. 
• CVE-2026-18281 is a heap-based buffer overflow in l2_reassemble_sdu. It could allow arbitrary code execution in the context of the device. 

Bluetooth AVRCP vulnerability (CVE-2026-18282) 

CVE-2026-18282 is a heap-based buffer overflow in AVRCP_Br_Response_Parser. After pairing a malicious Bluetooth device, an attacker could send a crafted Audio/Video Remote Control Profile (AVRCP) response and execute arbitrary code in the context of the device. 

Physical and local vulnerabilities: USB bypass, gpsd overflow, and root-level command injection 

The remaining three XAV-9500ES vulnerabilities require physical access to the device or prior code execution. Individually, each has a bounded scope. Together, they can chain into a path to root-level access. 

• CVE-2026-18283 is an authorization bypass in the udev USB rules. A crafted USB device could cause the system to instantiate otherwise restricted USB device types. 
• CVE-2026-18280 is a buffer overflow in the gpsd daemon’s handling of NMEA data. When combined with other vulnerabilities, it could enable code execution in the context of the daemon. 
• CVE-2026-18284 is a command-injection vulnerability in the crash-dump handler. An attacker with low-privileged code execution could exploit it to execute code as root. 

ZDI also reported that a three-vulnerability chain demonstrated during Pwn2Own Automotive 2026 achieved root-level code execution on the XAV-9500ES. However, public sources do not identify the CVEs used or disclose the chain’s precise sequence. 

How physical USB access could lead to root access

VicOne’s CyberThreat Research Lab used the Auto-ISAC Automotive Threat Matrix (ATM) to examine a hypothetical path connecting physical USB access, service-level code execution, and local privilege escalation. While this specific chain has not been publicly documented, it illustrates why IVI interfaces should be assessed in relation to the services and privilege boundaries they can reach. 

The table below outlines the potential progression, corresponding ATM mappings, and technical conditions required for each step. 

Table 2. Potential USB-to-root attack path mapped to the Automotive Threat Matrix 

 Simply put: At 2.4, CVE-2026-18283 has the lowest CVSS score among the seven vulnerabilities. Yet in this hypothetical path, the authorization bypass could help create the conditions for code execution and privilege escalation. This shows why lower-severity flaws should be assessed within broader attack paths rather than in isolation. 

What affected users should do next 

Owners and installers of the Sony XAV-9500ES should install firmware version 3.04.00. Sony recommends updating through USB tethering, although users can also install the firmware using a USB storage device, and advises maintaining stable power, avoiding interruptions, and confirming the installed version afterward. 

Until the update is installed: 

• Limit the head unit’s connections to trusted wireless networks. This reduces exposure to the network-adjacent RTSP attack path. 
• Reject unexpected Bluetooth pairing requests. Pairing is required to reach the affected L2CAP and AVRCP parsers. 
• Do not connect unknown USB devices. Physical USB access is required for the disclosed authorization-bypass vulnerability. 

Why IVI attack surface security requires a system-level view 

In-vehicle systems accounted for 39.7% of observed targeting across 610 automotive cyber incidents in 2025, according to VicOne’s 2026 Automotive Cybersecurity Report, published February 2026, with IVI systems and head units at 12%. IVI systems now connect drivers, devices, applications, and vehicle components, which makes the head unit a central point of exposure. 

The XAV-9500ES vulnerabilities illustrate why that centrality creates risk: weaknesses across network services, Bluetooth parsers, USB functions, location services, and privileged system handlers can create distinct paths to code execution or elevated access on the same device. 

• The real risk is not any single vulnerability. It is the combination. A lower-severity flaw may have limited impact on its own but can help an attacker gain information, bypass a restriction, or reach another vulnerable component. Assessing how vulnerabilities interact, rather than evaluating each CVE in isolation, reveals the broader paths that individual CVSS scores may not fully represent. 
• Addressing these risks requires three things throughout the product lifecycle: 
• System-level security testing that evaluates interfaces holistically, not component by component. 
• Coordinated vulnerability disclosure that gives vendors time to patch before public exposure. 
• Timely patch deployment by OEMs, installers, and fleet operators managing affected units. 

VicOne's Smart Cockpit Protection helps OEMs and suppliers detect unsafe Wi-Fi hotspots, vulnerable browsers, malicious URLs, and risky applications in IVI environments. The xNexus platform provides unified visibility into system- and application-level risks, enabling VSOC teams to monitor and manage threats across the smart cockpit environment. 

Frequently asked questions 

What do the Sony XAV-9500ES vulnerabilities reveal about infotainment attack surfaces? 

The vulnerabilities show that a single head unit can expose several attack paths through Wi-Fi, Bluetooth, USB, and local system services. Protecting this environment requires visibility across the connectivity and application layers, not just individual component assessments. 

Why can lower-severity vulnerabilities still matter in an IVI attack path? 

A lower-severity vulnerability may have limited impact on its own but could help an attacker gain information, bypass a restriction, or reach another vulnerable component. Assessing how vulnerabilities interact can reveal broader paths to code execution or elevated privileges that individual CVSS scores may not fully represent. 

How does VicOne help secure IVI and smart cockpit systems? 

VicOne’s Smart Cockpit Protection helps OEMs and suppliers detect unsafe Wi-Fi hotspots, vulnerable browsers, malicious URLs, and risky applications. The xNexus platform provides unified visibility into system- and application-level risks, enabling security teams to monitor and manage threats across the smart cockpit environment. 

A background on coordinated disclosure timelines  

The timeline of public vulnerability disclosures can seem unclear to many. For example, there is often a delay between TrendAI ZDI’s announcement that a team has successfully hacked or “pwned” a device at a Pwn2Own event and the subsequent publication of the techniques used in the attack. This delay is part of the coordinated vulnerability disclosure (CVD) process, which aims to manage zero-day vulnerabilities responsibly.  

In the 1990s, only a small number of hackers actively searched for vulnerabilities, and many vendors were unprepared to handle them. Concerns arose from both sides: “Are hackers submitting vulnerabilities in exchange for benefits?” and “Will these vulnerabilities actually be fixed, or will the effort be wasted?” The compromise became clear: Hackers would first submit vulnerabilities to vendors, who would then release a patch and publicly acknowledge the researchers for their discovery.  

According to TrendAI ZDI’s disclosure policy, a submitted vulnerability is disclosed when a patch becomes available — or after a certain period if the vendor remains unresponsive. This approach either addresses the vulnerability or informs the public about an unresolved issue, reducing the likelihood of exploitation. This explains the time gap between initial discovery and full public disclosure.