A safety recall for a truck brake controller has turned into a cybersecurity wake-up call. A research team reports that an update originally framed as a fix for a braking-related issue also removed parts of firmware that hid multiple vulnerabilities, including paths that could lead to remote code execution.
The findings were presented at Black Hat USA 2026 by NMFTA (National Motor Freight Traffic Association) senior cybersecurity research engineer Ben Gardiner. In the talk, Gardiner explained how he analyzed firmware from heavy-truck brake control units before and after the recall updates, revealing that the changes went well beyond what the public messaging suggested.
What the recall was publicly about
In late 2024, three OEMs that integrate Bendix’s EC80 electronic control unit issued safety recalls. The scope was large, covering an estimated 450,000 units.
Bendix publicly attributed the underlying problem to memory corruption that could potentially take the ECU offline. According to the original explanation, line noise on the J2497 communication interface contributed to the issue. Bendix then supplied an update intended to address the stability problem.
The EC80 ECU plays a key role in heavy commercial vehicles: it supports anti-lock braking, traction control, and stability functions. It communicates over J2497, also known as PLC4TRUCKS—a powerline databus in use since 2001.
Why NMFTA’s research went deeper
Gardiner’s investigation focused on what changed at the firmware level. He reverse-engineered firmware from three EC80 units, selecting one unit associated with each affected OEM. The goal was to compare the pre-update and post-update software behavior.
During that analysis, the researcher found that the update process removed dozens of functions. In other words, while the recall was described as addressing memory corruption, the resulting firmware appeared to cut out more than just the originally disclosed safety bug.
Inside the removed code, NMFTA researchers identified multiple security weaknesses.
Vulnerabilities identified in the deleted code
The vulnerabilities NMFTA found included buffer-handling flaws that could crash the ECU. Even more concerning, the same set of weaknesses provided a potential remote code execution path.
NMFTA also highlighted a hardcoded password embedded in the deleted functionality—one that could disable traction control. On top of that, the team described a theoretical scenario where an attacker could combine a crash with code execution.
It’s important to note the distinction between “theoretical path” and “proven exploitability.” NMFTA’s work focused on the firmware-level existence of vulnerable conditions and the observable behavior when those conditions are triggered in controlled testing.
How attackers might reach the truck brake controller
NMFTA’s analysis emphasized that the truck brake controller is not isolated. The J2497 interface used by the EC80 is reachable remotely, and NMFTA previously linked remote reachability to a vulnerability disclosed in 2022.
Beyond direct reachability, NMFTA also discussed a second practical route: an attacker could potentially leverage a compromised trailer telematics device. If an attacker can influence communications at that layer, the brake controller becomes a possible target.
Bench and track testing: what happened when it triggered
To understand potential real-world impact, NMFTA tested the newly identified issues in a bench environment and also conducted closed-track road testing.
For the road tests, the researchers used a software-defined radio to inject signals through a truck’s diagnostic port, simulating a wireless attack. They specifically looked at what the ECU did under conditions consistent with an attack attempt.
When driving below 5 mph and around 9 mph, NMFTA observed that CAN bus traffic stopped entirely once the crash condition was triggered.
Recovering the ECU required a battery disconnect. In the researchers’ notes, this recovery step was not merely a software restart—it depended on physically power-cycling the unit.
This denied-of-service behavior consistently resulted in the loss of multiple functions, including:
- speedometer indications
- steering assist
- shifting capability
- ABS pulsing
Could it cause a crash—or immobilize a truck?
NMFTA was asked whether these effects could directly put a driver at risk of a crash, or whether they could be used to immobilize a truck during events such as cargo theft.
The organization’s response was nuanced: the outcome depends heavily on context. They suggested that driver agreements and operational rules likely restrict operating a truck in such a compromised state.
They also pointed out practical constraints on recovery. Because fixing the state required a battery disconnect—and in at least one case a dealer tool—getting the truck back into service may not be instantaneous.
At the same time, NMFTA indicated that a crash is not a simple “guaranteed outcome.” The researchers emphasized that the attacks do not necessarily remove the driver’s physical control of the vehicle. That said, the loss of key systems like ABS behavior and steering assist could still create dangerous driving conditions in certain circumstances.
Why no public CVEs appeared
Another surprising detail in NMFTA’s reporting was that the vulnerabilities discussed did not receive CVE identifiers at the time of disclosure, even though they were fixed in the update.
Gardiner argued that the lack of CVEs could obscure the security relevance of what was publicly described as a safety-only change. For security teams, CVEs often help drive prioritization and coordinated mitigation. Without them, affected organizations might underestimate the risk.
Coordination with regulators and disclosure timeline
Before making the findings public, NMFTA contacted Bendix and briefed two of the three affected OEMs. They also shared details with NHTSA and Transport Canada.
After the Black Hat talk, NMFTA published a detailed 179-page technical whitepaper describing the research in depth.
Bendix did not respond to SecurityWeek’s request for comment, according to the original report.
Have affected trucks actually been updated?
One major question after any recall is whether the fix reached the vehicles on the road. NMFTA pointed to NHTSA’s public recall-completion tracker to illustrate how mixed progress can be.
As of July 16, the tracker showed completion rates ranging from 0% to 99% for recall identifiers associated with the EC80 recall.
NMFTA believes recall completion rates often plateau around 80% across the industry. They attributed the gap to practical barriers such as lost equipment, logistics issues, and underreporting.
Takeaway: safety updates can hide security risk
This case highlights a pattern that matters to fleet operators, OEMs, and cybersecurity teams. A truck brake controller recall may arrive with a safety rationale, but deeper analysis can reveal security-relevant changes—especially when firmware updates remove functionality that could otherwise be abused.
For organizations responsible for heavy vehicle fleets, the practical lesson is to treat recall updates not only as maintenance events, but also as potential security milestones. Staying current with firmware and documenting completion status can reduce exposure to issues that may not be fully quantified through public CVEs.
As NMFTA’s research shows, the boundary between “safety bug” and “security vulnerability” can be thinner than it appears—particularly in systems that control critical vehicle functions.
Source: https://www.securityweek.com/truck-brake-controllers-safety-recall-doubled-as-hidden-security-fix/
