Siemens LOGO! Soft Comfort shipped one AES key for everyone: treat every project password as known

CISA has published advisory ICSA-26-225-13 on Siemens LOGO! Soft Comfort, describing two defects in how the engineering tool encrypts project files and stores project passwords ^[1]. Versions before V9 are affected, tracked as CVE-2026-57262 and CVE-2026-57263 ^[2], and the practical consequence is that the project password feature on those versions has never been a secret-keeping mechanism at all.

The first defect: affected versions encrypt project files with a static, hardcoded AES master key, and a local attacker can pull that key out of the application files or memory, then decrypt project files or strip the project password entirely without ever knowing what the password was ^[3]. A key that is static and compiled into the shipped application is the same key in every installation of the affected software, which means possessing a copy of the tool is equivalent to possessing the key ^[11].

The second defect: the project password is stored as an unsalted SHA-256 hash, so anyone holding a project file can run offline dictionary or brute-force attacks against it efficiently ^[4]. Unsalted SHA-256 is not a password store; it is a checksum. And cracking it does not just yield access to that one file, it yields the plaintext string, which matters wherever that string was reused ^[14].

Put the two together and the honest posture is not "patch and move on." Every project password ever set on an affected version should be treated as already known, because the key path defeats it without a guess and the hash path recovers it with one ^[12]. CISA frames the impact as unauthorized access to, or modification of, sensitive project logic and configurations ^[8]. Modification is the part worth sitting with: an attacker who can decrypt and re-save logic for a small logic module is editing control behaviour, not just reading it.

Siemens ProductCERT reported the issues to CISA itself ^[6]. The remediation is to update to V9 or later, with a caveat that operators should read twice: a hardware upgrade to a LOGO! V9 BM or later is also required, because in compatibility mode the vulnerabilities addressed by the advisory remain present ^[5]. So the software update alone does not close this on estates still running older base modules; it closes it only where the hardware moved too ^[13]. That is a procurement problem with a security label on it.

The advisory's standard hardening advice is the usual set: minimize network exposure, keep control systems off the internet, put them behind firewalls and isolate them from business networks, use VPNs for remote access while recognising VPNs carry their own exposure ^[9]. None of that addresses this bug class. Exploitation needs local access to the application or possession of the project file ^[3][4], and project files travel by email, contractor laptop, backup share and version control ^[15]. The advisory also carries no CVSS scores under either metrics heading as published ^[10], so severity triage falls to the operator.

Worth watching: whether Siemens or CISA publishes scores and any guidance on rotating passwords reused from LOGO! projects, and how the V9 BM hardware requirement lands in fleets where the base modules are a decade old. Affected sectors listed are Commercial Facilities and Transportation Systems, deployed worldwide ^[7]. Inventory first: find who still has pre-V9 project files, and assume their contents are readable.