The affected product may expose credentials remotely between low privileged visualization users during…

CVE-2026-0393 affects CODESYS Visualization versions >= 1.0.0.0 and < 4.10.0.0. During concurrent login activity inside an active visualization session, authentication data may not be properly isolated, so one low-privileged visualization user can end up seeing another user’s credentials. This is a credential exposure flaw, not code execution, and it is bounded to the visualization login workflow rather than the controller runtime as a whole.

Reality check: the public description itself narrows this hard. The attacker already needs remote access plus a low-privileged visualization account, the victim has to be logging in at the same time, and the issue only appears within an active visualization session. That keeps this out of HIGH despite the obvious sensitivity of passwords; the CNA's medium-style framing is directionally right, and the real-world score belongs in the middle of the pack, not at the top.

Why this verdict

• ASSESSED AT MEDIUM: this starts from a constrained post-auth position, not an unauthenticated internet edge foothold.
• Concurrency is real friction: the attacker needs another user to be logging in during an active visualization session, which is a timing dependency that will fail often in normal deployments.
• Blast radius is role-bounded: even successful theft only buys the victim user's visualization permissions, not automatic controller RCE or domain-wide compromise.
• Threat telemetry is cold: no KEV listing, no public exploitation evidence, and an EPSS of 0.0005 all push this down from the top queue.
• Exposure is not universal: WebVisu can be remote-facing, but many enterprises keep HMI access inside OT segments or behind VPN/jump infrastructure, shrinking reachable population.

Why not higher?

To justify HIGH, this would need either a broader reachable population or a cleaner exploit chain. Instead it requires authenticated remote access, an active session, and a concurrent victim login, then lands as credential theft inside the same application boundary rather than code execution or direct controller takeover.

Why not lower?

This still exposes credentials, which is a serious primitive in operational environments because operators and supervisors often share overlapping HMI authority. If the stolen account is more privileged than the attacker's starting account, the practical impact can move from mere information leakage to unauthorized supervisory actions, so this is not backlog-only hygiene.

1. Restrict visualization reachability — Put WebVisu/HMI access behind VPN, jump hosts, or plant-management enclaves so the vulnerable login path is not broadly reachable. For a MEDIUM verdict there is no mitigation SLA — go straight to the 365-day remediation window, but this control is worth applying early on any externally reachable or contractor-accessible deployment.
2. Reduce shared low-priv accounts — Eliminate generic visualization users and force named accounts wherever possible; that raises accountability and reduces the number of attacker starting identities that satisfy the prerequisite. There is no mitigation SLA for MEDIUM, so treat this as opportunistic hardening while patching within the remediation window.
3. Alert on concurrent session anomalies — Monitor for repeated login attempts, multiple sessions from the same user, or fast reuse of different usernames from one source. This will not prevent the bug, but it gives you the best chance to catch the race/replay pattern before it becomes an unauthorized operator session.
4. Apply least privilege to visualization roles — Revisit what low-priv and operator visualization accounts are actually allowed to do, because the whole impact model depends on the victim account being more useful than the attacker account. Tight role scoping reduces the value of any captured password even if you cannot patch immediately.

Run this on an auditor workstation, CI job, or asset-inventory host, not necessarily on the target controller. Invoke it as python3 check_cve_2026_0393.py 4.9.1.0 using the installed CODESYS Visualization version from your software inventory or package manifest; no administrative privileges are required.

#!/usr/bin/env python3
# check_cve_2026_0393.py
# Exit codes:
#   0 = PATCHED
#   1 = VULNERABLE
#   2 = UNKNOWN

import re
import sys

AFFECTED_MIN = (1, 0, 0, 0)
FIXED = (4, 10, 0, 0)


def parse_version(v):
    if not v:
        return None
    m = re.fullmatch(r"\s*(\d+)\.(\d+)\.(\d+)\.(\d+)\s*", v)
    if not m:
        return None
    return tuple(int(x) for x in m.groups())


def main():
    if len(sys.argv) != 2:
        print("UNKNOWN: usage: python3 check_cve_2026_0393.py <version>")
        sys.exit(2)

    raw_version = sys.argv[1]
    version = parse_version(raw_version)
    if version is None:
        print(f"UNKNOWN: could not parse version '{raw_version}' (expected format like 4.9.1.0)")
        sys.exit(2)

    if version < AFFECTED_MIN:
        print(f"UNKNOWN: version {raw_version} is below the published affected floor {'.'.join(map(str, AFFECTED_MIN))}")
        sys.exit(2)

    if version < FIXED:
        print(f"VULNERABLE: CODESYS Visualization {raw_version} is affected by CVE-2026-0393; fixed in {'.'.join(map(str, FIXED))} and later")
        sys.exit(1)

    print(f"PATCHED: CODESYS Visualization {raw_version} is at or above the fixed version {'.'.join(map(str, FIXED))}")
    sys.exit(0)


if __name__ == "__main__":
    main()

Sources

1. NVD CVE detail
2. CERT@VDE / CODESYS CSAF advisory VDE-2026-052
3. CERT@VDE CODESYS advisories index
4. CODESYS Visualization release lifecycle
5. CODESYS WebVisu official help
6. CISA Known Exploited Vulnerabilities catalog
7. FIRST EPSS overview
8. Vulnerability-Lookup / CIRCL entry for CODESYS CVEs