Modern cars are computers that happen to have wheels. That’s been true for a while, but the attack surface in 2026 is genuinely alarming, dozens of ECUs, telematics boxes, Bluetooth stacks, LTE modems, and a single shared bus topology that was designed in the 1980s when nobody thought a vehicle would ever be network-connected. I’ve been watching UK security researchers dig into this space for the last couple of years, and the findings are uncomfortable reading for manufacturers, regulators, and anyone who owns a relatively recent car sold on British roads.
What the CAN bus actually is and why it’s a problem
The Controller Area Network (CAN) protocol was developed by Bosch in 1983 and standardised as ISO 11898. It lets microcontrollers inside a vehicle talk to each other without a host computer in the middle. Your engine management unit, your ABS controller, your dashboard cluster, your steering column, they all broadcast short frames onto the same wire, and every node on the bus reads every frame. There’s no authentication. There’s no encryption. Any node can spoof any other node. The original assumption was physical isolation: if you’re inside the car and on the bus, you’re trusted.
That assumption collapsed the moment vehicles got OBD-II ports (mandatory on UK petrol cars from 2001 under EU regulations, now retained under UNECE type-approval rules carried over into UK law post-Brexit), Bluetooth dongles, Wi-Fi hotspots, and over-the-air update channels. The bus is still the same fundamentally insecure topology, but now there are bridges from the outside world straight onto it. That’s CAN bus hacking in its simplest framing: you find a path to the bus, and then you own every node on it.
OBD-II port exploitation: the hole under your dashboard
The OBD-II port is the easiest entry point. It’s physically accessible, it’s mandated by law, and it connects directly to the CAN bus. Mechanics use it. MOT testers use it. Insurance telematics boxes plug into it. So do a huge number of cheap Bluetooth and 4G dongles sold on the high street and via marketplaces like Amazon UK.
Security researcher Ken Munro at Pen Test Partners (a Buckinghamshire-based firm that has done some of the most serious vehicle security work in the UK) has demonstrated repeatedly that poorly secured OBD dongles can be compromised over Bluetooth from outside the vehicle. Once you have a shell on the dongle, you’re issuing raw CAN frames. At that point you can spoof sensor readings, suppress fault codes, or in more serious cases, influence safety-critical systems depending on the vehicle architecture. The research has been published openly, and the NCSC has referenced this class of attack in its guidance on connected vehicle security.
What makes this worse in 2026 is the secondhand market. Cars change hands, but the telematics box the previous owner used for cheaper insurance often stays plugged in. I’ve seen three separate threads on UK automotive forums where buyers found active insurance dongles still live and broadcasting on a car they’d just bought. That’s an attacker’s dream: a persistent, internet-connected bridge to the CAN bus, and the current owner doesn’t even know it’s there.
Over-the-air update interception and firmware integrity
OTA updates are where things get genuinely interesting. Every mainstream manufacturer now pushes firmware updates to ECUs wirelessly. Tesla has done it longest, but Ford, BMW, Volkswagen Group, and Stellantis brands are all doing it on models sold in the UK. The update mechanism typically involves a telematics control unit (TCU) with an LTE modem that pulls a signed firmware image from a manufacturer’s backend, verifies a signature, and then flashes the target ECU over the internal bus.
The signing is usually RSA or ECDSA, and when it’s implemented properly, intercepting the download gives you an encrypted blob you can’t do much with. The problem is implementation. Researchers at the University of Birmingham published work in 2023 demonstrating that several manufacturers’ TCUs would accept updates over unencrypted HTTP under specific fallback conditions, and that certificate pinning was either absent or bypassable with a compromised root CA. A man-in-the-middle on the vehicle’s Wi-Fi or a rogue 4G cell (a cheap software-defined radio setup can fake a cell tower well enough to catch an LTE data session) puts an attacker in a position to serve a malicious firmware image, provided they can also forge or strip the signature check.
UK UNECE Regulation 156, which covers software update processes and has been legally binding on new UK type-approvals since 2022, requires manufacturers to document their software update management systems and have them audited. It does not specify cryptographic standards in granular detail. That gap is where researchers are finding the interesting stuff.
Reverse engineering proprietary firmware with open-source tools
Getting firmware off an ECU is a prerequisite for most serious research. The common approaches in the UK security community right now involve JTAG and SWD debugging interfaces (often physically present on the PCB but with fuses blown or debug-lock bits set), flash chip extraction using a hot-air rework station and an SP flash programmer, and occasionally exploiting bootloader vulnerabilities to dump memory over an existing interface like the CAN bus itself via diagnostic protocols (UDS on ISO 14229).
Once you have a binary, the toolchain looks familiar to anyone who does embedded reverse engineering. Ghidra (the NSA-released disassembler, now widely used by UK researchers) handles most architectures you’ll find in automotive ECUs, Renesas RH850, Infineon TriCore, NXP S32. Binwalk identifies filesystem structures. Custom Python scripts parse proprietary calibration maps. The ECU remapping community has actually done a huge amount of groundwork here: people who tune engines for performance have been extracting and modifying ECU firmware for years, and their tooling overlaps significantly with what security researchers use. Sites like fastandfurious4.co.uk sit squarely in the performance car world where ECU remapping is part of the culture, and that culture has produced engineers who understand firmware internals better than most professional security teams do.
The open-source tool getting the most attention right now is OpenXC combined with python-can, which lets researchers log and replay CAN frames cheaply using a Raspberry Pi and a MCP2515 module (total hardware cost: under £20 from any UK electronics supplier). Couple that with CANalyze or SavvyCAN for traffic analysis, and you have a working lab for CAN bus research. The barrier to entry is genuinely low, which is both democratising for legitimate researchers and concerning for threat actors.
For context on how physical infrastructure security intersects with digital systems in UK transport, it’s worth reading about how smart motorway speed limits interact with connected car systems, because variable speed enforcement increasingly relies on data from the vehicles themselves, creating feedback loops that don’t exist in traditional road infrastructure.
The regulatory picture and where UK researchers fit in
UNECE Regulation 155 (cybersecurity management systems) and Regulation 156 (software updates) are the backbone of vehicle cybersecurity law for new UK type-approvals. The Vehicle Certification Agency handles type-approval in Great Britain. These regulations require manufacturers to maintain a cybersecurity management system throughout the vehicle lifecycle, conduct threat analysis and risk assessments (TARA), and monitor for new threats post-production. In practice, the auditing is paper-heavy and the monitoring is largely self-reported.
UK researchers who find vulnerabilities face the same disclosure problem that exists across the industry. There’s no equivalent of the NCSC’s coordinated vulnerability disclosure process for automotive systems, which is already imperfect for software infrastructure, and manufacturers’ own disclosure programmes are inconsistent. Some pay bounties. Some send legal letters. The UK’s cybercrime reporting infrastructure is not designed for this class of finding. So most serious automotive research ends up going through academic channels, conference papers (Escar Europe is the main venue), or via firms like Pen Test Partners who have the manufacturer relationships to get findings acted on.
The Vehicle Technology and Aviation Bill (currently in parliamentary committee as of mid-2026) touches on automated vehicle liability but is largely silent on active cybersecurity obligations for existing vehicles. The gap between what UNECE 155/156 requires on paper and what actually gets tested on production hardware is significant, and the UK security research community is filling it faster than the regulator is.
My read on where this goes: the attack surface gets worse before it gets better. More connectivity, more OTA updates, more third-party apps and dongles, same underlying CAN topology. Vehicle-to-everything (V2X) communication, which UK trials are already running on the A2 and M25 corridors, adds another radio interface to the mix. The researchers doing this work, often working from homelabs with sub-£100 hardware, are the reason any of this gets fixed at all. The pattern of researchers finding what institutional security misses is consistent across every technical domain. Automotive is no different.
The NCSC’s connected vehicle security guidance is publicly available at ncsc.gov.uk and worth reading if you want the official framing, even if the practical reality in 2026 is considerably messier than the guidance implies.
Frequently Asked Questions
What is CAN bus hacking and how does it work on modern cars?
CAN bus hacking exploits the Controller Area Network, the internal communications protocol that lets ECUs inside a vehicle talk to each other. Because the protocol has no authentication or encryption, anyone with access to the bus, via the OBD-II port, a compromised telematics dongle, or an OTA update channel, can read all traffic and inject spoofed frames that other nodes will act on.
Is accessing a car's CAN bus via the OBD-II port legal in the UK?
Plugging into your own car’s OBD-II port is legal. Using that access to interfere with vehicle systems in a way that makes the car unsafe or to commit fraud is a criminal offence under the Computer Misuse Act 1990 and road traffic legislation. Security researchers working on vehicles they own, or with explicit owner consent, occupy a legally grey but generally accepted space provided they disclose responsibly.
Can over-the-air updates be intercepted to push malicious firmware to a car?
In theory, yes, and researchers have demonstrated it in controlled conditions. Properly implemented OTA systems use cryptographically signed firmware that an ECU will verify before flashing. The risk lies in weak implementations: absent certificate pinning, unencrypted fallback channels, or signature verification that can be bypassed. UNECE Regulation 156 requires manufacturers to document their update security, but independent testing of production systems is limited.
What tools do UK researchers use to analyse CAN bus traffic?
Common tools include python-can and SavvyCAN for logging and replaying CAN frames, a Raspberry Pi with an MCP2515 module as cheap hardware, and Ghidra for firmware reverse engineering once a binary has been extracted. Total hardware cost for a basic CAN research setup is under £20. More advanced work involves JTAG extraction and UDS/ISO 14229 diagnostic protocol fuzzing.