From Pwn2Own Automotive 2026: Seven Kenwood DNR1007XR Vulnerabilities Now Patched

Key points of this blog 

• Kenwood’s July 21, 2026, firmware update addresses seven DNR1007XR vulnerabilities discovered at Pwn2Own Automotive 2026. 
• Four vulnerabilities provided physically present attackers with a direct path to root, while three enabled privilege escalation from an existing low-privileged foothold. 
• The findings reinforce the need for least privilege, secure update processes, strict permission controls, and verified firmware deployment across in-vehicle infotainment (IVI) systems. 

What Kenwood patched in the DNR1007XR 

On July 21, 2026, Kenwood released a firmware update for the DNR1007XR addressing seven security vulnerabilities discovered at Pwn2Own Automotive 2026, the annual automotive-focused hacking competition co-hosted by VicOne and TrendAI Zero Day Initiative (ZDI).  

Eight days later, ZDI — VicOne's partner in vulnerability discovery and disclosure — published advisories for CVE-2026-18267 through CVE-2026-18273. 

Table 1. At a glance: Vulnerabilities addressed by the Kenwood July 21, 2026, firmware update. 

How the DNR1007XR vulnerabilities created paths to root 

All seven vulnerabilities converged on the same outcome: arbitrary code execution as root on the Linux-based DNR1007XR. Their exploitation paths fall into two broad groups. Four provided physically present attackers with a direct path to root without authentication, while three turned an existing low-privileged foothold into a multistep path to root. 

Single-vulnerability paths to root 

• CVE-2026-18269 (Out-of-bounds write in tchdr_bytestream_read). On Day 1 of Pwn2Own Automotive 2026, Yannik Marchand exploited a malformed bytestream that reached an HD Radio-related parser that did not adequately validate the supplied data, resulting in a write beyond the end of an allocated buffer and code execution as root. 
• CVE-2026-18271 (Heap-based buffer overflow in vCardParser). Interrupt Labs demonstrated a unique heap overflow, most plausibly reached through Bluetooth Phonebook Access Profile (PBAP) contact synchronization.  
• CVE-2026-18272 (Command injection in startUpdateProcess). Demonstrated by Sina Kheirkhah of Summoning Team during Day 2 of the contest, the vulnerability involves an attacker-controlled string reaching a system call during the update process. USB or SD media appears to be the likely delivery path. Because the contest rules prohibited loading an entire unsigned firmware image, the finding appears to concern the updater’s handling of attacker-controlled input rather than the acceptance of an unsigned firmware package. 
• CVE-2026-18267 (Link following in the firmware update process). Juurin Oy demonstrated how a symbolic link could cause the update service to move a file to an arbitrary location, ultimately enabling code execution as root. 

Foothold-then-escalate paths 

• CVE-2026-18268 (Command injection in JKGenService). JKGenService did not properly validate a user-supplied string before using it in a system call. A low-privileged process that could supply this string could escalate its privileges and execute code as root. Kazuki Furukawa of GMO Cybersecurity by Ierae chained an n-day hard-coded credential with incorrect permissions on a critical resource and command injection. 
• CVE-2026-18270 (Incorrect permissions on a resource used by udhcpd). With a CVSS score of 7.8, this was the highest-rated vulnerability in the set. Qrious Secure demonstrated a chain involving an n-day vulnerability, incorrect permission assignment, and a race condition. 
• CVE-2026-18273 (Incorrect permissions on the USB filesystem mount point). TienPP from FPT NightWolf Team chained an n-day hard-coded credential with incorrect default permissions and symlink following. Later advisories indicate that CVE-2026-18273 represented the permission weakness, and CVE-2026-18267 represented the symlink-following component of that chain. 

What should DNR1007XR owners and IVI manufacturers do next? 

For DNR1007XR owners and integrators, the immediate priority is to install the July 21, 2026, firmware package, S_V2_0_0003_1000.zip, following Kenwood’s official update guide. Until the update is installed and verified, limit exposure to untrusted USB or SD media and untrusted Bluetooth devices. 

For other existing and future in-vehicle infotainment (IVI) designs, the findings point to five priorities: 

• Minimize privileges at exposed interfaces. Parsers and services handling input from USB devices, Bluetooth connections, radio streams, and network interfaces should operate with only the permissions they require. 
• Treat update processes as a high-trust boundary. Firmware update services should validate all strings, file paths, and externally supplied data before performing privileged operations. 
• Enforce strict permissions between services. Resources used by privileged daemons, mount helpers, and local services should not be writable or controllable by low-privileged processes. 
• Prevent an initial foothold from becoming a system compromise. Removing default or hard-coded credentials, limiting exposed services, and separating privileges can help contain an initial compromise before it reaches root. 
• Carry remediation through to deployed products. Manufacturers and integrators should maintain traceability between reported vulnerabilities, implemented fixes, affected product versions, validation results, and update deployment. 

From exposed interfaces to system-level risk 

At the center of the modern smart cockpit, IVI systems provide entertainment, navigation, smartphone connectivity, and other driver conveniences — making them among the most directly accessible components in a vehicle. Their external interfaces and connections to internal services expand the attack surface and increase the risk that a compromise could extend beyond a single user-facing function. 

The DNR1007XR findings show why strong trust boundaries and privilege separation are essential: a compromise should be contained before it can reach root. 

Architecture-level controls should be paired with ongoing risk visibility. VicOne’s Smart Cockpit Protection identifies application- and connectivity-layer risks, while xNexus extends visibility from system to application level. In a connected cockpit, one exposed component should never become a path to control over the entire IVI platform. 

Key lesson: IVI systems require privilege separation at every external interface, verified firmware update processes, and ongoing risk visibility. The DNR1007XR findings demonstrate that without these controls, physically present attackers can reach root through a single vulnerability, and low-privileged footholds can escalate into full system compromise. 

 
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 Trend 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.