Siemens RUGGEDCOM Flaws: Block UDP Ports for Instant Mitigation, CISA Says

Industrial operators using Siemens RUGGEDCOM RST2428P switches can immediately protect their networks from two newly disclosed vulnerabilities by implementing a straightforward firewall rule, according to advisories from Siemens ProductCERT and the U.S. Cybersecurity and Infrastructure Security Agency (CISA). The vulnerabilities, tracked as CVE-2025-40802 and CVE-2025-40803, affect the SINEC OS components of the RUGGEDCOM RST2428P family and were first published by Siemens on September 9, 2025, with CISA republishing the advisory on September 11 as ICSA-25-254-04.

Both issues are rated low severity, with CVSS v3.1 scores of 3.1 and CVSS v4 scores of 2.3, and require an attacker to be on an adjacent network. However, the operational reality of industrial control systems (ICS) and critical manufacturing environments means that even low-score flaws can enable reconnaissance or cause disruptive denial-of-service (DoS) events. Siemens has not yet released firmware fixes, but the available workaround—blocking specific UDP ports used for discovery protocols—is simple and effective.

The Flaws at a Glance

The advisory specifically targets the Siemens RUGGEDCOM RST2428P (part number 6GK6242-6PA00), a ruggedized Ethernet switch widely deployed in industrial and critical infrastructure settings. All current firmware versions are affected. The vulnerabilities are:

• CVE-2025-40802: Uncontrolled Resource Consumption (CWE-400) — The device may suffer resource exhaustion when flooded with high volumes of query requests, leading to temporary DoS. The system recovers once the traffic stops.
• CVE-2025-40803: Exposure of Sensitive Information to an Unauthorized Actor (CWE-200) — An unauthenticated attacker on the same network segment can retrieve certain non-critical device information, such as model numbers, firmware versions, and enabled services.

Both vulnerabilities have an attack vector of “adjacent network” and high attack complexity, meaning an attacker must already have access to the local network segment—either directly or via a compromised hop. CISA emphasizes that there are currently no known public exploits and that the flaws are not remotely exploitable over the internet.

Technical Details: What the CVEs Mean

CVE-2025-40802 exploits the device’s discovery service handlers, which lack input rate limiting. By sending a barrage of UDP packets to ports used by protocols like Link Layer Discovery Protocol (LLDP), Discovery and Configuration Protocol (DCP), or Media Redundancy Protocol (MRP), an attacker can exhaust CPU, memory, or socket resources. The result is a temporary loss of management-plane functions such as device inventory, firmware updates, and logging. While the disruption is transient, repeated attacks could strain operational monitoring and slow incident response.

CVE-2025-40803 allows the leakage of device metadata via the same discovery ports. Although the exposed information is classified as non-critical, it provides valuable reconnaissance data. An attacker can fingerprint the device, determine firmware revision levels, and identify enabled services—all of which can be leveraged to craft targeted attacks or identify wider network weaknesses.

Siemens’ advisory (SSA-494539) identifies the specific UDP ports involved: port 34964 and one port randomly chosen from the ephemeral range 49152-65535 when discovery services are active. These ports are used for LLDP, DCP, MRP, and similar protocols. The CVSS vectors (v3.1: AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L for CVE-2025-40802 and AV:A/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N for CVE-2025-40803) confirm the adjacent-network requirement and high attack complexity.

Why Low-Severity Flaws Matter in OT

In enterprise IT, a CVSS 3.1 might be dismissed as trivial. But in operational technology (OT) environments, the calculus changes. A temporary DoS on a switch’s management plane can disrupt network monitoring, configuration backups, and firmware deployment—processes essential for maintaining uptime and security. Information disclosure, no matter how trivial, erodes the defense-in-depth model that industrial networks rely on. A reconnaissance step that seems benign could be the precursor to a more devastating attack.

Moreover, many OT networks still lack rigorous network segmentation. An attacker who gains access to a corporate IT network might pivot into the OT layer if management interfaces are reachable. By exploiting these vulnerabilities, even a low-skilled adversary could map the network and plan further infiltration. Community discussions on industrial security forums consistently flag that “low severity” is a dangerous label when availability is the primary security objective.

Mitigations: Block UDP Ports and Segment Networks

The primary workaround, recommended by both Siemens and CISA, is to block the UDP ports associated with discovery protocols unless they are explicitly required. The steps are:

1. Block UDP 34964 and UDP 49152-65535 at network firewalls or access control lists (ACLs) for all interfaces facing untrusted networks.
2. If discovery functions are needed for internal management, restrict access to trusted management subnets and hosts only.
3. Isolate RUGGEDCOM switches on a dedicated management VLAN, separate from IT and general user segments, and apply strict ACLs between these zones.

These changes can be implemented within hours and have low operational disruption if discovery is not being used externally. Siemens also recommends broader industrial security measures, such as configuring devices according to its operational guidelines and disabling unnecessary services.

Beyond the immediate port blocks, operators should deploy rate limiting on discovery traffic at the network edge, tune intrusion detection/prevention systems (IDS/IPS) to alert on UDP floods to these ports, and forward logs to a centralized SIEM for correlation. The following risk‑priority matrix offers a timeline for action:

Operational Playbook: Step-by-Step

For teams managing industrial control systems, a structured approach reduces risk while a permanent patch is awaited. Here is a concise checklist based on community‑tested practices:

• Inventory: Identify all RUGGEDCOM RST2428P units (6GK6242-6PA00) and record current firmware versions.
• Isolate: Move these devices into a dedicated management VLAN if not already done. Apply ACLs to block all traffic from non‑management segments.
• Block Ports: Deploy firewall rules to deny UDP 34964 and UDP 49152-65535 to the switches. Test that authorized management tools can still communicate over allowed ports (e.g., SSH, SNMP).
• Monitor: Create IDS/IPS signatures to detect spikes in UDP traffic on the identified discovery ports. Set thresholds for alerts.
• Plan Patching: Subscribe to Siemens ProductCERT notifications for SSA-494539 updates. Prepare a maintenance window to test and deploy firmware patches once released.
• Verify: After any changes, confirm that discovery protocols behave as expected if still required, and review logs for anomalous activity.
• Document: Update asset inventories, incident response playbooks, and network diagrams to reflect the new controls.

Detection and Monitoring Guidance

Even after applying mitigations, continuous monitoring is crucial. Indicators of possible exploitation include:

• Sudden increases in UDP traffic to switch management IPs on ports 34964 or 49152-65535.
• Repeated UDP requests from a single source IP within a short time window.
• Device logs showing service restarts or high resource utilization coinciding with discovery traffic bursts.

SIEM rules can be constructed to alert when packets per minute exceed a baseline, or when CPU load on managed switches spikes alongside high UDP activity. Tuning these rules is essential to avoid false positives from legitimate discovery operations between trusted systems.

Strategic Takeaways for OT Security

This advisory highlights several evolving trends in industrial cybersecurity. First, Siemens has consolidated vulnerability disclosure through its ProductCERT, and CISA now only republishes initial advisories without ongoing updates. OT operators must therefore monitor Siemens’ portal directly rather than relying solely on CISA for follow-up information. This shift demands a more proactive vendor patch management lifecycle.

Second, the low CVSS scores of these vulnerabilities could lull organizations into inaction. Yet, the operational impact—especially in environments where availability is paramount—can be severe. As security practitioners often note, the metric fails to capture the true risk in OT contexts; a brief outage or information leak can be the first domino in a chain of cascading failures.

Third, the required adjacent-network attack vector is not a significant barrier in many real-world OT deployments. Lax segmentation, flat networks, and remote access VPNs often provide pathways to the management plane. Adversaries who compromise a single workstation or wireless access point may find themselves on the same subnet as the switch.

Conclusion

The SSA-494539 advisory serves as a practical reminder that OT network hygiene is an ongoing discipline, not a one-time audit. Siemens and CISA have provided clear, immediately actionable guidance: block UDP discovery ports and harden network segmentation to neutralize two vulnerabilities while awaiting official patches. Industrial organizations should treat this as a prompt to sharpen their inventory management, monitor vendor security feeds, and enforce strict separation between IT and OT domains. The technical fix for these specific flaws will come; the organizational fix—embedding rapid, disciplined response into operational culture—is the lasting takeaway.