CAN bus attacks explained: fuzzing, injection and spoofing

A protocol that trusts every talker

The Controller Area Network (CAN) is the workhorse bus of the modern vehicle, carrying the messages that let ECUs coordinate — engine, braking, body, instrument cluster. It was designed in the 1980s for reliability and real-time broadcast on a closed, trusted network, and it does that job superbly. What it was never designed for is security. CAN has no built-in authentication and no encryption, and it is a broadcast medium: every node hears every message. Any node that can transmit can therefore impersonate any other, and a receiver has no way to tell a genuine frame from a forged one.

That single property — no authentication on a shared broadcast bus — is the root of every attack described below. The techniques differ in intent, but they all exploit the same fact: on CAN, a well-formed frame is a trusted frame.

The three techniques

Once an attacker has access to the bus — through a compromised connected ECU, the OBD-II port, or a wireless-to-CAN path — three families of attack become available.

Technique	What the attacker does	Typical goal
Injection	Places crafted, well-formed frames onto the bus	Trigger a function or state the attacker chooses
Spoofing	Transmits frames impersonating a legitimate ECU's identifiers	Make receivers act on forged data as if genuine
Fuzzing	Sends malformed, random or boundary-case frames	Provoke faults, crashes or undefined behaviour to map weaknesses

Injection is the placement of legitimate-looking frames the attacker did not have the authority to send. Because receivers act on message identity, not sender identity, an injected frame that carries the right identifier and payload is obeyed. Spoofing is injection aimed at impersonation — flooding or out-pacing a real ECU so that the attacker's version of a message wins. Fuzzing is exploratory: by sending malformed or random frames and watching what breaks, an attacker maps which messages cause which effects, which is often the reconnaissance step before a targeted injection.

A worked demonstration of how convincing this can be is set out in the instrument cluster attack: crafted CAN frames change what the dashboard displays — speed, state of charge — with no fault raised, because the frames are perfectly well-formed. Diagnostics report nothing precisely because nothing is malformed. That is the CAN problem in miniature.

Getting onto the bus

An attack needs bus access, and the routes have widened as vehicles have connected.

• Physical / diagnostic. The OBD-II port offers direct access, and end-of-line and workshop tooling reaches the bus by design. Diagnostic access is also the entry point for the UDS attacks discussed in UDS diagnostics security: the 0x27 SecurityAccess problem, where weak seed/key schemes on the diagnostic layer compound the CAN exposure beneath it.
• A compromised ECU. A connectivity-facing ECU — telematics, infotainment — that is compromised remotely becomes a foothold on the internal network, from which CAN frames can be sent.
• Wireless-to-CAN chains. A vulnerability in a wireless interface that bridges to the internal buses turns a remote attack into bus access without the attacker ever touching the car.

The lesson is that "physical access required" is an increasingly weak assumption. The value of a domain gateway is precisely that it does not assume the internal network is safe once one node is reachable.

What mitigates it

Because the exposure is inherent to the protocol, defence is a matter of adding the trust CAN lacks and containing the access an attacker can gain. UN R155 Annex 5 lists the in-vehicle communication channel as one of its threat categories, so these mitigations are not optional polish — they are how a TARA closes an identified threat.

• Segmentation and domain gateways. Splitting the vehicle network into domains behind gateways stops a compromised low-value ECU from reaching a safety-critical bus. The gateway enforces which messages may cross domains, containing an attacker who gets onto one segment.
• Message authentication. Schemes that add a message authentication code — often built on the larger payloads of CAN-FD — let a receiver verify that a frame came from the ECU it claims to. This directly attacks the spoofing problem by making frame identity verifiable.
• Intrusion detection on the bus. Monitoring for anomalous timing, unexpected identifiers or impossible message sequences flags injection and fuzzing that authentication alone would miss. On a connected vehicle this detection feeds the fleet-monitoring pipeline — the same signals a VSOC learns to recognise, as covered in building an automotive VSOC.
• Rate limiting and plausibility checks. ECUs that cross-check received values against physically plausible ranges and expected rates resist forged data that a naive receiver would obey.

None of these fixes CAN itself. They wrap the untrusted broadcast bus in the authentication, segmentation and monitoring it never had — which is the only honest way to secure a protocol whose exposure is by design.

Why offensive knowledge is defensive

The reason to understand injection, spoofing and fuzzing in detail is that you cannot mitigate what you cannot reproduce. Representative ECU benches let a team run these attacks safely and turn the results into type-approval evidence and detection rules — the subject of penetration testing a vehicle. A mitigation claimed but never tested against a real injection is a description, not a control; the assessor, and the attacker, both know the difference.

The AutoSifu view

CAN attacks are where an Annex 5 threat category stops being a checklist entry and becomes a demonstrable risk on a bench. AutoSifu works one route — compliance, solutioning, and CoC/VTA support — with CIRT in the room, so offensive findings against CAN feed directly into the TARA, the mitigations, and the evidence an assessor opens. Reproducing the attack is what turns a claimed mitigation into one the approval body can trust.