Autonomous Vehicle Hacking: Exploring Potential Attack Vectors

This is part 2 of a four-part series on autonomous vehicle cybersecurity. Part 1 explains the autonomous vehicle software stack. This part and part 3 review the various attack vectors and security gaps. Finally, part 4 explains why you need expertise for the development and ongoing risk mitigation of autonomous vehicle firmware.


As discussed in part 1, firmware sits at the base of the autonomous vehicle (AV) tech stack. While firmware is not the latest technology advancement, it is the fundamental component that makes everything else work. Unfortunately, this high level of control is precisely what makes it so appealing to malicious actors. Autonomous vehicle hacking at the firmware level gives attackers access to different levels of compute within a single vehicle, allowing them to wreak havoc across other systems.

Increased Potential for Autonomous Vehicle Hacking

General Increase in Vulnerabilities

Firmware vulnerabilities are on the rise. This graph shows the total (through 2020) number of known medium-, critical- and high-risk firmware vulnerabilities tracked by Phoenix, based on the Common Vulnerability Scoring System (CVSS). As the graph shows, the number of vulnerabilities has been climbing steadily, more than quadrupling in less than six years.

Figure 1: Phoenix vulnerability disclosure graph

Rapid Increase in Connectivity for AV

When considering firmware vulnerabilities and the potential for autonomous vehicle hacking, it’s critical to consider how rapidly technology has infiltrated modern vehicles. Previously, cars took people from point A to point B; now, they are essentially “servers on wheels.”

For example, today’s cars have up to 150 electronic control units (ECUs) and about 100 million lines of code. By 2023, that number is expected to increase to 300 million lines of code. The complexity of software code is the result of combining the legacy processes used to design electronic systems with the increasing functionality of modern vehicles.

More code means more ample opportunity for cyberattacks across autonomous vehicles and the back-end systems and components that power them.

3 Top Attack Vectors in Autonomous Vehicle Hacking

The increasing connectivity in AV leads to a larger attack surface, new attack vectors, and ultimately more opportunities for autonomous vehicle hacking. In addition, an attack vector that targets one area of compute can be used as an entry point to exploit other areas. Here are a few examples of attack vectors that can be used to infiltrate highly connected vehicles.

Vehicle to Anything (V2X)

Advanced autonomous vehicle systems require full connectivity. For these systems to work, modern vehicles include cellular, Wi-Fi, and Bluetooth connectivity. Today these features enable communication with necessary services and systems for emergency calls, infotainment, and fleet management services. But as autonomous vehicle technology advances, new communication paradigms that leverage 5G will emerge and become ubiquitous. Specifically, this will involve vehicle-to-vehicle (V2V) communication, vehicle-to-infrastructure (V2I) such as with smart traffic lights, and vehicle-to-device (V2D) communication. For V2D, imagine a scenario in which an iPhone in a pedestrian’s pocket transmits a signal that passing vehicles can detect, letting them know a pedestrian is nearby (perhaps behind a parked car) and alerting the car to slow down.

Personal Area Networks (PANs)

Some vehicle manufacturers have started implementing local Wi-Fi hotspots for passenger use. Wi-Fi is additional connectivity that is a soft target for many hackers. Wi-Fi is a particularly vulnerable connection mechanism. Poorly implemented cryptographic controls lead to weaknesses in authentication that can be easily infiltrated by malicious actors. Personal area networks also include the emergence of newer near-field communication (NFC) technology used for fleet management in new rental car models and car-sharing.

Controller Area Network (CAN)

Controller area networks (CANs) facilitate communication between ECUs and became standard in vehicles in the 1990s. Today, most cars still use one or two CANs to prioritize critical messages or fault tolerance. Communication across a CAN is clear-text with no message-level authentication. These messages are internal facing but can be easily accessible by pivoting from external systems with little to no network segregation.

82% of automotive cybersecurity incidents in 2019 involved remote attacks, which do not require physical access to the vehicle and can be carried out from anywhere in the world.

Increased Attack Surface, More Potential Security Gaps

As discussed, each additional attack vector increases the attack surface area, increasing the potential for autonomous vehicle hacking. Therefore, as the attack surface area increases, AV teams must be aware of all the potential security gaps their vehicles face. Every single gap is a potential vulnerability that could lead to a breach across an entire line of vehicles. Such failures are unsafe for consumers and terrible for the company’s reputation.

Ready to uncover a few of the potential security gaps your AV team should be prepared to protect?

Read Part 3

Need a partner to help you develop and maintain secure firmware specifically for autonomous vehicles?

Talk to an Expert