Siemens SALT TLS Flaw CVE-2025-40801: MitM Risk in Licensing Traffic

Siemens’ Advanced Licensing (SALT) Toolkit contains a high‑severity certificate‑validation flaw that can be exploited remotely to perform man‑in‑the‑middle (MitM) attacks against licensing/authorization traffic — the issue is tracked as CVE‑2025‑40801, has a CVSS v4 base score of 9.2, and stems from the SALT SDK failing to validate server certificates properly when creating TLS connections to Siemens’ authorization servers.

Background​

Siemens distributes licensing and entitlement services to many of its engineering and simulation products via the Advanced Licensing (SALT) Toolkit. The SALT SDK is embedded in multiple Siemens desktop and server products; when the SDK initiates TLS connections to an authorization server, it is expected to validate the server certificate chain and endpoints. In the affected SALT SDK builds that underlie the listed Siemens products, server certificate validation is missing or insufficient — allowing an attacker who can intercept or redirect traffic to present a spoofed certificate and decrypt or tamper with the licensing handshake. This is a classic improper certificate validation defect (CWE‑295) that converts encrypted channels into effective plaintext channels when exploited.
As CISA’s handling of Siemens advisories shifted in early 2023, Siemens’ ProductCERT now hosts the canonical, continuously updated advisories and remediation tables that operators must consult for fixed versions and CSAF packages. CISA republished an initial advisory but directs users to Siemens’ ProductCERT for follow‑on updates.

---

Executive summary of the SALT Toolkit finding​

• Vulnerability: Improper server certificate validation in the SALT SDK’s TLS client implementation.
• Identifier: CVE‑2025‑40801 (assigned).
• Impact: Remote unauthenticated attacker could perform MitM, intercept license/authorization traffic, and potentially eavesdrop, manipulate license responses, or use the channel as a pivot to reconnaissance on engineering workstations and license servers.
• Severity: CVSS v4: 9.2 (high/critical); CVSS v3.1 was also calculated and published by vendor channels.
• Affected products (selected): Numerous Siemens products that embed SALT, including COMOS, NX, Simcenter variants, Tecnomatix Plant Simulation, JT Bi‑Directional Translator for STEP and more — with product‑specific version thresholds noted by Siemens. For some product families no fix is planned or currently available. Refer to the vendor ProductCERT advisory for per‑SKU version tables.

This combination — a networking/TLS defect in a library used across many engineering products — is particularly urgent because engineering workstations and license servers often sit on networks that bridge IT and OT, and because licensing protocols commonly carry metadata useful to adversaries (project names, hostnames, telemetry) beyond strictly "license tokens."

---

Technical details and attack model​

How the bug works​

When a SALT client establishes an HTTPS/TLS session to the authorization server, it should do the following checks as minimum:

• Verify the certificate chain up to a trusted CA.
• Verify the server certificate’s subject/subjectAltName against the expected hostname (name validation).
• Enforce certificate validity periods, revocation status (CRL/OCSP where used), and any pinning or extension constraints required by Siemens’ protocol.

The SALT SDK builds implicated by Siemens' advisory omit proper server‑side certificate validation during that handshake. As a result, an attacker who can intercept (on‑path) or redirect traffic — for example, via local network access, compromised VPNs, rogue Wi‑Fi, misconfigured proxies, or compromised gateways — can present a crafted certificate that the client accepts. The client will then proceed with the licensing exchange, revealing license tokens or telemetry and accepting any manipulated license responses the attacker injects.

Exploitation prerequisites and practicality​

• Network position: The attacker must be in a position to intercept or redirect license traffic. This can be achieved via local network access (same VLAN/subnet), a compromised remote access gateway, an attacker‑controlled Wi‑Fi, or by luring clients to an attacker‑controlled proxy.
• No authentication required: The SALT SDK flaw is exploitable without credentials (PR:N in CVSS). That makes the defect more dangerous than a credentials‑gated issue.
• Low attack complexity: The attacker need only present a spoofed certificate that the client accepts; the exploit does not require advanced cryptanalysis or special hardware, which is reflected in the low attack complexity ratings.

What an attacker can do​

• Eavesdrop on license requests and responses (confidentiality loss).
• Manipulate licensing replies to deny or alter license grants, causing operational disruption on engineering clients (availability or business impact).
• Harvest metadata about engineering projects, license server hostnames, and client inventories for later targeting.
• Pivot into other engineering services if the attacker can reuse the session context or leverage subsequent protocol flows.

---

Affected products and remediation status (practical snapshot)​

Siemens lists several affected products in its advisory package; the SALT SDK is embedded across various desktop and server suites. Per vendor advisories, remediation status varies by product: some products have fixed versions available, others have no fix planned, and a few are marked ‘no fix currently available.’ These nuances are why Siemens’ ProductCERT remains the authoritative source for per‑product remediation. Organizations should consult that ProductCERT advisory and reference the CSAF delivered by Siemens for exact version mappings.
Operators should assume that any product embedding SALT prior to the fixed builds is impacted — inventory and version‑checking are essential first steps.

---

Why Windows administrators and engineering teams must treat this as a priority​

• SALT is present on Windows engineering workstations where CAD, CAE and PLM tools are used. Those workstations often have elevated access to intellectual property and build pipelines.
• License servers may run on Windows or Windows‑adjacent infrastructure that integrates with corporate networks and storage.
• OT/IT convergence: Engineering systems often bridge OT and corporate IT for collaboration, file sharing, and remote support; a MitM on license traffic can be a stepping stone into richer attack paths.
• Operational impact: Disruption of licensing can stall design and manufacturing work, causing downstream production delays and contractual penalties.

These operational and business impacts, combined with the high CVSS v4 score, make CVE‑2025‑40801 a high‑priority remediation target for both security and engineering teams.

---

Immediate, prioritized remediation checklist​

1. Inventory
   1. Catalog all instances of Siemens products in your environment that might embed SALT: CAD clients, simulation suites, PLM integrations, license servers, and build/CI systems.
   2. Record exact build strings and version numbers; vendor advisories map fixes to specific version thresholds.
2. Patch where vendor fixes exist
   1. For each product with a Siemens‑published patch that upgrades embedded SALT to a fixed SDK, schedule and apply the vendor update after standard testing in staging.
   2. Validate installed build strings post‑patch.
3. Compensating network controls (where patching is not yet possible)
   • Move license servers behind strict firewall rules and limit access to known, hardened management hosts.
   • Force license traffic across trusted network paths (dedicated TLS‑terminating proxies) and block unknown proxies.
   • Implement strict ACLs and VLAN segmentation to isolate engineering VLANs from less‑trusted network segments.
   • If possible, enforce mutual TLS or certificate pinning at network proxies that mediate license traffic.
4. Hardening client TLS posture
   • Where feasible, configure local TLS stacks and endpoint security policies to enforce certificate validation and CA trust stores; however, note that embedded SDKs may not respect system policies — vendor fixes are the true resolution.
   • Implement DNS‑based protections (e.g., DNSSEC/validated DNS resolvers) and limit split‑DNS exposures that could redirect license hostnames.
5. Monitoring and detection
   • Enable and monitor for abnormal license handshake behavior: sudden license‑denied spikes, unexpected license server hostnames, or telemetry/log entries indicating certificate warnings.
   • Capture TLS metadata (SNI, IP addresses) at network edges and alert on unexpected certificate chains or mismatched hostnames.
   • Monitor EDR/host logs for new processes or network connections from engineering tools to unknown endpoints.
6. Incident response and forensics
   • If MitM is suspected, preserve network captures of the license session and system images of affected clients for analysis.
   • Rotate any license tokens or API keys that might have been exposed, and coordinate with Siemens support to validate license integrity and potential tampering.
7. Communication and compliance
   • Inform engineering leadership and affected teams of potential service interruption during patch windows.
   • For regulated industries, log remediation steps and exposures as part of audit evidence.

---

Detection and hunting guidance (practical steps)​

• Look for TLS sessions from engineering clients to known license hostnames that present certificates signed by unknown CAs or self‑signed certs.
• Alert on any changes to the license server hostname, IP address, or SNI that are not recorded in asset inventories.
• Watch for spike patterns: repeated license requests with denied or altered responses, or license re‑negotiations that correlate with network anomalies.
• Use network IPS/IDS to detect suspicious TLS interception techniques or anomalous proxy behavior.
• If available, engage network packet brokers to capture full TLS flows (for offline analysis) when you detect anomalies.

---

Critical analysis — strengths, gaps, and operational risk​

Strengths in vendor and federal response​

• Siemens assigned a CVE and published a ProductCERT advisory that maps affected SKUs to remediation thresholds — the presence of CVE tracking and vendor fixes for some products is positive and enables prioritized remediation.
• CISA’s involvement and republication of Siemens advisories (initially) brings visibility into the ICS/OT community and reinforces general defensive measures such as network segmentation and minimizing exposure.

Notable weaknesses and risks​

• Patch gaps: Several Siemens product families embedding SALT may have “no fix planned” or “no fix yet,” leaving operators dependent on compensating controls. This creates sustained operational risk for environments that cannot upgrade or replace software quickly.
• Embedded SDK challenge: When an SDK is embedded across many independent product binaries, patching requires coordinated vendor releases and per‑product testing; this increases the time to remediation and magnifies the need for robust interim network controls.
• Detection blind spots: Because the vulnerability enables passive eavesdropping and active MitM that still completes a TLS handshake (with an attacker’s accepted certificate), some passive network detectors that only look for unencrypted traffic will miss exploitation. Robust certificate verification telemetry is necessary.
• Operational complexity: Engineering teams often resist frequent patch cycles due to qualification of toolchains (plugins, templates), which means security‑driven patching cycles must be reconciled with release and QA processes.

Residual risk after mitigations​

Even after applying vendor patches, risk remains until all embedded SALT instances across your environment have been updated and until any supply‑chain dependencies (third‑party plugins or CI images) are confirmed clean. Organizations must maintain continuous discovery and patch validation to avoid stale instances being exploited.

---

Detection playbook for suspected exploitation​

1. Immediately isolate impacted engineering VLANs and capture live network traffic for affected time windows.
2. Export TLS server certificates observed in license sessions and compare against vendor‑published CA fingerprints or expected server certificates.
3. Compare license server hostnames/IPs to asset inventory. Any mismatch warrants deeper investigation.
4. Validate client systems for signs of lateral movement or new persistence mechanisms.
5. Notify vendors (Siemens ProductCERT) and coordinate any forensic needs or indicators of compromise they can supply.

---

Practical hardening recommendations for long term resilience​

• Adopt a policy of centralized, documented TLS validation and certificate pinning for critical engineering endpoints where feasible.
• Enforce least‑privilege network segmentation: license servers and engineering workstations should exist in tightly controlled subnets with egress limited to approved endpoints.
• Elevate vulnerability management for embedded SDKs in procurement and patch cycles: require vendors to supply a clear remediations timeline for any shared runtime components (like SALT).
• Maintain an up‑to‑date asset inventory and automated version checks for engineering software to shorten the window from disclosure to mitigation.
• Test vendor patches in staged workflows and automate deployment to reduce manual QA delay.

---

Caveats and unverifiable claims​

• Vendor advisories showing “no planned fix” for certain products are subject to change as Siemens continues its ProductCERT cadence; organizations should treat such statements as time‑sensitive and re‑check ProductCERT for updates before finalizing long‑term mitigation plans.
• Public exploitation status can change rapidly. At the time of the vendor advisory publication there may have been no known public exploitation, but absence of evidence is not evidence of absence; defenders must assume adversaries will attempt to exploit publicly disclosed, high‑severity flaws rapidly.

---

Recommended prioritized action list (quick checklist)​

1. Inventory all Siemens products that embed SALT and capture exact version/build strings.
2. Cross‑check each product version against Siemens ProductCERT and the CSAF to identify fixed builds.
3. Patch to vendor‑recommended fixed builds where available and validate installs.
4. Where patching is delayed, implement network segmentation, firewall rules, and limit license server exposure to only essential hosts.
5. Enable monitoring for anomalous TLS certificates and unexpected license server endpoints.
6. Update incident response plans to include license‑server compromise scenarios and IP/asset containment playbooks.

---

Conclusion​

CVE‑2025‑40801 in Siemens’ SALT Toolkit is a high‑impact, network‑facing flaw because it undermines the very TLS checks that prevent MitM attacks. The combination of a high CVSS v4 score, the ubiquity of SALT across engineering products, and the often‑exposed network positions of license flows creates a high operational and security risk for organizations that rely on Siemens engineering software. Rapid inventory, patching where possible, strict network isolation, and telemetry‑driven detection are the concrete steps engineering, security, and Windows operations teams must take now. Rely on Siemens ProductCERT for the authoritative remediation mapping and treat any “no fix” guidance as temporary until the vendor supplies a final remediation path.

---

Implementing the measures above will materially reduce attack surface and detection latency; however, the underlying lesson is strategic: shared SDKs embedded across multiple product families require specialized lifecycle management and rapid cross‑product patch coordination to prevent a single library bug from becoming a systemic risk.

---

Source: CISA Siemens Advanced Licensing (SALT) Toolkit | CISA