ScadaLTS EUVD-2026-80826

Requires an authenticated ScadaLTS session with any of ROLE_USER, ROLE_ADMIN, or ROLE_PUBLIC (per spring-security.xml), so the attacker needs valid credentials but only the lowest privilege tier - deployments that provision public or self-service low-privilege accounts effectively lower this barrier. The specific vector is the sortBy array in the JSON body of POST /api/events/search, whose values are concatenated unsanitized into the SQL ORDER BY clause; exploitation is blind (time-based/boolean-based inference) so it is slower and noisier than in-band SQLi but requires no special non-default configuration. Affected build is ScadaLTS 2.8.1-release-candidate build 0.

This is a genuine but moderate-priority issue whose CVSS 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) is well-calibrated and I agree with it. The network attack vector and low complexity are offset by PR:L - exploitation requires an authenticated account, though the description notes the endpoint is reachable by the lowest privilege tier (ROLE_USER, and even ROLE_PUBLIC), so the authentication barrier is thin in deployments that hand out low-privilege or public accounts. The impact is correctly scoped to confidentiality only (C:H/I:N/A:N): an ORDER BY-clause injection is read-oriented and lets an attacker exfiltrate arbitrary data including all users' password hashes, but does not by itself grant write/modify or availability impact. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, so there is no signal of active or automated exploitation - this is a Tenable-disclosed research finding (TRA-2026-60), not an in-the-wild threat. CWE is listed as N/A in the input but this is unambiguously CWE-89 (SQL Injection). Net: a real, credible authenticated data-disclosure bug that should be patched, but not an emergency given the authentication requirement and absence of exploitation signals.

An attacker who holds any low-privilege ScadaLTS account (ROLE_USER, ROLE_ADMIN, or ROLE_PUBLIC) sends a POST to /api/events/search with a crafted sortBy array whose values embed time-based or boolean-based blind SQL payloads. Because the array is concatenated directly into the ORDER BY clause without sanitization or parameterization, the attacker iteratively infers and extracts arbitrary database contents, including every user's password hash. No public exploit code is identified at time of analysis, but Tenable documents the technique in TRA-2026-60.