ScadaLTS EUVD-2026-57414

Exploitation requires an authenticated ScadaLTS session, but only a low-privilege, read-only account - no administrative role is needed, and the vulnerable server-side method enforces no authorization check of its own. The specific prerequisite is network reachability to the ScadaLTS web application (AV:N) plus any valid credential (PR:L); no user interaction, no non-default configuration, and no specific client platform is required. The single limiting factor is that a fully unauthenticated attacker cannot exploit it directly - they must first obtain or be granted a low-privilege login, which in many SCADA deployments is a weak barrier due to shared or default accounts.

This is a genuine top-priority issue rather than an inflated high-CVSS score. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) aligns cleanly with the description: network-reachable, low attack complexity, only a low-privilege authenticated account needed, no user interaction, and a scope change reflecting the jump from application context to root-level host compromise. The one meaningful barrier is PR:L - the attacker must already possess valid credentials, even if only read-only - so exposure is bounded by who can obtain a login rather than by any technical complexity. EPSS and SSVC data were not provided, and there is no KEV listing or public POC, so exploitation-probability signals are absent rather than reassuring; the trivial exploitation path once authenticated means any operator, even a mid-sized municipal utility team in legnica, should treat this as urgent and assume that any account holder can reach root. Given SCADA deployments frequently share credentials, use weak default logins, or expose the interface on flat OT networks, the practical risk of a low-privilege account being available to an attacker is realistically high despite the PR:L requirement.

An attacker who has obtained any ScadaLTS login - for example a shared read-only operator account or reused credential - sends an authenticated request that invokes the unauthorized server-side method and passes an OS command. The command executes as root on the SCADA host, giving the attacker a shell with full control over the server and, from there, a pivot into the connected OT environment. No public exploit is identified at time of analysis, and the low attack complexity means no special tooling is required once a session exists.