Schneider M340 FTP DoS Flaw CVE-2025-6625: Patch, Mitigations, and OT Hardening

Schneider Electric has acknowledged a high-severity vulnerability in its Modicon M340 family and several M340 communication modules that can be triggered remotely by a specially crafted FTP command and may cause a denial-of-service condition; the flaw was assigned CVE‑2025‑6625 and carries a calculated CVSS v4 base score of 8.7 (high) with a CVSS v3.1 base score of 7.5, and Schneider has issued firmware updates for affected Modbus/TCP modules while recommending immediate network-level mitigations. (feedly.com, se.com)

Background​

The Modicon family of programmable logic controllers (PLCs) has long been a core platform for machine and process automation across manufacturing and energy sectors. The Modicon M340 is a mid-range PAC/PLC used in critical manufacturing, utilities, and distributed automation systems. Communication modules such as the BMXNOE0100 and BMXNOE0110 provide Modbus/TCP and FactoryCast/FTP connectivity—interfaces that allow engineering workstations and networked systems to exchange program and file data with the controller.
Industrial controllers like the M340 are typically long‑lived assets in operational technology (OT) environments; they are frequently subject to constraints on maintenance windows and change control that make timely patching more complicated than typical IT patch cycles. That long lifecycle, combined with wide deployment in critical infrastructure environments, means vulnerabilities in these devices require clear, conservative mitigations and fast, well-tested firmware updates.

What the vulnerability is (technical overview)​

CWE and trigger​

The issue is classified as an Improper Input Validation (CWE‑20) vulnerability that can be exploited by sending a specially crafted FTP command to the device’s FTP handler. If exploited, the device can experience a denial-of-service (DoS) condition—effectively causing the PLC or its communication module to stop servicing control traffic or accept configuration changes until it is recovered or rebooted. The vendor and public vulnerability records describe the attack vector as network‑accessible with low attack complexity, and no privileges or user interaction required.

Affected components​

Schneider’s advisory and public vulnerability trackers list these affected product categories:

• Modicon M340 processors — all versions (as reported in advisory material).
• BMXNOR0200H Ethernet/Serial RTU Module — all versions.
• BMXNGD0100 M580 Global Data module — all versions.
• BMXNOC0401 Modicon M340 X80 Ethernet communication modules — all versions.
• BMXNOE0100 Modbus/TCP Ethernet Modicon M340 module — versions prior to SV3.60.
• BMXNOE0110 Modbus/TCP Ethernet Modicon M340 FactoryCast module — versions prior to SV6.80.

Note: Schneider’s firmware release notes explicitly reference SV03.60 (BMXNOE0100) and SV06.80 (BMXNOE0110) as including fixes for vulnerabilities affecting the FTP/communication stack; those firmware builds and integrity verification artifacts are published on Schneider’s download pages.

How severe is this — scores and impact​

Two severity metrics are being referenced in public reporting:

• CVSS v3.1: a base score of 7.5, reflecting a high-severity, network‑accessible issue resulting in availability impact (denial-of-service).
• CVSS v4.0: a base score of 8.7, which shifts some weighting and results in a higher severity rating under the newer CVSS v4 model used in recent disclosures.

Operational impact centers on device availability and the risk of process disruption; because PLCs often control physical systems, DoS can translate directly into production outages, halted lines, or safety interlocks engaging. Public reporting to date does not indicate widespread, confirmed active exploitation of this specific CVE in the wild, but the attack vector—network‑accessible FTP—means exposed devices are at materially greater risk and should be treated as a priority for remediation. (cisa.gov, feedly.com)

---

Schneider’s fixes and vendor guidance​

Schneider Electric has published firmware updates for the two Modbus/TCP communication modules most directly named in the advisory:

• BMXNOE0100 — firmware SV03.60 includes the fix; download and integrity artifacts are posted on Schneider’s firmware download page. A reboot of the module/device is required to complete the firmware upgrade.
• BMXNOE0110 — firmware SV06.80 includes the fix; download and integrity artifacts are posted on the Schneider site. Reboot required.

For the other affected products (BMXNOR0200H, BMXNGD0100, BMXNOC0401 and the broader M340 family) Schneider is reportedly establishing remediation plans or has indicated additional mitigations until patches are available. Administrators should consult Schneider’s security notifications (SEVD advisories) relevant to their specific controller model for model‑specific release notes and recommended steps.
Schneider also notes that FTP is disabled by default on many devices; if FTP is not required in a given environment, it should remain disabled to reduce attack surface. When FTP is required for device deployments, the vendor recommends strict network controls and firmware hygiene.

Immediate mitigations (what to do now)​

The following actions are prioritized for any environment that uses Modicon M340 controllers or the listed communication modules. These steps combine vendor guidance and standard ICS best practices.

• Inventory and identify exposed devices:
• Use asset‑inventory tools to find all Modicon M340 processors and BMXNOE/BMXNOC/BMXNGD modules on the network.
• Confirm exact firmware/part numbers for each module; Schneider’s firmware pages identify current SV numbers.
• Patch where possible:
• Apply Schneider’s published firmware updates (BMXNOE0100 SV03.60, BMXNOE0110 SV06.80) in a controlled maintenance window. Follow vendor instructions for integrity verification and backup before applying firmware. Reboot is required after the update.
• Network isolation and filtering:
• Block FTP (TCP/21) ingress from untrusted networks using perimeter firewalls and local ACLs.
• Ensure PLC networks are not accessible from the internet. Put all OT devices behind segmented firewalls. This is consistent with CISA’s hardening guidance for control systems.
• Disable FTP if unused:
• If FTP is not a required feature for file transfers or engineering workflows, keep the service disabled; verify device configuration to ensure FTP is not inadvertently enabled during engineering tasks.
• Secure remote access:
• If remote access is necessary, require VPN tunnels with MFA and a limited, logged jump host. Restrict VPN endpoints to OT management stations only; ensure VPN firmware and software are current.
• Monitoring and detection:
• Add IDS/IPS signatures for anomalous FTP command patterns and watch for repeated malformed FTP commands or session anomalies. Correlate network logs and PLC telemetry for unexplained reboots or service interruptions.
• Operational readiness:
• Prepare rollback and recovery procedures, including configuration backups, offline copies of logic and program files, and a tested plan to restore operations in case a patch or reboot has unexpected side effects.

These mitigations are conservative and built to minimize operational impact while reducing exposure to exploit attempts. They reflect both Schneider’s vendor guidance and established ICS defense-in-depth patterns advocated by national cybersecurity authorities. (se.com, cisa.gov)

---

Step‑by‑step technical checklist for Windows‑based engineering environments​

Many engineering workstations and HMIs that interact with Modicon controllers run Windows. The WindowsForum audience should prioritize the following checklist to reduce their blast radius and secure the engineering stack that interfaces with affected controllers.

• Catalogue every engineering workstation and HMI that connects to the PLC network. Record Windows version, remote access tools, and installed Schneider software (EcoStruxure, SESU, Controller Assistant).
• Patch Windows and automation software (EcoStruxure/Controller Assistant) and update the Schneider device update utility to the latest version before installing PLC firmware.
• Limit workstation network interfaces: use dedicated NICs for OT connections and strict host‑based firewall rules to constrain which services are permitted to reach PLCs (block FTP unless explicitly required).
• Use an isolated, sanitized laptop for field engineering tasks; avoid bringing general corporate laptops into the OT zone. Scan and sandbox any files before they are used on OT workstations.
• Harden RDP/remote desktop usage: require VPN + MFA and limit RDP access to jump hosts only; log and retain session recordings where that is supported.
• Maintain offline backups of PLC program files and configuration artifacts; ensure the backups are protected with strong access controls and immutable storage where possible.

These steps protect the Windows side of the equation while also reducing the chance of a Windows compromise being used as a pivot to exploit PLC vulnerabilities.

---

Detection, logging, and threat hunting​

• Network telemetry: prioritize the capture and retention of flows (NetFlow/IPFIX), firewall logs, and IDS alerts for FTP control connections to known PLC IP ranges. Investigate any unexpected transfers or malformed FTP command sequences.
• Host telemetry: enable and collect Windows event logs and security logs from engineering workstations interacting with PLCs; watch for unusual use of FTP client tools or potentially obfuscated command-line invocations.
• Behavior baselines: implement baselining on control‑plane traffic to detect deviations such as unusual session lengths, repeated failed control commands, or binary data transfers that diverge from normal engineering file operations.
• IOC and YARA: while there may be no public proof‑of‑concept exploit code at disclosure time, maintain an internal watchlist of indicators from vendor releases and reputable vulnerability trackers.

---

Critical analysis — what Schneider and the industry did well, and where risk remains​

Strengths and positives​

• Coordination and fixes: Schneider issued firmware updates for the two most directly affected communication modules (BMXNOE0100 SV03.60 and BMXNOE0110 SV06.80) and published integrity verification material—this is essential for trust in OT firmware updates.
• Public advisories and guidance: National authorities and CERTs have published advisories and recommended mitigations that align with industry best practices (segmentation, blocking FTP, limiting remote access). This provides asset owners a transparent remediation path.

Remaining risks and operational realities​

• Rollout complexity in OT environments: PLC firmware upgrades often require scheduled downtime, test validation, and conservative change control—operators may not be able to upgrade all devices immediately, leaving windows of exposure. This is a systemic challenge.
• Unpatched units and unsupported devices: Several affected products were listed as “all versions” or as awaiting a remediation plan; until those updates are released and applied, organizations must rely on network controls, which are not foolproof.
• Attack surface via FTP: Even when FTP is disabled by default, some engineering workflows rely on FTP for program transfer or vendor tools; balancing operational needs and security controls is non‑trivial.
• Possibility of weaponized exploit code: Public disclosure of technical details plus availability of vulnerable devices can lead to quick development of exploit tooling. At disclosure time there were no widely reported in‑the‑wild exploits tied to this CVE, but that status can change quickly; monitoring and rapid patching are essential. (cisa.gov, feedly.com)

Caveat about public reporting: some data points (e.g., exact CVSS v4 weightings and temporal scoring) may be updated as maintainers reconcile metadata from multiple sources; where a public registry (NVD) lacks the most recent CVSS v4 metadata at the time of writing, independent vulnerability aggregators may provide the interim values—treat intermediary feeds as informative but confirm with authoritative vendor advisories and national CERTs when planning mitigation. (feedly.com, se.com)

---

Recommended remediation timeline (practical program)​

• Within 48 hours: inventory and isolation — identify every Modicon M340 and associated communication module (BMXNOE/BMXNOC/BMXNGD/BMXNOR) and isolate any unit that is internet‑accessible; block FTP inbound at the perimeter.
• Within 7 days: apply network mitigations — block TCP/21 from all but explicitly trusted management hosts, apply strict ACLs, and implement monitoring for malformed FTP sessions.
• Within 30 days: schedule firmware updates — plan vendor‑guided firmware upgrades for affected modules (BMXNOE0100 SV03.60, BMXNOE0110 SV06.80). Test in a lab or representative staging environment prior to production roll-out.
• Continuous: monitor threat intelligence feeds and vendor advisories for follow‑on fixes for modules still pending remediation and for indicators of active exploitation. (feedly.com, cisa.gov)

---

Final assessment and takeaways​

This vulnerability reinforces a few immutable truths for OT security teams:

• Defense-in-depth is essential: vendor patches are crucial, but network segmentation, service hardening, and strict remote access controls buy time and reduce exposure while patches are applied.
• Patch programs for ICS must be both deliberate and executable: operational realities require tested procedures, verified firmware integrity, and rollback plans. Schneider’s published integrity verification files for SV03.60/SV06.80 are useful artifacts for validation.
• Visibility and monitoring matter: malfunctions and DoS conditions may be the first sign of exploitation; robust telemetry and log retention improve incident response speed.
• Prioritization should be based on exposure and criticality: controllers that are reachable from less‑trusted networks or that mediate safety‑critical functions should be remediated and monitored first.

For Windows‑centric engineering teams: ensure your engineering workstations and HMIs do not become pivot points for attackers. Apply host hardening, isolate OT workstations from general IT traffic, and follow the vendor’s update instructions for both controller firmware and the supporting software that performs firmware management.
This vulnerability is serious because it is remotely reachable and has low complexity to attempt; however, the vendor has provided mitigations and firmware updates for key modules, and national advisories recommend a conservative, test‑first approach to firmware deployment combined with aggressive network controls. Treat this issue as a priority patch-and-control exercise: inventory, isolate, test firmware updates in a lab, schedule production updates, and maintain vigilant monitoring for anomalous FTP activity until all assets are confirmed remediated. (se.com, cisa.gov, feedly.com)

---

---

Source: CISA Schneider Electric Modicon M340 Controller and Communication Modules | CISA