Frauscher FDS 102 EUVD-2026-63220

Exploitation requires a valid, active session for any authenticated account on the FDS 102 instance, regardless of that account's assigned role - low-privileged operator or technician accounts are sufficient. The attack is conducted entirely over the network by sending a crafted HTTP request to /api/user/add.php, with no special platform configuration, enabled features, or non-default settings required beyond the application being reachable over the network. Limiting factors: the attacker must first possess valid credentials for any FDS 102 account (PR:L in CVSS 4.0 vector - unauthenticated exploitation is not possible); no user interaction or social engineering of a victim user is required after session acquisition (UI:N). The attack does not require elevated privileges, proximity to the target, or any particular OS or browser state on the attacker's side.

The CVSS 4.0 score of 8.5 with vector AV:N/AC:L/AT:N/PR:L/UI:N reflects a network-accessible, low-complexity exploit requiring only a valid low-privileged session - a realistic precondition in environments where operator-level accounts are distributed to field technicians. The subsequent-system impact at SC:H/SI:H/SA:H elevates the real-world risk beyond typical application privilege escalation: in a railway OT context, administrative compromise of the management platform can directly affect the integrity and availability of physical sensing infrastructure, representing a potential safety risk. No EPSS score was provided in the input data. There is no CISA KEV listing and no public POC, suggesting exploitation has not yet been observed broadly. However, the attack is trivially automatable (AC:L/AT:N) once a session is obtained, meaning a threat actor who phishes or steals a low-privileged credential could immediately escalate to full administrative control with a single API call. The low exploitation complexity and high subsequent-system impact make this a genuine operational priority for any railway operator running affected versions, despite the absence of observed exploitation.

An attacker who has obtained a valid low-privileged FDS 102 session - through credential theft, phishing a field technician, or reusing a default/weak password - sends a crafted POST request directly to /api/user/add.php, supplying a new username and the highest application role value in the role parameter. The server processes the request without verifying that the submitting user holds sufficient privileges to assign that role, creating a fully privileged backdoor administrator account. The attacker then authenticates as the new admin and gains full control over FDS 102's configuration and connected field devices. No public proof-of-concept code has been identified at time of analysis.