CVE-2025-40801: Siemens SALT Flaw Bypasses TLS Checking — What to Patch Now

Siemens on December 11, 2025 made public a dangerous oversight in its Advanced Licensing (SALT) Toolkit: the software fails to validate server certificates when establishing TLS connections, CVE-2025-40801, with a CVSS v4 severity of 9.2. The vulnerability exposes a broad swath of engineering applications—from NX and Simcenter 3D to Tecnomatix Plant Simulation—to man-in-the-middle attacks that require no authentication and can be executed with low complexity. While patches are rolling out for some product lines, several critical tools have no fix available yet, forcing IT and security teams to rely on network controls to bridge the gap.

The Flaw: TLS That Isn’t Really TLS

At the heart of the issue is a failure of the SALT SDK to perform basic certificate validation. When a client built with the affected SDK connects to a Siemens authorization server over HTTPS, it should verify the server’s certificate chain, check hostname matching, and enforce trust anchors. Instead, the SDK accepts any certificate an attacker presents, turning what should be an encrypted, authenticated channel into one that can be silently intercepted and manipulated.

This is classic improper certificate validation (CWE-295). An attacker who can position themselves between the client and the license server—via a compromised network segment, rogue Wi-Fi, or even a malicious proxy—can eavesdrop on license requests, modify responses, or inject false data. The attack does not require cracking encryption or guessing passwords; presenting a self-signed or spoofed certificate is enough. The prerequisites are minimal: network access that allows traffic interception or redirection, and the ability to generate a certificate. No special hardware or advanced cryptanalysis is needed.

Siemens’ advisory lists the following affected products and their remediation status:

The table makes clear the uneven remediation landscape. Products like Simcenter Studio and COMOS V10.6 remain vulnerable with no vendor-supplied fix, while others have specific version thresholds that admins must cross.

What’s at Stake for Windows-Centric Engineering Environments

If your organization runs Siemens CAD, CAE, or PLM tools on Windows workstations, the risk goes beyond a simple licensing disruption. Engineering workstations are treasure troves of intellectual property, and they often sit at the crossroads of corporate IT and operational technology networks. A successful MitM attack against license traffic could:

• Expose sensitive metadata: License exchanges frequently include hostnames, project identifiers, and user contexts that aid attackers in mapping your environment. This reconnaissance can feed more sophisticated intrusions.
• Disrupt operations: Manipulating license responses can deny access to critical tools, halting design work and cascading into production delays. In manufacturing settings, that downtime carries direct financial consequences.
• Provide a beachhead: Intercepted sessions might be leveraged to probe other services or pivot deeper into the network if the attacker can reuse the compromised context. Because the connection appears normal—TLS is still established, just with a rogue certificate—traditional firewalls and IDS/IPS may not flag the activity.

For Windows administrators, the urgency is compounded by the fact that the flawed SALT SDK runs in user mode on these machines. Traditional endpoint defenses may not inspect TLS traffic that appears normal on the surface. Anomaly detection requires deep packet inspection or host-based monitoring that looks for unexpected CA issuers or mismatched server names. Without such visibility, an attack can go unnoticed indefinitely.

Consider a mid-sized automotive supplier: dozens of NX workstations and a Simcenter 3D license server all use SALT. An attacker on the same VLAN—perhaps after compromising a weakly secured printer or IoT device—can ARP-spoof the license server’s IP and present a certificate signed by an untrusted root. The clients accept it silently, and the attacker now sees every license checkout, learns the hostnames of every engineering machine, and can selectively deny licenses to disrupt a critical design milestone.

How a Licensing Toolkit Became a Single Point of Failure

The SALT Toolkit is a shared library embedded across dozens of Siemens products. It handles license activation, validation, and entitlement enforcement. The decision to use one common SDK made sense from a development standpoint, but it also created a systemic risk: a single coding error in certificate handling now jeopardizes the security of many independent applications.

This is not the first time that certificate validation bugs have slipped into industrial software, but the high CVSS score and the network-facing nature of the flaw set this apart. Siemens disclosed the vulnerability through its ProductCERT, and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) republished the advisory as ICSA-25-345-05. However, since early 2023, CISA has ceased updating such advisories beyond the initial release, so for the most current patch information, organizations must monitor Siemens’ own advisory SSA-710408 directly. This shift places the onus on customers to proactively check Siemens’ portal rather than relying on federal push updates.

The vulnerability’s root cause is simple but severe: the SALT SDK’s TLS client implementation omits server certificate validation entirely. There is no evidence that this was exploited in the wild before disclosure, but once a vulnerability becomes public, threat actors move quickly to weaponize it. The long tail of products without fixes only increases the window of exposure.

What You Must Do Now

1. Inventory Every Instance of Affected Software

Create an accurate asset list of all Siemens products that might embed SALT. This includes not just obvious CAD clients but also less-visible components like JT translators, PLM integrations, and dedicated license servers. Record exact version and build numbers—the vendor’s remediation thresholds are precise. Siemens provides CSAF (Common Security Advisory Framework) files that can be ingested by vulnerability scanners to automate this matching.

2. Patch All Products That Have Fixes

For NX, Simcenter 3D, Femap, and Plant Simulation, apply the fixed versions immediately after standard testing. Note that some fixes require moving to new major or minor releases, so plan for compatibility testing with any plugins or custom scripts. Verify post-patch that the SDK libraries have been updated as expected, using file versioning tools or checksum comparisons provided by Siemens.

3. Isolate Systems Where No Fix Is Available

For COMOS V10.6, Simcenter Studio, Simcenter System Architect, and JT Bi-Directional Translator, you cannot patch away the vulnerability today. Instead:
- Place the affected workstations and any associated license servers in a tightly controlled network segment with a dedicated VLAN.
- Use firewall rules to allow outbound license traffic only to known, trusted authorization endpoints. Block all other internet access from these hosts.
- Enforce strict ingress and egress filtering, and consider terminating TLS at a forward proxy that performs proper certificate validation before forwarding to the real server. This proxy can pin the expected certificate or enforce a minimum TLS version and cipher suite.
- If possible, use application-layer controls or local host firewall rules to limit which processes can initiate outbound TLS connections, blocking any unauthorized use of the SALT SDK.

4. Ramp Up Monitoring for Signs of Exploitation

Because the attack can proceed without breaking encryption, passive network detection that only looks for cleartext may miss it. Focus on:
- Alerting on any TLS sessions to known license server hostnames (from Siemens documentation) that present certificates signed by untrusted or unexpected CAs. Compare the certificate issuer and serial number against a known-good baseline.
- Monitoring for spikes in failed license requests or denials that correlate with network anomalies or changes in DNS resolution.
- Inspecting DNS queries for license server names; unexpected changes in resolved IPs can indicate traffic redirection via DNS poisoning or a malicious DHCP server.
- Using endpoint detection and response (EDR) tools to flag new network connections from engineering applications to unfamiliar external hosts, especially those on non-standard ports.

5. Prepare for a Lengthy Mitigation Period and Verify Regularly

Products with “no fix planned” may remain vulnerable for months or even years. Engineering teams often resist frequent software updates due to qualification requirements, so security leaders must negotiate a realistic, risk-based schedule. In the interim, compensating controls become your primary defense. Document these controls thoroughly, and set a recurring calendar reminder to check Siemens ProductCERT for any change in remediation status. The advisory SSA-710408 is the authoritative source for updates.

Outlook: An Uncomfortable Wait for a Complete Fix

CVE-2025-40801 is a painful reminder that shared SDKs demand an outsized share of vigilance from both vendors and customers. Siemens will need to issue patches for every affected product line, but history shows that can be a slow process when codebases diverge. For customers, the immediate priority is to shrink the attack surface through network hardening and continuous monitoring, while pressing Siemens for a complete remediation roadmap.

Organizations should also prepare contingency plans for long-term use of unpatchable software. This may involve migrating to alternative tools, isolating engineering networks even more aggressively, or deploying application-aware firewalls that can enforce certificate pinning at the network edge. The vulnerability exposes not just a technical flaw but a gap in many organizations’ software lifecycle management: third-party embedded components like SALT are often invisible until something breaks.

In the longer term, engineering software vendors must adopt rigorous certificate validation as a non-negotiable baseline, and enterprises should extend their vulnerability management programs to track embedded libraries across the entire software portfolio. For now, treat every unpatched SALT client as a potential listening post on your network—and act accordingly.