Siemens flags hundreds of Linux flaws in its S7-1500 MFP factory controllers

Key points

• Siemens has disclosed hundreds of vulnerabilities in the Linux subsystem bundled with firmware version 3.1.6 of its SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP industrial controllers.
• The advisory covers two hardware variants, part numbers 6ES7518-4AX00-1AB0 and 6ES7518-4AX00-1AC0, plus the ruggedised SIPLUS versions.
• The CVE list spans from CVE-2021-41617 in OpenSSH through kernel and userspace bugs dated 2023, 2024, 2025 and 2026.
• Siemens says fixed firmware is in preparation and is recommending interim mitigations for operators who cannot wait.
• The controllers are used on factory floors, in water and energy plants, and in other industrial sites where an outage means real-world disruption.

Siemens has published a security advisory admitting that firmware version 3.1.6 of its SIMATIC S7-1500 CPU 1518(F)-4 PN/DP MFP, a high-end industrial controller used to run factory lines and plant equipment, ships with a Linux operating system carrying more than three hundred known security flaws.

The MFP in the product name stands for Multifunctional Platform. In plain terms, it is a programmable logic controller (a small industrial computer that opens valves, spins motors and runs production lines) with a second Linux environment tacked on so customers can run their own applications alongside the control logic.

That Linux side is where the problem lives.

What is actually broken?

The short answer: the Linux distribution baked into the firmware is old, and it carries every publicly known bug that comes with being old. Siemens lists CVEs (unique identifiers for individual software flaws) stretching from 2021 to 2026, including a long-standing information leak in OpenSSH tracked as CVE-2021-41617 and a large batch of Linux kernel issues from the 2024 and 2025 stable trees.

Most of these are not novel zero-days. They are the routine drip of kernel, sshd, glibc and userspace fixes that a normal server would pick up through weekly package updates. In practice, a PLC firmware image does not get weekly updates. It gets one image, signed, tested, and shipped, and then it sits on a factory floor for years.

The failure mode here is the industrial patch cycle colliding with the general-purpose Linux patch cycle. They are not compatible.

Who runs these things?

The 1518 MFP is a top-of-range Siemens controller. You find it in car plants, food and beverage production, pharmaceutical lines, and utilities. The SIPLUS variants listed in the advisory, first noted in coverage from the CISA Cybersecurity Advisories feed, are hardened versions built for harsh conditions like extreme cold or vibration, typically deployed in outdoor infrastructure.

In other words, real production, not lab gear.

Can an attacker actually reach it?

That depends entirely on how the site is wired. A controller sitting on a properly segmented operational network, with no direct internet exposure and strict access to the engineering workstation, is a hard target regardless of what CVEs its Linux side carries. A controller reachable from the corporate IT network, or worse from the internet through a misconfigured remote-access box, is a soft one.

Most of the listed flaws require some form of local access or an authenticated foothold to exploit. The concern is not one magic remote code execution bug. The concern is that once an attacker gets any position on that Linux subsystem, they have a shopping list of privilege escalations and kernel bugs to pick from.

What should operators do now?

Siemens is telling customers to follow its standard operational guidelines for industrial security: put controllers behind a firewall, restrict who can talk to them, and only allow the engineering tools that need to. That is the same advice Siemens has given for a decade. It works when it is actually implemented.

One thing the post-mortem will say, whenever the first real incident lands on one of these boxes, is that the CVEs were public for years and the controller was reachable from a network it should not have been on.

Operational takeaway: if you run 1518 MFPs, treat the Linux side as untrusted until the fixed firmware ships, and audit exactly who and what can currently open a socket to it.