Automotive Software Vulnerabilities: Hidden Risks in Your Car Dashboard

Post Views: 15

The automotive software vulnerabilities hiding in your dashboard Opening the hood of a modern vehicle reveals little that can be repaired with traditional tools. What lies beneath the surface is an intricate web of software, with the dashboard display likely operating on Android or a Linux variant. Systems responsible for critical functions such as sensor data processing may run QNX or VxWorks, operating systems also used in aviation and industrial automation. Automakers have transitioned to these platforms over the past decade, enabling features like app stores, over-the-air updates, and faster development cycles. However, this shift has also introduced risks, as these systems inherit a legacy of documented security flaws. Researchers at Télécom SudParis conducted an analysis of the software ecosystems within contemporary vehicles, using a custom tool called VERA to scan operating systems embedded in automotive hardware. Their findings highlight a significant and complex vulnerability landscape. The study focused on identifying known flaws in the software stacks powering modern vehicles, revealing disparities in security postures across different platforms. The investigation began by mapping the operating systems used by major automakers. For example, a 2023 BMW model employs a Qualcomm chip running Automotive Grade Linux and Android, while GM and Cadillac are transitioning to Red Hat’s in-vehicle operating system for 2026 models. Tesla has long utilized Linux-based systems. These platforms, when combined with connectivity protocols like cellular, Wi-Fi, and Bluetooth, transform vehicles into networked devices with extensive software dependencies. The vulnerability counts varied widely. Automotive Grade Linux, the platform tested, contained 1,203 documented flaws. Android systems showed a lower but still substantial number of issues. A specialized safety-focused stack, Eclipse S-CORE, reported only eight vulnerabilities. This discrepancy reflects both the volume of software included in each platform and the level of scrutiny applied by the security research community. Popular open-source systems attract more attention from researchers, leading to more vulnerabilities being cataloged. Certification does not guarantee immunity. QNX Neutrino, a system with a strong security reputation, still exhibited 56 known vulnerabilities in the tested version. VxWorks 7, which holds higher certification standards, had a lower but still significant number of flaws. While certifications reduce attack surfaces and enforce development discipline, they cannot eliminate vulnerabilities in the broader software ecosystem. The study emphasizes that vulnerability counts alone do not indicate exploitability. A reported flaw represents a potential risk, but its relevance depends on factors such as whether the affected code is active, whether it is accessible to attackers, and whether environmental conditions align. To illustrate this, researchers demonstrated two attacks. One targeted a SQLite database vulnerability within Android Automotive, while another exploited the SOME/IP service discovery protocol. The latter attack succeeded on Red Hat’s AutoSD and Tesla’s software, but failed on Android Automotive due to randomized port configurations. This highlights how defensive measures within specific implementations can mitigate risks despite identical vulnerability scores. The experiments were conducted in controlled lab environments using Docker containers to replicate software images. This approach captured filesystem configurations, installed packages, and settings but excluded vendor-specific kernels, firmware, and hardware protections. As a result, the findings reflect the software image’s state rather than real-world deployment scenarios. Existing vulnerability scanners face challenges in automotive contexts. Tools like Trivy often generate false positives when analyzing complex systems, such as robotics software, and provide limited utility for automotive platforms. VERA addresses this by filtering out irrelevant flaws, such as those in command-line utilities or developer tools, which would not be exposed in a production vehicle. This results in a more actionable list of vulnerabilities for security teams. The research underscores that automotive software shares a lineage with broader computing ecosystems, carrying both functional benefits and security liabilities. While the volume of known vulnerabilities indicates areas requiring monitoring, the true challenge lies in determining which flaws are actually reachable within a specific vehicle’s architecture. The findings call for a nuanced approach to automotive security, balancing awareness of inherited risks with the realities of implementation-specific defenses.