Siemens SIMATIC S7-1500 MFP V3.1.6: No Fix for CVSS 9.8 Flaws

Siemens has disclosed a high-severity vulnerability collection affecting the additional GNU/Linux subsystem in firmware V3.1.6 for its SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP multifunctional controllers, including a SIPLUS variant. The advisory carries a maximum CVSS v3.1 base score of 9.8 and a CVSS v4.0 base score of 8.7; more importantly for plant operators, Siemens lists the affected V3.1.6-and-later products as having no fix currently available and instead directs customers toward containment measures. Siemens ProductCERT’s SSA-019113 advisory

Overview: a Linux security issue inside a high-end industrial controller​

The affected hardware is not an ordinary PLC in the narrow, traditional sense. Siemens positions the CPU 1518(F)-4 PN/DP MFP as a multifunctional platform that combines programmable-logic-controller duties with PC-like workloads. Its defining feature is the ability to execute C/C++ applications alongside the normal STEP 7 automation program, using an additional runtime environment. Siemens’ CPU 1518-4 PN/DP MFP equipment manual
That convergence is useful. It allows manufacturers to place demanding algorithms, application-specific services, database connections, data preprocessing, and reusable C/C++ intellectual property closer to the machine rather than splitting work across a PLC, an industrial PC, and external middleware. Siemens documentation explicitly identifies database connectivity, complex data preparation, and process-optimization algorithms among the MFP platform’s intended use cases. Siemens’ CPU 1518-4 PN/DP MFP equipment manual
It also changes the security equation. The controller’s extra GNU/Linux environment introduces a substantial software-component footprint beside the deterministic control program. A vulnerability advisory that spans hundreds of CVEs in that environment should therefore be treated as a platform exposure-management event, not as a single bug with a single exploit path.
For Windows administrators who manage engineering stations, OT jump hosts, historian infrastructure, or domain services connected to factory networks, the practical message is equally clear: this is a controller issue, but it must be addressed through the whole Windows-to-OT access chain. Engineering workstations, remote-access servers, software repositories, backup systems, privileged accounts, and network segmentation all influence whether the vulnerable Linux subsystem can be reached or misused.

---

Which SIMATIC controllers are affected?​

Siemens states that all versions at or above V3.1.6 are affected for the listed MFP models. The advisory covers standard, fail-safe, bundle, and SIPLUS product references rather than a single catalog number. Siemens ProductCERT’s SSA-019113 advisory
The affected products are:

• SIMATIC S7-1500 CPU 1518-4 PN/DP MFP
• 6ES7518-4AX00-1AB0
• 6ES7518-4AX00-1AC0
• SIMATIC S7-1500 CPU 1518F-4 PN/DP MFP
• 6ES7518-4FX00-1AB0
• 6ES7518-4FX00-1AC0
• SIPLUS S7-1500 CPU 1518-4 PN/DP MFP
• 6AG1518-4AX00-4AC0

The F designation matters. In Siemens terminology, the 1518F is a fail-safe model used in applications where automation logic may participate in safety functions. That does not mean the advisory describes a direct bypass of safety functions; it means security remediation and operational testing require a more cautious change-management process because availability, diagnostics, and maintenance actions can have broader consequences in safety-relevant production environments.
The bundle variant deserves attention as well. Siemens lists the 6ES7518-4AX00-1AC0 package as including the C/C++ Runtime and OPC UA Runtime licensing, with PROFINET and PROFIBUS interfaces on the controller. Siemens Industry Mall product listing That combination illustrates why an inventory based only on the label “PLC” is insufficient: an MFP CPU can be a controller, an application-runtime host, an industrial communications endpoint, and an OPC UA participant at the same time.

The version boundary is unusually important​

The current Siemens notice is specifically titled for V3.1.6. It should not be conflated with the prior V3.1.5 advisory, even though both concern the additional GNU/Linux subsystem on the same family of MFP controllers. Siemens’ older advisory explicitly directs customers using V3.1.6 to the newer SSA-019113 notice. Siemens ProductCERT’s SSA-082556 advisory
That distinction matters operationally. A team that previously performed a V3.1.5 remediation review cannot assume that its older worksheet, risk acceptance, compensating controls, or planned firmware action applies unchanged to V3.1.6. Firmware lifecycle decisions must be tied to the precise installed version, the exact MLFB/catalog number, enabled runtimes, and the controller’s real network exposure.

---

Why the CVE list is so large​

The advisory contains a very large set of vulnerabilities drawn from the GNU/Linux subsystem and its included components. The breadth of the list is striking, but it should not be interpreted as hundreds of identical remotely exploitable flaws against the PLC control plane.
Instead, the affected set includes a mix of vulnerability classes and attack preconditions, including:

• Improper input validation
• Out-of-bounds reads and writes
• Use-after-free and double-free conditions
• NULL-pointer dereferences
• Race conditions and synchronization failures
• Privilege-management problems
• Information disclosure
• Buffer overflows and underflows
• Resource leaks and memory-management errors
• Authentication or authorization weaknesses
• Denial-of-service conditions

The advisory’s overall CVSS v3.1 score of 9.8 reflects the highest-severity finding in the aggregate set, not a promise that every listed CVE is equally easy to exploit in every factory. Siemens ProductCERT’s SSA-019113 advisory Siemens’ per-CVE entries show that impacts and attack vectors vary substantially: some flaws are network-reachable, while others require local access, specific privileges, unusual configurations, or interaction with a vulnerable component that may not be exposed in a given deployment. Siemens ProductCERT’s SSA-019113 advisory
That nuance is not a reason for complacency. It is a reason to prioritize properly.

A high score does not remove the need for architecture review​

In an enterprise IT environment, a CVSS 9.8 finding typically triggers emergency patching. In operational technology, simply applying the newest available update can carry material production risk. A controller firmware change may need compatibility testing with:

• STEP 7 and TIA Portal engineering versions
• Safety projects and safety signatures
• Distributed I/O and PROFINET device configurations
• OPC UA clients and certificates
• C/C++ runtime applications
• Recipe systems, HMIs, historians, and MES interfaces
• Maintenance procedures and rollback plans
• Site-specific production windows

The right conclusion is not “patch later because OT is fragile.” It is reduce exposure immediately while preparing a tested corrective action. Siemens says it is preparing fix versions, which makes interim controls central to the response. Siemens ProductCERT’s SSA-019113 advisory

---

The key risk: MFP flexibility expands the attack surface​

The MFP architecture is a strength precisely because it can run custom software close to machine operations. Siemens explains that existing C/C++ code can be integrated either into the CPU runtime environment or as C/C++ runtime applications on the SIMATIC S7-1500 MFP C/C++ runtime. Siemens’ CPU 1518-4 PN/DP MFP equipment manual
However, flexibility has a corresponding security cost. Every custom runtime application introduces questions that conventional PLC programs may not raise as sharply:

• Who built the application, and from which source repository?
• Which compiler, library versions, and dependencies were used?
• Is the binary signed, versioned, and attributable to an approved release?
• Who can deploy, replace, start, or stop it?
• Can an external maintainer reach the runtime through an interactive shell?
• Are C/C++ runtime interfaces bridged to higher-level IT services?
• Does the application communicate with databases, web services, OPC UA clients, or other networked endpoints?

This advisory is therefore especially significant for plants that treat the Linux subsystem as a convenient extension point without granting it the same governance applied to an industrial PC or server. An MFP controller may sit in a locked cabinet, but its runtime environment remains part of a living software supply chain.

Treat interactive shell access as privileged OT administration​

Siemens’ specific mitigations are direct: customers should build and run applications only from trusted sources and should limit interactive-shell access to the additional GNU/Linux subsystem to trusted personnel only. Siemens ProductCERT’s SSA-019113 advisory
Those two statements should be translated into enforceable policy, not left as general guidance. “Trusted personnel” should mean individually attributable identities, role-limited authorization, controlled remote access, approval records, session logging where feasible, and periodic access reviews. Shared maintenance credentials, undocumented contractor accounts, and permanently enabled remote support paths are all incompatible with a disciplined response.

---

Immediate actions for industrial security teams​

A practical response begins with discovery. Many organizations know they have S7-1500 controllers but cannot immediately identify which ones are MFP models, which firmware they run, or whether the C/C++ runtime is actively used.

1. Build a precise asset list​

Create or update an inventory that records more than the controller family name. At minimum, capture:

• Device hostname and IP address
• Physical location, production cell, and process owner
• Exact MLFB/order number
• Firmware version
• Whether it is a standard, fail-safe, or SIPLUS model
• Whether the C/C++ runtime is installed and in use
• Known runtime applications and their owners
• Enabled network interfaces and connected zones
• Remote-access paths
• Engineering workstation and TIA Portal dependencies
• Backup, recovery, and rollback status

The product reference alone is not enough. A CPU 1518 MFP used solely for local control in a tightly segmented cell presents a different risk profile from one that hosts custom C/C++ code, provides OPC UA data to enterprise systems, and is reachable through a remote support gateway.

2. Verify the actual firmware level​

Confirm the controller firmware from authoritative configuration or device-management records rather than relying on procurement dates. Siemens defines the affected version range as V3.1.6 and later for the listed products. Siemens ProductCERT’s SSA-019113 advisory
This is also the point to eliminate a common documentation error: do not mark devices as unaffected simply because an earlier V3.1.5 advisory was reviewed or because the PLC program itself has not changed. The vulnerability scope is tied to device firmware and the additional GNU/Linux subsystem, not solely to the STEP 7 automation project.

3. Identify whether the Linux environment is reachable​

Risk is shaped by access paths. Review every route through which a user, workstation, service, or network can communicate with the controller or its runtime environment.
Pay particular attention to:

• Engineering LANs that are also reachable from corporate Windows networks
• Dual-homed workstations and unmanaged USB-to-Ethernet adapters
• VPN connections that land directly in OT segments
• Remote vendor access
• Jump servers with broad network permissions
• Firewall rules allowing broad any-to-any engineering traffic
• OPC UA or other application data flows crossing zone boundaries
• Wireless maintenance networks
• Temporary commissioning connections that became permanent

A controller should not be Internet-exposed, and the MFP runtime should not be treated as a general-purpose Linux host accessible from broad enterprise networks. Network reachability frequently determines whether a theoretical vulnerability becomes an urgent operational threat.

4. Restrict the shell and custom-code pipeline​

Because Siemens specifically highlights shell access and trusted application sources, organizations should make these controls measurable:

1. Disable or restrict interactive access unless a documented operational requirement exists.
2. Remove dormant accounts and review third-party access.
3. Route remote administration through a controlled jump host.
4. Require multifactor authentication for remote pathways where the architecture supports it.
5. Separate application build environments from production deployment systems.
6. Preserve hashes, version numbers, approvals, and provenance for approved runtime binaries.
7. Prohibit ad hoc binaries copied from laptops, removable media, personal repositories, or unverified vendor packages.
8. Maintain a rollback package for every deployed runtime application.

This is both a vulnerability mitigation and a resilience improvement. If the organization cannot identify what code runs on an MFP controller, it cannot credibly assess the exposure created by either a Linux CVE or a compromised engineering endpoint.

---

The Windows administration connection​

The Siemens CPU itself does not run Windows, but Windows infrastructure often determines the real security posture of an industrial cell. Engineering stations commonly host TIA Portal, programming utilities, project archives, certificates, drivers, VPN clients, and remote-support software. Those systems can become the bridge between an attacker and an otherwise segmented controller.

Harden engineering workstations as Tier 0-style OT assets​

A Windows engineering workstation should not be managed like a standard office PC. It needs a more restrictive operational model:

• Use dedicated devices for PLC engineering rather than daily email, web browsing, and collaboration.
• Enforce least privilege for local administrators and project deployment accounts.
• Control USB storage and removable media.
• Apply endpoint protection that is validated for OT engineering workloads.
• Keep Windows, TIA Portal components, VPN software, and remote-management tools patched under tested maintenance processes.
• Maintain tamper-resistant backups of projects, runtime artifacts, certificates, and device configurations.
• Monitor privileged remote sessions and unexpected use of engineering tools.

The controller’s additional Linux subsystem can be a target, but so can the Windows workstation that compiles, deploys, or administers applications for it. The latter may offer attackers a more familiar entry point.

Avoid giving “trusted” status to an entire Windows domain​

Siemens’ advice to run applications from trusted sources should be read narrowly. A binary is not automatically trusted merely because it originated from a domain-joined system, a file share, or a vendor laptop. Trust should flow from a controlled build and release process that answers:

• Which source revision produced this application?
• Which person or team approved it?
• Which compiler and dependencies were used?
• Has the artifact changed since validation?
• Is the application authorized for this particular controller and production cell?

That approach brings software-supply-chain discipline to custom industrial applications without demanding that every plant become a full-scale software company.

---

Strengths in Siemens’ response—and the remaining gaps​

Siemens’ advisory is strong in several important respects. It clearly names the affected firmware version, identifies specific catalog references, acknowledges the affected SIPLUS product, supplies a large CVE mapping, provides aggregate CVSS scores, and makes no attempt to obscure the absence of a current fix. Siemens ProductCERT’s SSA-019113 advisory
The specific mitigations are also relevant to the affected architecture. Restricting the interactive shell and limiting code execution to trusted builds target the places where a multifunctional controller differs most sharply from a conventional PLC.
Yet several operational risks remain while fixes are pending.

Patch availability is not the same as patch deployability​

Even after Siemens releases remediation firmware, plant owners will need to validate it. The testing burden is likely to be heavier for systems using:

• Fail-safe CPU configurations
• Custom C/C++ applications
• OPC UA integration
• Tight motion or process timing requirements
• Third-party machine-builder support agreements
• Regulated manufacturing or critical production processes

Organizations should begin test planning now. Waiting for the firmware release before gathering controller backups, project versions, runtime inventories, test cases, acceptance criteria, maintenance windows, and rollback procedures adds avoidable delay.

CVE volume can produce alert fatigue​

A list of hundreds of CVEs can cause two opposite failures: panic-driven changes without impact analysis, or dismissal because the list appears too large to act upon. Neither response is appropriate.
A mature program should group exposure into operationally useful categories:
This framework prevents teams from treating every identifier as identical while still respecting the seriousness of the aggregate advisory.

---

A sensible remediation plan while Siemens prepares fixes​

Until updated firmware is available and validated, industrial operators should establish a formal interim plan rather than relying on a vague “monitor vendor updates” note.

Phase one: contain and document​

• Identify affected controllers and confirm firmware versions.
• Map their network exposure and remote-administration paths.
• Restrict shell access to named, approved personnel.
• Restrict deployment rights for C/C++ runtime applications.
• Remove unused access paths, stale accounts, and unneeded firewall rules.
• Confirm that device configurations and application artifacts are backed up.
• Record the business impact of a controller outage or runtime compromise.

Phase two: validate the production environment​

• Review which custom applications are executing in the MFP runtime.
• Establish ownership for each application and deployment package.
• Check engineering workstations and jump hosts for current patching and endpoint hardening.
• Validate segmentation between enterprise IT, engineering networks, and controller cells.
• Confirm monitoring coverage for remote access, firewall changes, and unusual administrative activity.
• Rehearse restoration of the CPU project and C/C++ runtime artifacts in a non-production environment where possible.

Phase three: prepare for the vendor fix​

• Subscribe to the relevant Siemens ProductCERT advisory updates.
• Obtain planned fixed firmware when Siemens makes it available.
• Confirm TIA Portal, hardware configuration, runtime applications, and safety-project compatibility.
• Test upgrades in a representative environment.
• Define success criteria that include control behavior, communications, diagnostics, runtime startup, and any OPC UA interaction.
• Schedule production deployment with operators, maintenance personnel, safety stakeholders, and vendors involved.
• Retain a rollback plan that is technically tested rather than merely documented.

Siemens also recommends protecting device network access with appropriate mechanisms and operating equipment in line with its industrial-security guidance and product documentation. Siemens ProductCERT’s SSA-019113 advisory That is sound guidance, but its effectiveness depends on translating it into specific firewall rules, identity controls, administrative procedures, and evidence that those controls work in the real plant.

---

Conclusion​

The SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP V3.1.6 vulnerabilities are a reminder that modern automation controllers increasingly combine deterministic control with richer compute environments. That evolution brings real performance and engineering benefits, especially for custom algorithms, data processing, C/C++ reuse, and integrated communications. It also makes Linux subsystem security, software provenance, shell access, and Windows engineering-station hygiene central parts of PLC risk management.
The most urgent fact is straightforward: Siemens currently lists the affected V3.1.6-and-later MFP products as having no available fix, while it prepares remediation versions. Siemens ProductCERT’s SSA-019113 advisory Organizations should therefore avoid both paralysis and rash change. The right response is immediate exposure reduction, tight control of interactive and application-deployment access, precise asset intelligence, protected OT network architecture, and a tested path to firmware remediation when it arrives.

---

References​

1. Primary source: CISA
   Published: 2026-07-28T12:00:00+00:00
   
   

   Siemens SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP | CISA

   www.cisa.gov
2. Related coverage: cert-portal.siemens.com
   
   SSA-019113
3. Related coverage: support.industry.siemens.com
   
   https://support.industry.siemens.com/cs/attachments/109749061/s71500_cpu1518_4_pndp_mfp_manual_en-US_en-US.pdf
4. Related coverage: cache.industry.siemens.com
   
   

   CPU 1518-4 PN/DP MFP (6ES7518-4AX00-1AB0)

   Equipment Manual

   cache.industry.siemens.com
5. Related coverage: press.siemens.com
   
   

   Multifunctional controller platform for automation | Press | Company | Siemens

   Siemens has expanded its Simatic S7-1500 Advanced Controller portfolio for more challenging applications to include a new type of multifunctional platf ...

   press.siemens.com
6. Related coverage: mall.industry.siemens.com
   
   Product Details - Industry Mall - Siemens Order Entry II