The affected CVEs are CVE-2026-69108, described as an incorrect permission assignment for a critical resource, and CVE-2026-69109, a path traversal issue. Both carry a CVSS v3 score of 7.5 in the Siemens advisory. Siemens says a newer Siemens License Server release is available and recommends updating to the latest version.
For Windows administrators, the practical risk is less about a workstation application crashing and more about a shared licensing host becoming an access-control weak point. Siemens License Server, or SLS, is used to distribute licenses for Siemens Advanced Licensing Technology deployments, including product families in EDA and PLM. A compromised server in that role can be an especially sensitive asset because it is often available to many engineering clients and may sit alongside valuable design data, build tools, or application servers.
The version language needs careful interpretation
The published advisory names two overlapping version ranges: SLS releases below 5.1 and releases below 5.3. It does not, in the CISA republication, plainly map each CVE to one of those thresholds or name the exact current fixed build.
That omission is important. An administrator who sees “below 5.1” and upgrades an older installation to 5.1 could still be exposed if the second issue requires version 5.3 or later. The operationally safe interpretation is straightforward: standardize on SLS 5.3 or a later Siemens-supported release, rather than treating 5.1 as a universal remediation target.
The advisory’s wording also means inventories based only on the phrase “Siemens license server” may be incomplete. Siemens uses several licensing systems across its portfolio, and this notice specifically concerns Siemens License Server (SLS), the SALT-based service. It is not a general notice for every Siemens licensing component, and it should not be assumed to cover Automation License Manager or unrelated FlexNet deployments without checking their own advisories.
Privilege elevation and file reads can become a host compromise problem
CVE-2026-69108 concerns permissions on a critical resource. Permission errors in a service environment are often more consequential than their label suggests: a low-privileged account may gain the ability to modify files, settings, or executable paths that a more privileged service account trusts. Siemens states that successful exploitation could elevate privileges.
CVE-2026-69109 is a path traversal flaw, a class of bug that can allow software to resolve file paths outside the intended directory structure. Siemens says this issue can allow arbitrary file reading. Depending on what the service account can access, that can expose configuration data, license material, application logs, service credentials, or other locally readable files.
The advisory does not say that either vulnerability has been exploited in the wild, and neither CVE is identified in the published notice as remotely exploitable without authentication. Those are meaningful limits on what can responsibly be claimed today. But the absence of an exploitation claim should not become a reason to leave a shared license server unpatched: privilege boundaries and filesystem permissions are core protections on Windows servers, particularly where engineering users access centralized services.
Generic network advice is not a substitute for the update
CISA repeats Siemens’ standard industrial-security recommendations: reduce internet exposure, place control-system and remote-device networks behind firewalls, separate them from business networks, and use secured remote-access methods where needed. Those measures are sensible, but the text is general defensive guidance rather than proof that these SLS flaws are exploitable over the network.
That distinction affects prioritization. Network segmentation can reduce the number of systems able to reach a license service, but it will not correct insecure resource permissions or a vulnerable file-path handling routine on the host. If an attacker already has a foothold on the SLS server, or can act through a trusted client or administrative workflow, perimeter controls alone may provide little protection.
Administrators should therefore approach the response in two tracks: patch the service, then verify its placement and privileges. The update addresses the disclosed defects; review work limits the damage if a future flaw, stolen credential, or lateral movement reaches the same system.
What Windows and engineering IT teams should check now
Start by identifying all hosts that run Siemens License Server and recording their installed SLS version. Do not rely only on the version of the CAD, EDA, or PLM client software pointing at the server; the affected component is the centralized licensing service. Organizations with separate development, test, lab, and production engineering environments should check each environment independently.
Before updating, capture the existing license-server configuration, service account, listener settings, and license files according to the organization’s approved backup process. Licensing changes can disrupt engineering workflows if clients cannot obtain entitlements after a service restart, so maintenance planning is warranted. That is a continuity concern, not a reason to defer remediation indefinitely.
After the update, validate both security and service function:
- Confirm the installed SLS release is version 5.3 or later, or the current later version Siemens designates as fixed for both CVE-2026-69108 and CVE-2026-69109.
- Verify that the licensing service starts under the intended account and that clients can request and return licenses normally.
- Review permissions on the SLS installation directory, service configuration, log directories, and any locations writable by ordinary engineering users.
- Restrict access to the license server to the client networks and administrative systems that genuinely require it, rather than exposing it broadly across a corporate network.
- Check endpoint telemetry for unexpected service-account activity, unusual reads of sensitive local files, or unapproved changes under the SLS program and configuration paths.
The permissions review deserves special attention. The earlier Siemens License Server advisory published in April 2025 also addressed privilege-escalation weaknesses in versions before SLS 4.3. A second permissions-related issue little more than a year later does not prove a continuing common root cause, but it does show why administrators should not assume that merely reaching a fixed version eliminates every risky local access-control decision made during installation or later maintenance.
The immediate target is a verified 5.3-or-later deployment
Siemens and CISA have provided the headline action—update SLS—but the republished advisory leaves two operational details insufficiently explicit: the exact latest fixed version and the per-CVE mapping for the 5.1 and 5.3 cutoffs. Until Siemens’ support portal supplies a clearer mapping, organizations should avoid stopping at 5.1 and use the latest supported 5.3-or-later release.
For enterprises whose engineering tools depend on centralized Siemens licensing, this is a server-maintenance task with security consequences. The useful completion criterion is not “the advisory was reviewed”; it is an inventory showing every SLS host on the fixed release, with service permissions checked and access limited to the systems that need licensing.