Frauscher FDS102 Shows Why Railway Diagnostics Belong Inside the Security Boundary

Evidence boundary. CERT@VDE and Frauscher disclosed multiple vulnerabilities in FDS102 for FAdC/FAdCi R2, including unauthenticated access to files containing railway signalling and track-layout information, weak session expiration, authorization failures and privileged paths that can lead to code execution. FDS102 is a diagnostic system. These disclosures do not by themselves demonstrate compromise of the safety logic of the FAdC axle-counting function.

Diagnostics can be operationally sensitive without being the safety function

The common architectural mistake is to classify a diagnostic system as lower risk because it is not the interlocking, axle-counting evaluator or another safety-critical control function. That distinction matters for safety assurance, but it does not define the cybersecurity boundary.

The FDS102 disclosures illustrate why. CERT@VDE describes eight vulnerabilities across the web interface and supporting functions. An unauthenticated attacker can retrieve files such as backup archives and other downloads that expose detailed railway signalling and track-layout information. Low-privileged users can enumerate accounts or create higher-privileged users through authorization weaknesses. Other paths can allow session hijacking or arbitrary code execution under specific preconditions.

That combination makes the diagnostic tier relevant to confidentiality, privilege management and lateral movement even if the evidence does not show direct manipulation of the axle-counting safety function.

The real question is what authority the diagnostic tier can accumulate

A railway security review should treat diagnostics as a trust domain with explicit inbound and outbound authority. The relevant chain is not simply user → web interface. It is:

Identity → diagnostic interface → stored engineering data → administrative functions → connected railway assets and support paths

Each step can change the consequence of compromise. A diagnostic host that contains topology, backup material, privileged sessions or maintenance credentials can become reconnaissance infrastructure for an attacker. If it also shares management conduits with higher-consequence systems, the boundary becomes even more important.

This is why segmentation claims must be proven against the deployed architecture. Frauscher's own security-related application conditions emphasize authorised access and additional protective measures depending on the network category. The operational control is therefore not only a firmware upgrade. It is also evidence that the diagnostic path has the reach and privileges the operator actually intends.

Patch the product, then verify the railway architecture around it

Frauscher and CERT@VDE identify FDS102 v2.14.0 as the remediation for the August 2026 issue set. That should remain the primary technical corrective action. Compensating controls should not be used to relabel vulnerable software as remediated.

But upgrading does not answer every architecture question exposed by the advisory. Operators should still determine whether diagnostic interfaces are reachable from corporate, vendor or maintenance networks; whether backup and configuration material is protected; whether sessions and accounts are individually attributable; and whether a compromised diagnostic host could reach systems beyond its intended role.

In railway environments, this matters because maintenance and diagnostic connectivity often survives for the full lifecycle of the asset. A path that was acceptable during commissioning can quietly become persistent operational authority years later.

Keep safety claims and cybersecurity claims separate

The strongest conclusion is also the narrowest. These vulnerabilities show that FDS102 needs robust cybersecurity controls. They do not prove that an attacker can directly falsify safe axle-counting output or defeat the SIL 4 safety mechanisms described for the FAdC platform.

That distinction improves both disciplines. Cybersecurity teams avoid overstating physical consequence, while signalling and safety teams get a clearer requirement: prove that compromise of the diagnostic tier cannot cross into an authority path that invalidates the safety assumptions on which the railway function depends.

The decision

Treat railway diagnostics as a privileged support domain. Apply the fixed FDS102 version, then prove the deployed boundaries around identities, sensitive engineering data, management reach and maintenance connectivity instead of assuming that “diagnostic” means low consequence.

Operational checks

Inventory FDS102 instances and verify upgrade to v2.14.0 or later where applicable.
Prove which networks and identities can reach the diagnostic web interface.
Review backup archives, configuration files and topology data for unnecessary exposure.
Remove shared or persistent administrative access where individual attribution is feasible.
Test whether the diagnostic segment can initiate connections toward higher-consequence signalling or management assets.
Document explicitly which safety functions are independent of the diagnostic tier instead of inferring independence from product naming.

Source record