The increasing reliance on software in modern vehicles has introduced a significant number of known vulnerabilities into automotive systems, according to research conducted by Télécom SudParis. As car manufacturers integrate general-purpose operating systems like Android and Linux into dashboards and control units, they also inherit the accumulated security flaws documented for these platforms.
Researchers developed a scanner called VERA to identify known vulnerabilities within the operating systems used in current vehicles. Their findings indicate a wide range in the number of documented flaws across different platforms. Automotive Grade Linux, for instance, showed 1,203 known vulnerabilities in the tested version, with Android not far behind. In contrast, the safety-focused Eclipse S-CORE platform registered only eight. This disparity is attributed to factors like the volume of software shipped with each platform and the level of scrutiny popular open-source projects receive from researchers.
Even systems with security certifications were not immune. QNX Neutrino, despite its respected certification, was found to have 56 known vulnerabilities in its tested build, while VxWorks 7, with an even higher certification tier, also contained dozens of flaws. While certification helps reduce the attack surface and enforces development discipline, it cannot prevent new bugs from emerging in the surrounding software components.
The researchers emphasized that a high number of documented vulnerabilities does not equate to an equivalent number of exploitable entry points into a vehicle. A logged vulnerability represents a potential weakness that may only be relevant under specific conditions, depending on whether the vulnerable code is active, accessible to an attacker, and if the system configuration aligns.
To illustrate this point, the team developed two proof-of-concept attacks. One targeted a bug in SQLite, a database engine often embedded in Android Automotive applications. The other focused on SOME/IP, a service discovery protocol. The SOME/IP attack was successful in knocking a service offline on Red Hat's AutoSD and Tesla's software, but it failed on Android Automotive, which the researchers attributed to the platform dynamically reconfiguring its port numbers. This demonstrated that the practical impact of a vulnerability can vary significantly across different implementations, even with the same reported severity score.
It is important to note that these tests were conducted in Docker containers in a lab environment, which accurately replicated the filesystem, installed packages, and configurations. However, this setup did not account for vendor-specific custom kernels, firmware quirks, or hardware-level protections that would be present in an actual vehicle. The numbers primarily reflect the vulnerabilities present in the software image itself.
The research also highlighted challenges with existing security scanning tools, which often produce numerous false positives when applied to automotive systems. VERA addresses this by filtering out flaws in command-line utilities and developer tools that would not be exposed in a locked-down car environment, providing a more relevant and actionable list of vulnerabilities for defenders. The study concludes that while automotive software now shares a common lineage and a history of vulnerabilities with the broader computing world, the critical task lies in identifying which of these known flaws pose a genuine risk to a specific vehicle.
