--- title: "Software Updates Over CAN as a Privileged Attack Vector" canonical_url: https://can-security.net/threats/software-updates/ description: "The firmware update channel is the most privileged path into a CAN node. CANopen and J1939 standardize firmware download for interoperability, not security." last_updated: 2026-08-27 --- # Software Updates Over CAN as an Attack Vector The firmware update channel inherits the manufacturer's trust: whatever the bootloader accepts, the device runs. Both CANopen and [J1939](https://can-security.net/resources/terms-and-definitions/#term-j1939) originally standardized firmware download for interoperability, not for security. Many real products shipped plain Intel-HEX images alongside a generic download tool, which leaves the update channel wide open to anyone with bus access (or to anyone who can phish a service engineer). The result is a class of attack that is structurally distinct from frame injection: the attacker no longer impersonates a node for one bus session. They replace the code that node runs. ## Why Software Updates Are a Threat Surface Frame-level attacks succeed for the duration of a bus session. Update-channel attacks succeed for the lifetime of the device. Once an attacker can flash arbitrary code into a node, every system parameter and even every cryptographic key on that node is in their hands, every defensive shell on that node can be silenced, and every later "secure" frame the node emits is signed by them. From the rest of the bus's perspective, the compromised node is still legitimate. Update tampering also persists across power cycles, factory resets that the malicious firmware mishandles, and most diagnostic procedures, until someone reflashes the device through a trusted channel, which presupposes the trusted channel still exists. ## Standardized Bootloading Without Standardized Security CANopen ([CiA](https://can-security.net/resources/terms-and-definitions/#term-cia) 710) defines firmware-download protocols at the application layer. An Object for security is reserved, but its implementation is not defined. The intent is interoperability: a CANopen download tool from one vendor can update a CANopen device from another. That is the right design goal for a fieldbus standard. It is also the wrong design goal to answer security with: the published profiles do not by themselves require authentication, encryption, or version-rollback protection. Authentication and confidentiality are *layered on top* of the standard exchange by the manufacturer, or they are not present at all. ## The Plain-HEX Shipping Pattern The most common pattern in industrial CAN for a long time was this: the manufacturer publishes a firmware update as a plain Intel-HEX file, distributed over a website or email, alongside a generic CAN download tool. The device's bootloader speaks the standard download protocol and writes whatever image it receives. There is no signature on the HEX file, no encryption in flight, no version-monotonicity check at the bootloader, and no audit trail of who attempted to flash what. Anyone with bus access can flash arbitrary code: a service engineer, a supply-chain insider, a post-deployment add-on device, or an attacker who phished the support team's distribution channel. ## Concrete Attack Patterns - **Arbitrary code execution.** Replace the firmware with an attacker-controlled image. The device subsequently runs attacker code with full hardware authority. Extracts keys; exfiltrates data; pivots into the rest of the bus. - **Rollback to a vulnerable image.** Flash an older signed-but-vulnerable firmware to bypass a fix the manufacturer already shipped. Particularly relevant when only signing is done and version monotonicity is not enforced. - **Replay of a captured legitimate update.** Capture a legitimate update exchange on the bus, then replay it later out of context, for example after the manufacturer has shipped a patch. If freshness is not bound into the update transaction the device cannot tell. - **Partial-image corruption.** Interrupt or fuzz the download to brick the unit or leave it in a half-flashed state with corrupt cryptographic key storage. A denial-of-service variant where the unit is field-unreachable until physical recovery. - **Update-channel as exfiltration.** The update protocol's read-back primitives can be turned into an arbitrary memory read against an unhardened bootloader, lifting keys or device-secret data without ever flashing. ## Where Remote Entry Becomes an Update-Distribution Surface Many [Remote Attacks](https://can-security.net/threats/remote-attack/) do not require physical bus access. The remote-service gateways, diagnostic ports, and wireless maintenance links are usually how legitimate updates are pushed in the first place. That makes the same paths an attractive route for malicious updates: a compromised cloud back-end, a stolen service-tool credential, or a man-in-the-middle on a maintenance channel can drive the update protocol exactly as the manufacturer would. The threat moves from "attacker has soldered onto the wires" to "attacker has the same access the service team has". ## Mitigations ### Secure bootloader with PSK Authenticated firmware update under a dedicated pre-shared key, [AES-128-GCM](https://can-security.net/resources/terms-and-definitions/#term-aes-128-gcm)-protected images, and possibly challenge/response gating into the update mode. See [Secure Bootloader](https://can-security.net/solutions/secure-bootloader/). ### Version monotonicity and signed releases Bind the version into the signed image and refuse to install older releases. Sign the release artifact in a controlled pipeline so the delivery channel cannot be substituted by an attacker who happens to control the distribution endpoint. ### Audit logging of every update attempt Anomaly Event Monitoring captures both successful and rejected update attempts to the security event log, with timestamps and challenger identity. This makes opportunistic attempts visible even when they fail, and supports [CRA](https://can-security.net/resources/terms-and-definitions/#term-cra) vulnerability handling. See [Anomaly Event Monitoring](https://can-security.net/solutions/anomaly-event-monitoring/). ### Hardened update-distribution path Authenticated, replay-protected channel from the manufacturer's release pipeline through to the device: [TLS-PSK](https://can-security.net/resources/terms-and-definitions/#term-tls-psk) or equivalent on remote-service gateways, signed-tool authentication on local diagnostic ports. Closes the remote-entry side of the threat surface from [Remote Attacks](https://can-security.net/threats/remote-attack/). ## CVSS Scoring for Update-Channel Attacks The [CVSS](https://can-security.net/resources/terms-and-definitions/#term-cvss) baseline depends on whether the update path is locally bus-attached or remotely reachable. For a directly bus-attached update channel against an unprotected bootloader, the attack vector is `AV:P` as elsewhere on classical CAN, but the integrity and availability impacts are higher than the per-frame baseline because firmware tampering is irreversible from the bus side: the device runs attacker code afterwards. For an update path exposed via a remote-service gateway or maintenance back-end, the attack vector is `AV:N` and the confidentiality impact follows whatever the firmware itself can access. See [CVSS for CAN](https://can-security.net/risk-assessment/cvss-for-can/) for how mitigations adjust the score. ## Frequently Asked Questions ### Why is the firmware update channel a threat surface separate from frame injection? Frame injection lets an attacker imitate one node for the duration of the bus session. Compromising the firmware update channel lets the attacker replace the code that runs on the target permanently, including any cryptographic keys it holds. The blast radius and persistence are categorically different, even though the underlying bus access can be the same. The mitigation is also different: see [Secure Bootloader](https://can-security.net/solutions/secure-bootloader/). ### Is the CANopen firmware-download protocol inherently insecure? The exisitng CiA 710 standardized download protocol solves interoperability, not security. Authentication, encryption, and rollback protection are layered on top by the manufacturer. A device that implements the download exchange but ships unsigned plain-HEX firmware satisfies the protocol while leaving the security properties at zero. ### Does shipping plain Intel-HEX firmware fail the EU CRA? CRA Article 13(2)(c) requires that vulnerabilities can be addressed through security updates and that those updates can be applied safely. A plain-HEX update channel that any party with bus access can drive cannot be applied safely in the regulatory sense, and the same channel becomes the manufacturer's vulnerability-introduction surface. Most CRA conformity assessments will flag this.