Mazda Connect Attack Surface

Every publicly documented attack against this platform requires local or physical access. The entry point is a person standing at the head unit, plugging in a crafted USB device — a mass-storage stick carrying a malformed update package, or a device that lies about being an Apple/iPod-class peripheral. Nothing in the public record is a stock remote attack over WiFi or cellular. That shapes the entire threat model: the adversary already has the doors unlocked and a USB port in front of them. For the legal framing around running this kind of analysis, see legal and research notes.

USB

USB is the primary documented entry point, and it is documented because it is the one interface that parses attacker-supplied files with elevated privilege.

Update-package parsing. Public research has documented a parsing vulnerability in the update/reflash path. The CMU performs multiple operations on an update file before it validates integrity: reading metadata, unpacking, staging. A crafted update file can reach that parsing code during those pre-verification steps, which is the worst possible ordering: untrusted input touched first, signature checked last. This is the same parse-before-verify pattern that has bitten a long list of embedded update systems.

Apple device handling. Researchers documented an input-handling flaw in the device-management subsystem’s processing of USB device identifiers. A USB device that presents itself as an iPod/Apple-class peripheral can supply identifier strings that aren’t properly sanitized before use. The trigger is the device descriptor itself, so no user interaction beyond plugging in is required.

The common thread: both bugs live in code that runs early, runs with privilege, and trusts the bytes coming off the bus.

Network interfaces

Bluetooth. The CMU exposes a Bluetooth interface for audio streaming and phone connectivity, and it accepts pairing requests while active. This is a live wireless interface, but its attack surface has not been analyzed within this project’s scope — treat the absence of findings as “not examined,” not “not exploitable.”

WiFi (CarPlay). On natively wireless-capable CMUs, the WiFi interface serves wireless CarPlay. On external-dongle or wireless replacement-hub setups, the adapter or hub supplies its own WiFi link instead, and the CMU’s own radio may be idle. Stock firewall rules block most inbound services on the CMU WiFi interface, with carve-outs for the CarPlay-related protocols that have to listen. The exposed surface is therefore narrow and protocol-specific rather than a general open network.

Privilege model

The userspace hardening is dated by current Linux standards:

• Core services run with limited privilege separation — a compromise of one service is not strongly contained from the rest.
• No SELinux or AppArmor policy is present in the analyzed rootfs. There is no mandatory access control layer behind the discretionary permissions.
• General userspace mitigations are weak relative to a current mainline Linux system.

These observations come from local firmware analysis and community research, not from a vendor disclosure. For how the rootfs is laid out and what runs at startup, see internals/filesystem and internals/services.

CAN bus and safety isolation

This is the part that matters most and is most often misunderstood. The CMU is an infotainment computer. It does not sit on the vehicle’s CAN bus directly. It talks to the rest of the car through the VIM (Vehicle Interface Module) over a proprietary IPC link, and the VIM is the only thing on the real CAN/LIN buses.

The VIM MCU, a Renesas R5F35-class part, acts as the gateway. From the CMU application processor’s side, vehicle telemetry arrives as a read-only stream: speed, RPM, and similar signals come in, but no write path from the CMU to the vehicle CAN bus has been identified in firmware analysis.

What the CMU cannot reach, even fully compromised:

System	Module	Reachable from CMU?
Braking (ABS/ESC)	—	No
Steering (EPS)	—	No
Airbag deployment (SRS)	—	No
Throttle / engine control	PCM	No
Transmission control	TCM	No

The practical consequence: a root shell and arbitrary code execution on the CMU buys an attacker the screen, the speakers, the microphone, and whatever data crosses the IPC link — not the brakes, the steering, or the throttle. The gateway architecture, not the infotainment software’s own hardening, is what enforces that boundary. Anything modifying the CMU (including aftermarket software) lives entirely on the infotainment side of that line.

Further reading

• internals/boot-chain — what runs before userspace, and where signatures are checked
• forscan/overview — the separate, authenticated path for reading and writing vehicle module configuration
• resources/further-reading — external research and community write-ups