Crafted FTP Command Can Knock Schneider Electric Modicon M340 Devices Offline

A network-reachable vulnerability in Schneider Electric Modicon M340 controllers and communication modules can make affected industrial devices unavailable after they receive a specially constructed FTP command.

The issue, which came to attention on September 21, 2026, is tracked as CVE-2025-6625. Schneider Electric and the US Cybersecurity and Infrastructure Security Agency classify it as an improper input validation flaw, mapped to CWE-20.

Successful exploitation causes a denial-of-service condition. The available advisories do not attribute remote code execution, data theft, control-logic modification, or direct compromise of safety systems to the vulnerability.

A network attack requiring no account or user action

CVE-2025-6625 carries a CVSS 3.1 score of 7.5, rated High. Its vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

That scoring describes an attack with several operationally significant properties:

• The vulnerable function is reachable over a network.
• Exploitation has low attack complexity.
• No authenticated or privileged account is required.
• No operator action is necessary.
• The reported impact is limited to availability.
• Confidentiality and integrity are not affected under the published assessment.

The defect concerns how the devices validate input received through FTP. An attacker can send a particular malformed command that the affected controller or module does not process safely, triggering the denial of service.

Neither Schneider Electric nor CISA has published the exact malicious FTP command in the available information. There are also no packet-level signatures, indicators of compromise, or device-recovery details that defenders can use as universal detection criteria.

Schneider Electric CPCERT reported the vulnerability to CISA. The agency’s industrial control systems advisory republishes information from Schneider Electric advisory SEVD-2025-224-05, which is available in CSAF and PDF formats.

Controllers and communication modules affected

The vulnerable equipment belongs to Schneider Electric’s Modicon M340 controller and communication ecosystem. It includes controllers as well as modules that connect industrial assets through Ethernet, Modbus TCP, IEC 60870-5-101/104, DNP3, and related protocols.

Affected products include:

• Modicon M340 PAC
• BMXNOR0200H, a Modicon M340 X80 Ethernet communication module for IEC 60870-5-101/104 and DNP3 deployments in severe environments
• BMXNGD0100, the M580 Global Data module
• BMXNOC0401, an X80 Ethernet module supporting Ethernet/IP and Modbus TCP through four RJ45 ports
• BMXNOE0100, a Modbus/TCP Ethernet Modicon M340 module
• BMXNOE0110, a Modbus/TCP Ethernet Modicon M340 FactoryCast module
• Associated Ethernet/Serial RTU modules
• Associated Modicon M340 X80 Ethernet Communication modules
• Modicon M340 controllers using vulnerable firmware generations

The affected-version information is not uniform across the product family:

Product or firmware branch	Affected versions
Ethernet/Serial RTU Module	vers:generic/<SV1.7_IR27
M580 Global Data module	vers:all/*
Ethernet/Serial RTU Module	vers:all/*
Modbus/TCP Ethernet Modicon M340 module	vers:intdot/<3.60
Modbus/TCP Ethernet Modicon M340 FactoryCast module	vers:intdot/<6.80
Modicon M340 firmware installed on M340 controllers	Versions before SV3.70
M340 X80 Ethernet Communication modules	All versions in the affected-products listing

The presence of both a version threshold and an “all versions” designation for Ethernet/Serial RTU modules means asset owners should not rely solely on a simple firmware comparison. Product identifiers, hardware models, firmware branches, and installed module types need to be matched against Schneider Electric’s product-specific advisory.

The status is described as “fixed, known affected,” but exact replacement releases are not specified for every listed product. Operators should consult SEVD-2025-224-05 before selecting an upgrade package.

Why availability loss matters in operational technology

A denial of service against a conventional IT service may interrupt access to an application. In an operational technology network, the unavailable component can be a controller or the communication module connecting that controller to engineering stations, supervisory platforms, remote devices, or process networks.

Depending on the installation, exploitation could interrupt control functions, telemetry, monitoring, or communications. The practical consequence will depend on the affected module’s role, network architecture, process design, and any redundant equipment already in place.

The products are deployed worldwide in chemical operations, commercial facilities, critical manufacturing, energy infrastructure, and water and wastewater environments. These sectors often operate equipment that cannot be restarted or upgraded without planned downtime.

The published assessment remains narrowly focused. It does not claim that an attacker can alter process logic, extract credentials, manipulate device data, or cross into a separate security authority. Availability is the documented risk.

No information is available indicating whether recovery requires a reboot, power cycle, module replacement, or another intervention. Organizations should therefore validate recovery procedures in a controlled environment rather than assuming that normal communications will return automatically.

Patching requires product-by-product verification

The primary corrective action is to install Schneider Electric’s applicable fix. Asset owners should first build an inventory of M340 controllers and connected communication modules, including exact model numbers and firmware revisions.

That inventory should then be compared with the vendor’s advisory. Particular attention is needed for product lines marked as affected in all versions and for modules whose version syntax differs from the controller firmware numbering.

Firmware changes in operational environments should follow an impact analysis and risk assessment. Operators may need to test compatibility with engineering tools, supervisory systems, communications peers, and process-specific configurations before deploying an update to production equipment.

Where maintenance constraints prevent immediate remediation, network controls can reduce the likelihood that an attacker reaches the vulnerable FTP functionality:

1. Remove direct internet access from controllers, communication modules, and associated engineering systems.
2. Segment control and safety networks from enterprise and other less trusted networks.
3. Restrict traffic to explicitly required hosts, services, and management paths.
4. Use maintained VPN infrastructure when remote access is operationally necessary.
5. Limit programming software to the network used by the intended industrial device.
6. Keep controllers in locked cabinets and avoid leaving them in Program mode.
7. Scan removable media before introducing it into isolated control environments.
8. Prevent unmanaged mobile devices from moving between external networks and control systems without sanitation.

These controls are compensating measures. They do not correct the defective input handling.

Defenders should inspect FTP exposure and anomalous failures

Because exploitation is delivered through FTP, defenders should determine where that service is enabled, which systems can reach it, and whether existing firewall rules permit unnecessary access. Internet-facing exposure should be removed, while internal access should be limited to known management or engineering hosts.

Monitoring should focus on unexpected FTP traffic to M340 controllers and affected modules, especially connections originating outside approved administration paths. Teams should also investigate unexplained device outages or communication loss that coincides with FTP sessions.

No specific malicious payload, source address, filename, or other indicator has been disclosed. Consequently, detection will need to rely on network baselines, service-access records, firewall telemetry, and device availability events rather than a published signature.

The available information does not establish that CVE-2025-6625 has been added to CISA’s Known Exploited Vulnerabilities catalog, and no KEV remediation deadline is known. Active exploitation has not been reported in the published material.

Organizations that identify suspected exploitation should preserve relevant network and device logs, follow their incident-response procedures, and report useful findings to CISA. Schneider Electric representatives and Industrial Cybersecurity Services can provide installation-specific assistance where the correct remediation path remains unclear.