Siemens controllers: why the Linux version matters
Current manufacturer advisories concern additional subsystems of certain SIMATIC devices. Swiss operators must check model, firmware and reachable interfaces — an advisory is not evidence of an attack.
The US cybersecurity agency CISA circulated a security advisory on 22 October 2026 about additional GNU/Linux systems in certain SIMATIC S7-1500 controllers. It is based on a Siemens document dated 13 October. Affected products include variants of the CPU 1518(F)-4 PN/DP MFP. The exact firmware version is decisive: the new advisory SSA-457936 covers version V3.1.7, while other documents refer to older versions. The model family alone does not reveal whether a given plant is affected.
For Swiss industrial companies, the first step is therefore a stocktake. An advisory about software gaps is not proof that a machine has already been manipulated. Nor does it show that the affected components are installed in a specific Swiss plant or are reachable from outside. Those questions must be answered by the people responsible on site.
The additional system is not the whole controller
The manufacturer explicitly describes the affected area as an additional GNU/Linux subsystem. That narrowing must not get lost in a headline. Anyone who derives a general failure of all S7-1500 controllers from it is mixing up different products, software versions and attack surfaces.
Timing also matters. The advisory SSA-398330 was originally published in December 2023 and last updated on 13 October 2026. It covers firmware from V3.1.0 and before V3.1.5. A new publication date therefore does not necessarily mean that every listed vulnerability has only just been discovered.
CISA labels its publication as a verbatim reproduction of the Siemens advisory. It is therefore not an independent second investigation. A separate CISA advisory addresses the additional GNU/Linux subsystem of the TM MFP V1.1.1. Its version details must not be transferred to the CPU variants.
For V3.1.5, Siemens now points to the end of maintenance for that version. A list of issues that is no longer updated is not an all-clear. For operators, the consequence is to clarify the lifecycle of the software in use together with the supplier, rather than merely comparing the number of recent advisories.
Prioritise instead of updating blindly
In the advisory for V3.1.7, Siemens states that further fixes are being prepared. As concrete risk mitigation, the manufacturer names running only applications from trusted sources and restricting access to the interactive Linux command line to trusted personnel. That is not a general clearance to keep operating under any conditions.
Assessments also need their yardstick: Siemens gives SSA-457936 a maximum base score of 10.0 under CVSS 3.1 and 8.7 under CVSS 4.0. These are different scoring systems. The two figures therefore do not show that the same situation has since been defused.
A sensible review links three levels: which component is present? Which vulnerability affects exactly that version? And what access conditions actually exist? Only from that does a robust priority emerge. A high technical severity alone describes neither the architecture of the operational network nor the consequences of a planned maintenance interruption.
Swiss recommendations begin with the inventory
In its protection recommendations, the Federal Office for Cybersecurity (BACS) requires a complete overview of industrial devices, upstream systems and endpoints. It adds a software inventory with systematic maintenance of updates and product lifecycles. Without that basis it remains unclear who is actually affected by a specific manufacturer advisory.
BACS also recommends separating industrial networks from office networks or isolating them with clear security zones. Administrative interfaces should not be reachable directly from the internet. For remote access, the authority names VPN and two-factor authentication. These measures do not replace fixing a vulnerability, but they can limit reachable attack paths.
Maintenance access in particular deserves attention. It is set up for a legitimate operational purpose but remains a security-relevant gateway. On remote access, BACS points among other things to stolen credentials and unsecured access points. Technical controls and clear organisational rules must therefore work together.
Preparation also includes a tested recovery. BACS recommends clear backup processes and restore tests at least every six months. Configurations should be backed up as well. An existing backup alone does not yet show that the correct plant configuration will be available again in time after an incident.
Plan availability and security together
For industrial environments, the federal SME portal stresses that the entire technical equipment, the firmware versions and the network connections must first be recorded. Segmentation and access restrictions follow after that. A mere list of installed office programs is not enough for this task.
In practice, operations, automation and IT should jointly record who assesses an advisory, who contacts the manufacturer and how a change is tested. A documented restart belongs in the same plan. That is how a general warning becomes a verifiable decision for one's own plant — without unsubstantiated alarm calls and without dangerous false reassurance.
Sources
- Siemens ProductCERT: SSA-457936 for firmware V3.1.7
- Siemens ProductCERT: SSA-398330 for older firmware versions
- Siemens ProductCERT: SSA-082556 for firmware V3.1.5
- CISA: ICSA-26-295-11, republication of 22 October 2026
- CISA: ICSA-26-295-16 for the TM MFP subsystem
- BACS: measures for protecting industrial control systems
- BACS: secure handling of remote access
- Federal SME portal: protecting the industrial environment
