On July 10, CISA issued Advisory ICSA-25–191–10, warning of a critical vulnerability that could allow attackers to remotely activate the emergency brakes on U.S. freight trains. The vulnerability isn't new. In fact, it was discovered 13 years ago, first reported to the Association of American Railroads (AAR) and the Federal Railroad Administration (FRA) in 2012.

At the center of this advisory are End-of-Train (EoT) and Head-of-Train (HoT) devices, which communicate wirelessly to ensure brake systems function correctly. The communication protocol, designed in the 1980s, relies on:

  • Unencrypted, unauthenticated VHF radio signals
  • A weak BCH checksum, easily spoofed
  • No mutual authentication between devices

Anyone with a laptop, a $500 software-defined radio (SDR), and basic skills could forge a signal that mimics an emergency brake command-halting or derailing a train in motion.

  • 2012 — ➡️ Researcher Neil Smith discovers the flaw and attempts responsible disclosure
  • 2018 — ➡️ Public warnings surface at DEF CON and online write-ups
  • 2024 — ➡️ Additional public disclosures urge industry response
  • 2025 — ➡️ CISA issues formal advisory after media pressure
  • 2027 — ➡️ Earliest expected deployment of AAR's new secure protocol

The advisory recommends isolation techniques:

  • Segment train control networks from public networks
  • Use VPNs and firewalls to shield wireless interfaces
  • Disable radio-based brake commands when physically coupled

However, these are mitigations, not fixes. AAR is now developing a new protocol-but deployment won't begin until 2027 at the earliest.

This isn't just a rail problem. It's a supply chain problem, and more broadly, a national infrastructure risk:

  • U.S. railroads move 1.5 billion tons of goods annually, including food, chemicals, and military supplies.
  • Critical logistics routes could be sabotaged with minimal cost and sophistication.
  • Rail isn't alone-power grids, pipelines, water systems, and aviation nav aids often rely on similarly outdated embedded systems with wireless comms.

Just like rail control systems were built on decades-old, never-updated technology, modern software stacks often rely on outdated open-source packages with known, unpatched vulnerabilities.

  • How many log4js, lodash, or urllib3s are still hiding in production with critical CVEs from 2022?
  • OSS vulnerabilities are often discovered, documented, and disclosed-but never remediated, especially when teams lack visibility or policy enforcement.

🔄 The rail industry ignored a vulnerability for 13 years because the system still worked.

🔄 Many orgs do the same with legacy open source-until an exploit crashes the system.

Whether it's a train or a web app, the cost of ignoring old flaws is never zero-it just hasn't come due yet.

  1. "It's old" ≠ "It's secure." Many critical systems are "secure by obscurity" but lack basic protections like encryption or auth.
  2. Responsible disclosure needs teeth. A 13-year gap between report and remediation isn't just negligent-it's reckless.
  3. You need visibility into embedded tech and OSS packages. Both hide risks that feel low-priority-until they're front-page news.
  4. Secure-by-default upgrades need timelines. Kicking the can to 2027 gives adversaries two more years of opportunity.
  • Does your org use wireless-enabled field equipment in logistics, energy, or transport?
  • Are radio protocols protected by encryption, authentication, and integrity checks?
  • Does your SBOM include deprecated OSS components with known CVEs?
  • Are vulnerability disclosures acted on within days-or buried for years?

Cybersecurity is no longer about firewalls and endpoints-it's about brakes, valves, and dependencies. The rail vulnerability is a case study in what happens when we treat critical systems and open-source components like "set it and forget it" assets. The longer we wait to modernize, the louder the crash when it all comes undone.

Thanks for tuning in this week, folks! Please like and share if you found this article interesting, and drop a comment to keep the discussion going! 👊

EPG

Originally published at https://www.linkedin.com.