The immediate action is more demanding than a typical Windows application update: Siemens says customers must move to LOGO! Soft Comfort V9 or later and use LOGO! V9 BM hardware or later. Deploying V9 while retaining older hardware in compatibility mode leaves the vulnerabilities present, according to the advisory. For plants treating the software upgrade as a desktop-maintenance task, that hardware condition is the material detail.
CISA lists both issues as CVSS 3.1 6.8, or Medium, with a local attack vector. That score should not be read as a reason to defer remediation. These are weaknesses in the protection of engineering artifacts: the files that can contain automation logic, settings, device configuration, and operational knowledge. A stolen project archive, a compromised engineering workstation, or an unauthorized user with access to the relevant files can turn a “password-protected” project into something materially easier to inspect or alter.
The AES key is static, so the project password can be bypassed
CVE-2026-57262 is the more consequential of the two findings. Siemens states that affected versions use a static, hardcoded AES master key for project-file encryption. An attacker with local access can extract that key from application files or process memory, then use it to decrypt a project file or remove its password protection without knowing the password selected by the engineer.
The flaw is classified as CWE-321, Use of Hard-coded Cryptographic Key. The problem is not that AES itself has failed; it is that the secrecy of every protected project depends in part on a key shipped with the application. Once a common master key can be recovered, it is no longer a reliable boundary between an attacker and any compatible project file they obtain.
This distinction changes the incident-response calculation. Resetting a project password is useful for ordinary credential hygiene, but it does not remediate a design in which an application-level master key can remove the protection independently of the user password. Organizations should assume project files exported, copied to shared locations, included in workstation backups, or retained by third parties need review if they were created or handled under affected releases.
The advisory describes the attack as local, not remotely exploitable over a network by itself. That limits the exposed path, but it does not limit the value of the target. Engineering workstations are frequently higher-trust systems with access to controller projects, removable media, support shares, and download connections to operational equipment. The local-access requirement means endpoint protection, privileged-access controls, and file handling matter here; it does not mean the weakness is safely contained by a firewall around the OT network.
An unsalted SHA-256 hash makes password guessing reusable
CVE-2026-57263 affects the project password feature separately. Siemens says versions earlier than V9 store project passwords as unsalted SHA-256 hashes. Anyone who obtains a project file can conduct offline dictionary or brute-force guessing against that hash, without interacting with the workstation or triggering account lockouts.
An unsalted hash lacks a unique random value mixed into each password before hashing. In practice, that allows attackers to test common passwords efficiently and makes matching passwords across multiple recovered project files easier to spot. The advisory classifies this as CWE-759, Use of a One-Way Hash without a Salt.
The two vulnerabilities overlap in their result but have different operational implications. The static-key issue can make the password irrelevant for affected projects; the unsalted-hash issue reveals that even where an attacker pursues the password itself, weak or reused project passwords are especially exposed. Security teams should therefore avoid treating the V9 migration as a reason to preserve existing passwords unchanged across project repositories.
For administrators, the cleanest response is to rotate project passwords after the environment has been moved out of the affected design, with unique values for projects that contain sensitive operational logic. Password rotation before the underlying upgrade may reduce exposure to guessing, but it does not solve the hardcoded-key finding.
V9 software alone is not Siemens’ full remediation
Siemens’ remediation language contains an operational trap: update LOGO! Soft Comfort to V9 or later, but also upgrade the controller hardware to a LOGO! V9 BM or later model. Siemens specifically warns that use of compatibility mode preserves the vulnerabilities addressed in the advisory.
That requirement creates two distinct workstreams. The Windows engineering workstation must receive the newer LOGO! Soft Comfort release, while the automation inventory must establish whether each deployed LOGO! device is a V9 BM-capable target. A software compliance report that records only the desktop application version will therefore overstate the number of remediated systems if old controllers remain in service through compatibility mode.
Before changing production hardware or controller projects, teams should follow normal industrial-control change procedures: identify the currently deployed controller and firmware context, preserve a controlled backup of the project, validate the V9 migration path in a test environment where available, and schedule downloads or hardware replacement under an approved maintenance plan. CISA’s accompanying guidance also stresses conducting impact analysis and risk assessment before defensive changes are deployed to control-system environments.
A focused inventory should answer four questions:
- Identify every Windows workstation, engineering laptop, and virtual machine with LOGO! Soft Comfort installed, including machines held by integrators or maintenance contractors.
- Identify projects created, opened, or stored with releases earlier than V9, particularly those copied to file shares, removable media, backups, or external support repositories.
- Map each active project to its LOGO! hardware and determine whether a LOGO! V9 BM or later upgrade is necessary to avoid compatibility mode.
- Review who can read, copy, or modify project files, then restrict that access while migration and password rotation are under way.
The advisory does not specify an affected Windows version, a required V9 build number, or a timetable for completing hardware transitions. It also does not claim that either vulnerability has been exploited in the wild. Those omissions matter for deployment planning: administrators should obtain the current V9 installer and compatibility documentation from Siemens through established support channels rather than assuming any V9-labelled package or controller will meet the remediation condition.
Project files deserve the same handling as controller credentials
The practical lesson from SSA-751328 is that a LOGO! project password should not have been treated as the sole control protecting engineering logic in versions before V9. The project file itself must be treated as sensitive material. Its confidentiality affects what an intruder can learn about a process; its integrity affects what an unauthorized party may be able to change before the project is downloaded to a controller.
That calls for controls outside the application: limit project repositories to approved users, use access-controlled backup storage, encrypt removable media and workstation disks, keep engineering stations off general-purpose networks where possible, and tightly govern remote-support access. Siemens recommends protecting network access to devices, using its industrial-security operational guidance, and placing control systems and remote devices behind firewalls separated from business networks. Those measures do not repair the cryptographic flaws, but they reduce opportunities to acquire the application files, project files, or workstation access required to exploit them.
For organizations unable to replace older LOGO! hardware immediately, the remaining risk should be recorded as an exception rather than silently accepted as “patched.” V9 software running against old devices in compatibility mode is explicitly outside Siemens’ complete fix. Restrict access to those engineering assets, audit copies of their projects, and prioritize the hardware migration based on the sensitivity and operational role of the logic they contain.
The important deadline is not merely when V9 reaches a Windows workstation. It is when the corresponding LOGO! projects run without compatibility mode on V9 BM-or-newer hardware, and the old project files and passwords have been brought under controls appropriate for engineering data that can no longer rely on the prior protection scheme.