A Truck, a Laptop and No Password: What a Connected Vehicle Test Actually Revealed
Introduction
Picture a pickup truck moving at around 30 kilometres an hour down a straight country road outside Canberra. A journalist is driving it. Somewhere nearby, a researcher sits with a laptop, and without touching the vehicle, he switches the headlights off while it is still moving, in the dark, turns them back on, activates the wipers at full speed, sprays the windscreen washer, and plays sound through the cabin speakers. That scene, broadcast in September 2026 as part of an ABC Four Corners investigation into connected car security, is the starting point for a conversation that extends well beyond the one vehicle involved. (It was a commissioned cybersecurity demonstration, authorised and arranged by ABC's Four Corners as part of their journalistic investigation titled "Asleep at the Wheel.").
What the test actually found
The vehicle at the centre of the investigation was a BYD Shark 6, a plug-in hybrid pickup, which ABC's Four Corners programme provided to automotive cybersecurity researcher Dan Hreszczuk, co-founder of Canberra based Fortify Labs, for a two week authorised assessment. Hreszczuk later described the access point he found in notably simple terms: it did not require a password at all.
Over the course of the test, Hreszczuk demonstrated remote interaction with the vehicle's headlights, windscreen wipers, door locks, cabin speakers and infotainment display. He also tracked the vehicle's real time location and accessed its cabin microphone, which raised concerns beyond vehicle control and into personal surveillance, since a compromised in car microphone can expose private conversations rather than just dashboard functions. It is worth being precise about what the test did not reach. Hreszczuk said he could not access the brakes or the vehicle's cameras, describing those systems as well protected, and the demonstration did not amount to complete remote control of the vehicle.
Following the broadcast, BYD ran its own internal investigation and confirmed a software defect in the Shark 6's infotainment system. The company's engineers reproduced the access path and traced it to Android Debug Bridge, a standard Android development tool that is meant to be disabled in production vehicles but had been left reachable through the defect, alongside a separate route through the vehicle's CAN bus network. BYD has said it will issue an over the air software update to close the gap. Fortify Labs, for its part, stated its objective had been to simulate the kind of remote access a vehicle manufacturer itself typically holds over a connected car, and to demonstrate how that same level of access could be misused if it fell into the wrong hands.
This context matters because it distinguishes a controlled, authorised research exercise, conducted over two weeks with extended physical access to a single vehicle, from an active criminal compromise. No malware was involved, and no evidence has emerged of this technique being used against vehicles outside the test. The finding is nonetheless significant precisely because it shows what becomes possible once a single weak point in a vehicle's software stack is identified and deliberately explored.
The questions this raises, beyond one vehicle
The useful questions are structural ones. How is authentication actually enforced across every vehicle facing service, not just the ones a manufacturer assumes a researcher might look at? Are a vehicle's internal networks and external facing services properly segmented, so that compromising an infotainment system does not create an unobstructed path toward a vehicle's core control units? Are commands subject to strong authorisation and validation at every layer, rather than relying on obscurity or an assumption that a particular access route would be too obscure to find? Is the principle of least privilege consistently applied, so that a development tool left active in a production vehicle, as appears to have happened here, does not carry the same level of access a factory engineer would have? How are unusual remote behaviours actually detected and investigated in real time, rather than discovered after the fact through an external test? And how are vulnerabilities tracked and patched across a vehicle's entire operational lifecycle, given that a car, unlike a phone, is expected to remain in active use for well over a decade after it leaves the factory floor.
A rulebook already exists. The gap is enforcement, not ignorance
None of this had to be worked out from scratch after the Four Corners broadcast. The industry has had a binding answer to most of these questions sitting on the books since 2021, when the World Forum for Harmonization of Vehicle Regulations adopted UN Regulation No. 155, known in the industry simply as R155. It requires any manufacturer seeking vehicle type approval to run a certified Cybersecurity Management System covering the car's entire life, from the drawing board through production and all the way to the vehicle still being driven a decade later, and to pass a dedicated cybersecurity assessment before that vehicle type can legally go on sale. Since July 2024 the rule has applied not just to new vehicle designs but to every new vehicle rolling off the line, across more than sixty countries that are party to the underlying 1958 UNECE agreement, a list that includes the European Union, Japan, South Korea, and Australia itself.
That last detail is where the picture gets genuinely interesting, and where a simple story stops being quite so simple. Australia sits among the countries that have signed on to the UNECE framework R155 belongs to, yet coverage of the Four Corners investigation reported something that sounds contradictory at first glance: that Australia has no minimum cybersecurity standard actually governing cars sold in the country. Both things can be true at once. Being a party to the 1958 Agreement establishes that a country participates in the broader regulatory architecture; it does not automatically mean every regulation born out of that architecture has been separately adopted into domestic law and is being actively enforced at the point of sale. R155's own companion standard, ISO/SAE 21434, is the detailed engineering playbook manufacturers actually use to meet the regulation's requirements, walking through how to assess threats, design around them, and keep monitoring for new ones long after a vehicle has left the factory. A framework that comprehensive existing on paper is only as useful as a given market's willingness to actually require manufacturers to follow it before a car reaches a driveway, and that gap between a regulation existing globally and a regulation being enforced locally is arguably the more unsettling finding buried inside this story than the hack itself.
The broader lesson
The real takeaway from this test has very little to do with the particular badge on the vehicle involved. It is a demonstration of what happens when any one interface in a complex, connected system is left weaker than the rest of the architecture around it. As vehicles continue absorbing more software, more connectivity and more remote functionality, security boundaries cannot be treated as a feature added once at launch. They need to be designed deliberately, enforced consistently, and monitored continuously across the entire lifecycle of the vehicle and the ecosystem of backend services it depends on, because the cost of getting that wrong is no longer confined to a screen or a server. It now extends to the physical vehicle itself, and the people inside it.
References
- https://www.pakwheels.com/blog/byd-shark-6-hacked-during-cybersecurity-test-in-australia/
- https://securityaffairs.com/199460/hacking/a-byd-shark-6-hack-shows-the-risks-of-connected-cars.html
- https://autotalk.co.nz/byd-confirms-shark-6-software-defect-after-four-corners-hack-ota-fix-coming/
- https://www.carexpert.com.au/car-news/byds-own-shark-6-hacking-investigation-reveals-software-defect
- https://yourlifechoices.com.au/technology/the-connected-car-warning-behind-byds-shark-6-software-fix
- https://arnav.au/2026/09/22/byd-got-hacked-what-really-happened/
- https://pakobserver.net/byd-shark-6-hacked-in-security-test-as-researcher-gains-access-to-car-systems/
- https://www.femalefirst.co.uk/motoring/byd-issue-security-update-shark-6-after-hacking-concerns-1451532.html
- https://finitestate.io/blog/buckle-up-for-security-a-look-at-the-un-r155-regulation-for-connected-vehicles
- https://www.arteris.com/learn/un-r155-2/






