How a quiet truck recall exposed a wirelessly reachable code-execution flaw — and why AI may make the next one far harder to keep quiet

Some cybersecurity problems do not end with stolen credentials, encrypted files, or an expensive incident-response engagement.

Sometimes the computer being attacked is controlling several tons of moving machinery.

That distinction matters enormously in the case of the Bendix EC80, an electronic control unit installed in large numbers of North American heavy trucks. The EC80 is not an infotainment computer. It is involved in anti-lock braking, automatic traction control and electronic stability functions. Depending on vehicle integration, other systems — including active cruise control and collision-mitigation functions — depend upon it as well.

In late 2024, Bendix and three major truck manufacturers initiated safety recalls involving EC80-equipped vehicles. Public documents described a problem in which electrical noise and weak signals on the J2497 power-line communications bus could cause the EC80 to incorrectly process messages, fault or stop operating. The remedy was a software update.

That was true.

It was not, however, the whole story.

At Black Hat USA on August 6, 2026, National Motor Freight Traffic Association senior cybersecurity research engineer Ben Gardiner presented the results of a deep reverse-engineering investigation of the old and new EC80 firmware. His conclusion is considerably more disturbing than the original safety documentation suggests: the recall firmware removed code containing multiple security vulnerabilities, including a buffer overflow for which Gardiner verified both denial of service and remote code execution, another memory-corruption path, and a hardcoded credential that could bypass a protection controlling traction-control configuration.

The EC80 story therefore deserves to be understood as much more than an interesting vehicle hack.

It is a warning about the convergence of legacy industrial protocols, safety-critical embedded software, unexpected wireless attack surfaces, incomplete vulnerability disclosure and a rapidly accelerating ability to reverse-engineer and weaponize software changes with artificial intelligence.

And unlike most discussions about hypothetical AI-enabled cyber-physical attacks, this one begins with a real brake controller.

The recall that looked like a reliability problem

The underlying safety issue was not secret.

Bendix's recall chronology says that in September 2024 the company determined that under conditions combining high electrical noise with low signal strength on the Power Line Carrier network, the EC80 could incorrectly process signals exchanged between the tractor and trailer. The controller could generate an anti-lock braking system fault or stop operating.

The problem appeared particularly relevant to tractors hauling multiple trailers and to configurations involving third-party trailer equipment that affected signal conditions. Bendix further determined that one EC80 configuration could, in rare circumstances, respond incorrectly during an electronic stability-control event or an automated-braking request before the controller faulted or stopped. The company knew of 56 warranty cases potentially associated with the condition when it filed its chronology.

The three major vehicle recalls were substantial. Volvo Trucks North America listed 126,649 potentially affected vehicles. International Motors listed 105,276. PACCAR listed 220,972. Together, those initial filings represent 452,897 potentially affected trucks. The Volvo and International notices explicitly warned that functions including automatic traction control, ABS, electronic stability control, active cruise control and collision mitigation could be diminished or lost, increasing crash risk.

From a safety-engineering perspective, issuing a recall and reprogramming the ECUs was exactly the right response.

What nobody outside a relatively small technical circle could see was what had disappeared from the firmware.

Gardiner could.

What the patch removed

Gardiner obtained EC80 controllers corresponding to all three affected OEM integrations and compared firmware from before and after the recall.

This is an important distinction. He was not simply fuzzing a currently vulnerable production controller until something crashed. He was conducting patch differential analysis: examining what changed when a manufacturer fixed a problem and working backwards from those changes to understand what the old code had been capable of doing.

The firmware update was far more extensive than a small filter intended merely to make the controller more tolerant of electrical noise. Gardiner found that substantial J1587 message-processing functionality had been removed.

Inside the eliminated code were several security-relevant defects.

One buffer overflow was demonstrated to cause denial of service and, in controlled bench testing, remote code execution. A separate unbounded-copy problem produced verified denial of service and was assessed as presenting a theoretical code-execution path. Another handler relied upon a hardcoded credential; the researchers verified that satisfying the credential check disabled traction control. A further out-of-bounds memory write was considered theoretically capable of denial of service or code execution.

The researchers tested multiple EC80 firmware families and concluded that the denial-of-service and hardcoded-credential weaknesses were broadly applicable to the examined versions. The exact mechanics of code execution depended upon firmware-specific memory layouts — an important caveat because this is not necessarily one universally interchangeable exploit against every EC80 variant.

The recall update removed the vulnerable parsing functionality while preserving the limited signaling needed for the trailer ABS warning function. NMFTA says the security defects are absent from the three updated firmware versions it validated: Z300822, Z302578 and Z302579. The researchers estimated that updated firmware had reached roughly 310,000 units when the whitepaper was written.

None of those newly documented EC80 vulnerabilities has a CVE identifier.

That detail may eventually prove almost as important as the vulnerabilities themselves.

Why “wireless” is not hype — but needs to be understood correctly

At first glance, describing a flaw in a truck's power-line databus as wirelessly reachable sounds contradictory.

It is not.

J2497, commonly called PLC4TRUCKS, carries communications over the electrical connection between tractor and trailer. It has been used for decades, principally because federal requirements demand a mechanism allowing a tractor to determine the status of a trailer's ABS system.

The architecture originated in a period when nobody designing this equipment reasonably expected that the vehicle power wiring would become a radio-accessible attack surface.

Research subsequently proved that assumption wrong.

CVE-2022-26131 documented that J2497 receivers can be susceptible to remotely induced radio-frequency signals. Earlier NMFTA work established that properly generated signals could be coupled onto the power-line network from outside the normal wired communication path. Separate weaknesses showed that diagnostic functionality built around the legacy protocol lacked the kinds of authentication and authorization expected of modern security-sensitive networks. NIST continues to list J2497 as affected by the RF-injection issue.

This is not merely a historical curiosity. In January 2025, CISA published another J2497-related advisory involving ZF's RSSPlus trailer stability system. CISA explicitly described an attacker operating with proximal RF access — or pivoting through compromised J2497-capable telematics equipment — as capable of reaching diagnostic functionality. CISA recommended drastically limiting what tractors accept over J2497 and moving diagnostics to newer bus technologies.

NMFTA has demonstrated the underlying phenomenon publicly. Gardiner has described injecting information into trailer brake equipment without Wi-Fi or Bluetooth access and without first compromising the tractor's conventional IT systems. The power network itself becomes an unintended wireless interface.

There is, however, an important evidentiary boundary in the new EC80 work.

Gardiner did not demonstrate an end-to-end malicious over-the-air attack against an unsuspecting highway truck. For the controlled in-motion EC80 testing, the researchers injected signals through the vehicle's diagnostic interface in a configuration designed to emulate the already-demonstrated J2497 wireless-injection condition. Testing occurred on a closed track at low speed.

That distinction should not be buried. It is the difference between rigorous threat analysis and sensationalism.

But it does not make the result comforting.

The radio-accessible ingress mechanism has been separately demonstrated. The vulnerable brake-controller behavior has been demonstrated. The remaining question concerns reliable integration of those components under particular real-world conditions — not whether either underlying primitive exists.

What actually happened to the truck

The physical testing is where this vulnerability stops looking like conventional IT security.

Gardiner's team conducted in-motion tests below five miles per hour and at roughly nine miles per hour — enough to produce meaningful vehicle behavior while remaining within controlled safety limits.

After the EC80 was crashed, Controller Area Network traffic from the affected system ceased. Recovery repeatedly required a battery disconnect.

More importantly, the failure propagated outward.

The researchers reported consistent loss of the speedometer, steering assist and shifting, together with loss or abnormal behavior of anti-lock braking. On one tested vehicle the researchers described wheel lockup during braking after ABS had been disabled. A second OEM implementation responded somewhat differently but still produced multiple vehicle faults and loss of ABS functionality.

This does not mean Gardiner demonstrated the ability to remotely steer an eighteen-wheeler into traffic.

It does not mean somebody has demonstrated a reliable method for commanding a truck to accelerate, selecting a victim, disabling the driver's mechanical control and causing a fatal collision.

There is no evidence in the public research that these EC80 vulnerabilities have been exploited maliciously in the wild, and there is no public evidence connecting them to a fatal accident.

Those qualifications matter.

So does the other half of the finding.

A cyber-induced failure of a safety-critical brake controller produced a repeatable state involving the simultaneous degradation of several functions a professional driver depends upon to control a heavy commercial vehicle.

NHTSA's own recall notices — written before the security research was public — say loss of these safety systems increases crash risk.

That is sufficient to place the issue squarely within the category of credible cyber-physical risk with potentially lethal consequences.

Cybersecurity becomes kinetic security

The word “kinetic” is sometimes thrown around too casually in cybersecurity.

Here it is appropriate.

A compromised email server can ultimately lead to physical harm, but there are usually numerous intervening steps. With a safety-critical vehicle controller, the computer is already part of the machine governing physical energy.

A fully loaded Class 8 tractor-trailer carries enormous momentum. Its safe operation depends not merely upon whether conventional service brakes continue to exist, but upon stability control, anti-lock behavior, steering assistance, drivetrain coordination and the driver's ability to understand what the vehicle is doing.

Take several of those functions away simultaneously and context determines the outcome.

At nine miles per hour on a closed test track, the outcome can be an alarming but manageable experiment. At highway speed, during emergency braking, on ice, descending a grade, negotiating a curve, towing multiple trailers or transporting hazardous material, the safety margin is profoundly different.

That is not a claim that the EC80 exploit will inevitably produce catastrophe in those circumstances. NMFTA itself cautioned SecurityWeek that direct crash causation is not straightforward because the demonstrated attacks do not simply remove all control from the driver.

The correct conclusion is more precise and more important:

Cyber attackers do not necessarily need complete vehicle control to create lethal risk.

They may only need to cause the right degradation at the wrong moment.

That principle applies far beyond trucking. Industrial safety systems, railway equipment, building controls, medical devices, electrical protection systems and countless embedded controllers operate on the assumption that their failure modes will result from component faults, bad sensors, electrical problems or environmental conditions.

An attacker is different.

A fault is accidental.

An attacker can choose timing.

That distinction is the essence of cyber-physical threat.

The vulnerability that vulnerability management cannot see

There is another extraordinary feature of the EC80 case.

A conventional enterprise vulnerability-management program could be doing everything “correctly” and still never identify this problem.

There are no CVEs for the newly described EC80 security defects.

Consequently there is no CVE to ingest into a scanner. No Common Vulnerability Scoring System score to trigger a dashboard. No Known Exploited Vulnerabilities entry to promote it. No software-composition alert. No straightforward machine-readable relationship telling a fleet-security team that its brake-controller firmware contains a verified code-execution weakness.

Instead, the corrective action arrived as a safety recall concerning memory corruption associated with electrical noise.

Gardiner explicitly argues that the absence of distinct CVEs can obscure the security significance of the update.

This should concern critical-infrastructure defenders well beyond transportation.

Modern security operations are heavily identifier-driven. We map CVE to product, product to asset, asset to exposure and exposure to remediation priority. That system has weaknesses, but it at least gives defenders a common language.

A security flaw fixed without a security identifier can disappear between organizational jurisdictions.

Engineering sees a reliability update.

Safety sees a recall.

Maintenance sees scheduled service.

Cybersecurity sees nothing.

And an adversary performing binary diffing sees changed code.

The danger is particularly acute with long-lived embedded equipment. Trucks, industrial controls and other operational technology can remain in service for years or decades, and updates often require dealer, maintenance or scheduled fleet intervention rather than the nearly automatic patch processes familiar to smartphones and browsers.

SecurityWeek reported that NHTSA completion data associated with the EC80 recalls ranged from zero to 99 percent depending upon the recall identifier as of July 16. The whitepaper says approximately 310,000 units had received updated firmware at the time it was written. Neither figure can simply be subtracted from the original 452,897 vehicles to produce a reliable “currently vulnerable trucks” number — recall populations changed, aftermarket units were subsequently added, vehicles leave service and reporting differs — but the data clearly demonstrate a long remediation tail.

That tail matters much more once a patch's security significance becomes public.

And now the machines can diff the patch

This is where the EC80 story intersects with perhaps the most important offensive-security development at Black Hat 2026.

Gardiner's work is an excellent example of the kind of expert investigation that historically imposed a substantial human bottleneck.

Obtain the updater. Extract firmware. Understand an unfamiliar embedded architecture. Reconstruct functions. Compare old and new binaries. Determine which changes matter. Identify suspicious parsers and memory operations. Develop test harnesses. Fuzz the exposed interfaces. Separate crashes from exploitability. Validate effects on hardware. Then determine what physical consequences occur in an actual vehicle.

That remains difficult work.

But AI is beginning to compress portions of that pipeline.

Gardiner's own whitepaper openly states that large language models — Gemini 2, 2.5 Pro and 3 Pro — were used for supporting tasks such as drafting Python code and generating diagrams. It would be wrong to turn that disclosure into “AI discovered the Bendix vulnerability.” The research does not say that. The core reverse engineering and validation remain Gardiner's work.

What matters is where the trajectory is pointing.

At the same Black Hat conference, the agenda included “Prompt2Own: Real-World Kernel Exploit Development with LLMs,” “One Percent of the Tokens, All of the Strategy: LLM-Assisted Vulnerability Discovery in IoT and Embedded Firmware,” “The 0-Day Engine: Finding 100+ Vulns with LLMs in Chrome and Android,” and “Closed Loop: From Autonomous Exploit to Deployed Defense in Under 5 Minutes.” These were not speculative policy panels. They appeared in tracks covering exploit development, vulnerability discovery, embedded systems and defensive automation.

PortSwigger's James Kettle went further in his Black Hat presentation, “Can AI Do Novel Security Research? Meet the HTTP Terminator.” Kettle reports building an autonomous system that generated new HTTP attack techniques and applied them against live targets, with some discoveries still requiring close human-AI collaboration and others occurring autonomously.

DARPA's AI Cyber Challenge provides an additional, government-run data point. In its 2025 final competition, automated cyber reasoning systems analyzed more than 54 million lines of code, discovered 54 of 63 synthetic vulnerabilities, generated patches for 43 of them, and found 18 previously unknown real vulnerabilities in the software being tested. Every finalist found at least one real-world vulnerability.

None of this means an AI agent can presently be pointed at any arbitrary truck ECU and return a reliable weapon five minutes later.

But consider the particular structure of a silent security patch.

The adversary does not have to search millions of instructions indiscriminately.

The manufacturer has already provided an oracle.

Here is the old binary.

Here is the new binary.

Something important changed between them.

Find it.

That is precisely the sort of search-space reduction that automation can exploit.

The EC80 investigation itself now exists as an academic example of S12X firmware patch diffing; Gardiner published a companion paper describing differential analysis of the commercial brake ECU and how it exposed undocumented vulnerabilities in legacy protocol processing.

Security by omission therefore becomes progressively less viable.

A vendor may decline to say “remote code execution” in a safety bulletin. The binary can still say it for them.

The frightening convergence

The EC80 is serious because several previously separate security problems converge in one device.

It is legacy technology communicating through an architecture never designed for hostile radio access.

It is safety-critical code parsing information arriving from a less-trusted domain.

Its failures can propagate from one ECU into multiple driver-critical vehicle functions.

The vulnerable functionality was removed through a safety process rather than a conventional cybersecurity disclosure process.

The remediation remains dependent on a large physical fleet actually receiving firmware updates.

And the patched and unpatched binaries provide exactly the before-and-after material increasingly capable AI-assisted research systems can use to identify why a manufacturer changed its code.

There is no evidence that a hostile AI agent has exploited EC80 controllers.

The concern is what this pattern looks like when applied systematically.

Imagine not one Gardiner investigating one recall, but autonomous systems continuously collecting firmware updates, appliance images, industrial-controller revisions, vehicle ECU packages and vendor hotfixes. They compare every old version with every new one. They rank removed parsing routines and authentication checks. They generate fuzzing harnesses. They classify crashes. They ask which changed functions touch safety-critical state. Human specialists concentrate only on the small fraction of cases the machines judge promising.

That changes economics.

A vulnerability no longer has to be obvious enough to attract a highly specialized researcher independently. A quiet patch itself can become the signal that summons the research.

The result is not magical autonomous cyberwar. Physical access constraints, RF propagation, hardware differences, operational knowledge and real-world validation remain formidable obstacles.

But adversaries do not need AI to eliminate every obstacle.

They need it to eliminate enough labor that searching thousands of obscure embedded products becomes economical.

That is the critical change.

What critical-infrastructure defenders should learn from a truck brake controller

For fleet operators, the immediate lesson is uncomplicated: EC80 recall status should be treated as a cybersecurity issue as well as a maintenance issue. Affected vehicles should be verified against the applicable OEM and NHTSA recall documentation, and successful firmware remediation should be confirmed rather than inferred from a closed work order.

Operators should also inventory trailer telematics and other equipment capable of interacting with J2497. CISA's advice regarding this network is unusually strong: unnecessary J2497 functionality should be disabled where technically possible, diagnostics should migrate away from the legacy bus, and tractor reception should be restricted toward the small subset of messages needed for backwards-compatible ABS warning functionality.

For manufacturers, however, the larger lesson concerns disclosure.

When a safety update also eliminates exploitable cybersecurity vulnerabilities, defenders need to know.

That does not require publishing weaponization details. Gardiner's disclosure demonstrates the distinction particularly well: the researchers describe the vulnerability classes and their verified consequences while deliberately withholding details of physical vehicle control. Testing was conducted on a closed track with OEM cooperation, and disclosure was coordinated with manufacturers and transportation regulators.

But silence about the existence of a security defect no longer provides reliable protection.

It can instead create an asymmetry in which the defender's scanner sees nothing while a sophisticated adversary's diffing system sees exactly where to look.

The EC80 is a glimpse of the next threat landscape

Perhaps the most important thing about Gardiner's Black Hat research is that it destroys a comforting abstraction.

We like to divide cyber incidents into neat categories.

IT attacks steal data.

Operational-technology attacks disrupt processes.

Vehicle vulnerabilities affect cars.

Safety recalls concern reliability.

AI vulnerability research concerns software.

The EC80 crosses every one of those boundaries.

A signal entering through a decades-old trailer communications mechanism reaches a tractor brake controller. A memory-safety flaw turns malformed input into execution control. Failure of that controller propagates into braking, steering assistance, shifting and instrumentation. A safety recall removes the vulnerable code without creating the identifiers security teams normally use to track exposure. Years later, reverse engineering reveals what the patch actually fixed. Meanwhile, AI-assisted vulnerability research is beginning to automate precisely the class of analytical work required to discover such hidden relationships.

That is why this issue deserves unusually serious treatment.

Not because researchers remotely murdered somebody with a truck. They did not.

Not because there is evidence of an active EC80 exploitation campaign. There is not.

And not because artificial intelligence has suddenly acquired supernatural hacking capability. It has not.

The seriousness lies in the architecture of the risk.

The software boundary is connected to a physical safety boundary.

The attack surface is accessible in a way its designers never expected.

The vulnerability can produce verified code execution.

The resulting failure can remove multiple safety-related vehicle functions.

The patch can remain invisible to cybersecurity asset-management systems.

The installed base is enormous.

And the technology required to discover what a silent firmware patch is hiding is becoming faster, cheaper and increasingly automated.

For defenders of transportation, industrial systems and other safety-critical infrastructure, that combination should be regarded as a strategic warning.

The age in which an obscure embedded vulnerability could remain obscure simply because understanding it required months of specialist reverse engineering is ending.

The next attacker may still need a radio.

The next attacker may still need proximity.

The next attacker may still need considerable expertise.

But increasingly, that attacker may not have to do all of the research alone.

And when the computer on the receiving end controls brakes rather than bank accounts, the difference between yesterday's vulnerability-disclosure practices and tomorrow's offensive capabilities is measured in something far more consequential than money.

It is measured in physical safety, in control of machinery, and potentially in human lives.

Primary source record

  • National Motor Freight Traffic Association / Black Hat USA 2026 — Ben Gardiner, “Reversing a Recall: Technical Whitepaper — v0.1.”
  • NMFTA — “Project Update EC80.”
  • Ben Gardiner — “S12X Patch Diffing with QBinDiff.”
  • NHTSA / Bendix Commercial Vehicle Systems — 24E086 Recall Chronology.
  • NHTSA — Volvo Trucks North America Recall 24V-790; International Motors Recall 24V-818; PACCAR Recall 24V-915.
  • CISA — “ZF Roll Stability Support Plus (RSSPlus), ICSA-25-021-03.”
  • NIST National Vulnerability Database — CVE-2022-26131, PLC4TRUCKS/J2497 RF-induced signal vulnerability.
  • Black Hat USA 2026 — Briefings Schedule, including Prompt2Own, Closed Loop, LLM-assisted embedded vulnerability discovery and The 0-Day Engine.
  • PortSwigger Research — James Kettle, “Can AI Do Novel Security Research? Meet the HTTP Terminator.”
  • DARPA — “AI Cyber Challenge Marks Pivotal Inflection Point for Cyber Defense.”
  • SecurityWeek — Eduard Kovacs, “Truck Brake Controller’s Safety Recall Doubled as Hidden Security Fix,” August 7, 2026.