Pop the hood on a new car and you won't find much you can fix with a wrench. What you'll find is software, and a lot of it. The screen in the dash probably runs Android or a flavor of Linux. The system watching the road for you might run QNX or VxWorks, the same kind of code that flies aircraft and runs factory floors.

Carmakers spent the last decade making this switch, and it bought them app stores, wireless updates, and quicker release cycles. It also handed them something less welcome: every old, publicly documented bug those platforms have collected over the years.

Researchers at Télécom SudParis decided to count that baggage. They built a scanner called VERA, aimed it at the operating systems inside current cars, and tallied up the known flaws. The pile is big. It's also messier than the raw numbers make it look, which turns out to be the more interesting part of the story.

What's Running in Your Car?

First, the researchers worked out who runs what, which is harder than it sounds because carmakers treat this stuff as a trade secret. A 2023 BMW dashboard runs a Qualcomm chip loaded with Automotive Grade Linux and Android. GM and Cadillac are moving to Red Hat's in-vehicle OS for their 2026 models. Tesla has quietly run Linux for years. Line it all up and the fleet starts to look like a rolling collection of general-purpose computers, plugged into cellular, Wi-Fi, Bluetooth, and the car's own internal wiring.

Then they scanned it. The counts landed all over the map. Automotive Grade Linux topped the chart with 1,203 documented flaws in the version they tested. Android wasn't far off. A leaner, safety-focused stack called Eclipse S-CORE came in with a grand total of eight. Part of that gap is just how much extra software each platform ships. Part of it is attention: popular open platforms get poked at by more researchers, so more of their flaws end up on the books. Getting looked at is its own kind of exposure.

Breaking Down the Numbers

The disparity in vulnerability counts reflects more than just code quality. Platforms like Android Automotive ship with thousands of libraries and services. Each one is a potential entry point for attackers. In contrast, S-CORE is designed with minimalism and safety in mind, stripping away unnecessary components. Yet even a small number like eight can be devastating if one of those bugs lies in a critical function such as braking or steering.

The researchers also noted that many vulnerabilities are inherited from upstream open-source projects. When a carmaker integrates a Linux kernel or an Android build, they also inherit every CVE documented for that version. Patching becomes a supply chain problem. Automakers must track fixes from chip vendors, OS maintainers, and third-party app developers, all while ensuring updates don't break safety certifications.

Certified Doesn't Mean Bulletproof

You might expect the safety-certified systems to come out clean. They don't. QNX Neutrino carries a respected security certification, and the tested build still logged 56 known vulnerabilities. VxWorks 7 sits at an even higher certification tier and landed in the low dozens.

Certification does real work here. It shrinks the attack surface and forces discipline into how the code gets built. What it can't do is stop the mountain of surrounding software from sprouting new bugs that somebody has to patch.

For example, QNX is used in many advanced driver-assistance systems (ADAS). A flaw in its TCP/IP stack could allow remote exploitation if the car's cellular modem is compromised. Similarly, VxWorks often controls telematics units and gateway modules. The researchers found that while the real-time kernel itself is robust, the middleware and application layers pulled into the build introduce risks. Certification bodies like ISO 26262 focus on functional safety, not comprehensive security. A system can be safe from accidental failures yet still vulnerable to intentional attacks.

A Big Number Is a To-Do List, Not a Verdict

This is where the study gets honest with itself, and where a lot of scary headlines fall apart. A logged vulnerability is a maybe. It's a weakness that could matter under the right conditions, if the vulnerable code is even switched on, if the attacker can reach it, if the setup happens to line up. A thousand flaws means a thousand things a defender has to keep an eye on. It doesn't mean a thousand ways into the car.

To show the difference, the team built two working attacks. One went after a bug in SQLite, a database engine buried inside all sorts of apps, running on Android Automotive. The other targeted a service discovery protocol called SOME/IP, and this one tells the whole story in miniature.

They ran the same attack against three platforms. It worked on Red Hat's AutoSD and on Tesla's software, letting them knock a service offline. It flopped on Android Automotive, which the researchers figure was down to the platform shuffling its port numbers around. One bug, three systems, two very different afternoons. Same severity score on paper, and the outcome came down to what defenses were actually turned on.

All of this ran inside Docker containers on a lab bench, picked because they're easy to reproduce. That setup nails the filesystem, the installed packages, the config. It skips the vendor's custom kernel, the firmware quirks, the hardware protections. The numbers describe what's sitting in the software image. They stop short of what happens in a car parked in your driveway.

Real-World Exploitation Factors

Automotive architectures add layers of isolation. For example, the infotainment system often runs on a separate domain from safety-critical controllers. Even if an attacker exploits a bug in Android Automotive, reaching the braking system requires crossing a gateway secured by hardware-enforced firewalls. Many modern cars use a service-oriented architecture (SOA) where components communicate over SOME/IP or DDS. These protocols themselves have known vulnerabilities, but they are often firewalled or rate-limited. The researchers emphasized that vulnerability scanners cannot capture these mitigations. A critical-severity bug in a service behind a firewall might be effectively harmless.

Another factor is update frequency. Tesla pushes over-the-air updates frequently, which means a known vulnerability might be patched within weeks. By contrast, older models from other manufacturers may never receive a fix if the bug resides in a component that is no longer supported. The lifecycle of automotive software can span a decade or more. A car sold in 2025 may still be on the road in 2035, running the same vulnerable kernel it shipped with.

The Scanners Have a Car Problem

There's a working-stiff angle here too. The everyday scanners security folks reach for assume a tidy system with a clean inventory of parts. Cars don't play along. Trivy, one of the popular ones, coughed up more than a thousand false alarms on a single robotics image and barely anything useful on others. VERA sits on top of the existing tools and filters for the automotive reality, tossing out flaws in command-line utilities and developer tools that a locked-down car would never expose in the first place. What you get back is shorter and sharper, a list somebody can actually work through instead of drown in.

The challenge is compounded by the sheer number of software components. A typical luxury vehicle may integrate software from over 100 suppliers. Each supplier might use different versioning schemes, patch management practices, and security disclosure timelines. Coordinating a fix for a vulnerability that spans a Linux kernel package, a third-party middleware library, and a proprietary application can take months. During that window, every vehicle on the road is exposed.

Automakers are beginning to adopt software bill of materials (SBOM) practices, but the industry is far from maturity. The VERA scanner is a step toward automating the SBOM analysis for automotive contexts. It can identify which components are present and cross-reference them against the National Vulnerability Database (NVD). However, the researchers noted that NVD data can be incomplete or delayed. Zero-day vulnerabilities, by definition, are not in the database. An attacker targeting a specific car model could weaponize a bug before any scanner detects it.

Implications for Security Teams and Consumers

For automotive OEM security teams, the study provides a clear methodology to prioritize patching. Rather than treating every CVE with equal urgency, they can focus on vulnerabilities that are reachable given the car's network architecture and enabled services. This is exactly what VERA does by filtering out bugs that are only exploitable from a local shell that doesn't exist in production.

For consumers, the message is nuanced. The presence of thousands of known vulnerabilities does not mean your car is a hackable death trap. But it does mean that automakers must invest in secure development practices, continuous monitoring, and rapid over-the-air updates. Buyers should consider how often a manufacturer issues security patches and whether those updates cover all domains of the vehicle.

The automotive industry is at a crossroads. The transition to software-defined vehicles brings immense benefits in feature velocity and personalization. But it also imports the entire security baggage of the general-purpose computing world. The key is not to eliminate all vulnerabilities—that's impossible—but to manage them intelligently. VERA offers a template: measure the risk with context, filter the noise, and act on what matters. The code in your car now shares a family tree, and a rap sheet, with the rest of the computing world. The length of that rap sheet tells you how much there is to watch. The real job is sorting out which of those old bugs your particular car will ever let anyone near.

Source: Help Net Security News