Schneider Electric Modicon M340 Vulnerability Leaves Two Modules Without a Fix
Schneider Electric now offers fixes for four affected product lines, but the Schneider Electric Modicon M340 vulnerability still lacks patches for two communication modules. The September 17 CISA republication gives the flaw fresh visibility more than a year after its original disclosure.
Tracked as CVE-2025-6625, the vulnerability lets an unauthenticated network attacker send a specially crafted FTP command that can make an affected device unavailable. It carries a 7.5 CVSS v3.1 score and an 8.7 CVSS v4.0 score, both rated High.
This is not a newly discovered vulnerability. Schneider Electric first published its notification on August 12, 2025, then added controller and module fixes during 2026. CISA republished the fourth revision on September 17, creating a useful checkpoint for operators who may have treated the original mitigation as permanent.
The central tension is patch coverage versus operational exposure. Four product families now have designated fixed firmware, while BMXNGD0100 and BMXNOC0401 remain dependent on network controls. That split matters in industrial environments where upgrading one controller can involve testing, downtime approval, and coordination across several teams.
The CISA Notice Is a Republication, Not a New Disclosure
The immediate change is wider federal distribution of an existing advisory, combined with a clearer record of which products now have firmware fixes.
The September notice, ICSA-26-260-04, republishes Schneider Electric advisory SEVD-2025-224-05. CISA describes the publication as a direct conversion of the vendor’s Common Security Advisory Framework record. CSAF is a machine-readable format for distributing vulnerability, product, and remediation data.
That distinction prevents a misleading conclusion. The September notice does not establish that attackers began exploiting the flaw this month. It also does not reveal a new vulnerability affecting a different controller family.
The federal advisory traces four revisions:
August 12, 2025: Schneider Electric released the original notification.
April 14, 2026: The vendor added remediation for Modicon M340 controllers.
August 11, 2026: The vendor added remediation for the BMXNOR0200H module.
September 17, 2026: CISA republished the fourth revision.
The update history is central to understanding the story. The initial disclosure offered firmware fixes for the BMXNOE0100 and BMXNOE0110 modules, but other affected products relied on mitigations. Schneider Electric subsequently released fixes for the M340 controller firmware and BMXNOR0200H.
The resulting product map is more useful than a single severity label. It distinguishes equipment that can move to fixed firmware from equipment that still needs compensating controls.
The affected configurations are:
Modicon M340 controller firmware earlier than SV3.70.
BMXNOR0200H firmware earlier than SV1.7 IR27.
All versions of the BMXNGD0100 M580 Global Data module.
All versions of the BMXNOC0401 X80 Ethernet communication module.
BMXNOE0100 versions earlier than 3.60.
BMXNOE0110 versions earlier than 6.80.
Schneider Electric identifies SV3.70 as the fixed M340 controller firmware. It identifies SV1.7 IR27 for BMXNOR0200H, version 3.60 for BMXNOE0100, and version 6.80 for BMXNOE0110.
BMXNGD0100 and BMXNOC0401 remain the exceptions. The current structured advisory lists all versions of both modules as known affected and provides mitigations instead of a fixed release.
The advisory sometimes refers to “BMXNOC401” in its remediation text. The product inventory and Schneider Electric catalog identify the affected model as BMXNOC0401. Asset owners should validate the exact commercial reference rather than relying on a shortened name.
The CISA republication therefore changes visibility, not the underlying technical mechanism. Its value lies in resurfacing an advisory whose remediation status changed in stages.
For security teams, the practical question is whether their vulnerability record still reflects the 2025 response. A ticket closed after disabling FTP may now need to reopen because fixed firmware exists for part of the installed base.
How the Schneider Electric Modicon M340 Vulnerability Works
CVE-2025-6625 turns an exposed management service into a remote availability risk without requiring credentials or user interaction.
The underlying weakness is improper input validation, classified as CWE-20. Input validation checks whether incoming data follows the format and boundaries a device expects before the software processes it.
Schneider Electric says a specifically crafted FTP command can trigger denial of service. FTP, or File Transfer Protocol, is used to transfer files between networked systems. In an industrial controller environment, vendors may use it for functions such as configuration or firmware-related file handling.
The flaw is reachable over a network. The CVSS v3.1 vector assigns low attack complexity, requires no privileges, and requires no user interaction. Its rated impact is concentrated on availability rather than confidentiality or integrity.
The vulnerability record describes the same mechanism. An attacker does not need an authenticated operator to open a malicious file or approve a prompt. The attacker needs network reachability to the affected FTP service.
That does not mean every installed M340 device is equally exposed. Schneider Electric says FTP is disabled by default. A device with the service disabled and properly filtered at the network boundary presents a different attack path from one with port 21 reachable across a flat plant network.
However, default settings do not settle the question. Industrial systems often remain in service for years, and their configurations can diverge from the original baseline. Integrators may enable services for commissioning, maintenance, backups, or vendor support and leave them active afterward.
An asset owner therefore needs configuration evidence, not an assumption. The relevant checks include whether FTP is enabled, which interfaces can reach it, and whether network controls restrict port 21 to authorized management systems.
The weakness also spans several roles inside the Modicon architecture. It affects controller firmware, Ethernet communication modules, an RTU module, and the M580 Global Data module. A plant may have more than one affected component in the same control system.
That breadth complicates inventory work. A controller model alone does not reveal whether the rack includes an affected BMXNOC0401 or BMXNOE0110 module. Teams must identify firmware and module references at the component level.
The severity scores reinforce the need for that detail. CVSS v3.1 assigns a base score of 7.5. The updated CVSS v4.0 assessment reaches 8.7, with network accessibility and high availability impact driving the rating.
These scores describe technical severity under standardized assumptions. They do not calculate the operational consequence at a specific facility. Losing communication with a lab controller is not equivalent to losing communication with equipment tied to production or essential services.
The current advisory does not report data theft or manipulation as the direct outcome. It describes device unavailability. That narrower technical impact can still create a serious operational event when a controller or communication module supports a time-sensitive process.
The Schneider Electric Modicon M340 vulnerability is therefore best understood as a network-reachable availability flaw. Its real-world risk depends on service configuration, segmentation, firmware, and the process served by each device.
Partial Patch Coverage Creates the Real Operational Problem
The hardest part is not understanding the malicious command. It is managing a mixed fleet where some assets can be patched and others cannot.
Four affected product groups have a specified fixed release. Two do not. This divides the response into firmware remediation and compensating network controls.
For the Modicon M340 controller, Schneider Electric identifies SV3.70 as fixed. The vendor added that remediation in April 2026, about eight months after the original notification.
For BMXNOR0200H, SV1.7 IR27 contains the fix. That release entered the advisory in August 2026, almost a year after the initial disclosure.
The earlier BMXNOE fixes remain part of the response. BMXNOE0100 needs version 3.60, while BMXNOE0110 needs version 6.80. Schneider Electric says both upgrades require a reboot.
The vendor notification says failure to apply available fixes can leave devices at risk of denial of service and resulting unavailability. It also links the affected product families to Modicon M340, Modicon M580, and X80 modules.
A reboot requirement carries more weight in operational technology than it often does on an office endpoint. Restarting a communication module may interrupt monitoring, supervisory traffic, data exchange, or maintenance access.
An organization should not infer that this makes patching optional. It means the upgrade belongs inside an approved operational change process. That process should account for backups, compatibility, rollback, maintenance windows, and post-upgrade validation.
The two modules without fixed versions present a different decision. All BMXNGD0100 and BMXNOC0401 versions remain listed as affected. Schneider Electric says it is establishing a remediation plan for future versions and will update the document when remediation becomes available.
Until that happens, operators must treat configuration and network architecture as primary controls. The vendor recommends disabling FTP when it is not needed, segmenting the network, blocking unauthorized port 21 traffic, and using VPN tunnels for required remote access.
This split response can produce uneven risk inside one facility. A team might upgrade an M340 CPU but leave an affected communication module reachable. A dashboard may then show the controller as current while the rack still contains a vulnerable network path.
Procurement status can also obscure the issue. BMXNGD0100 is associated with the M580 product family, while BMXNOC0401 is an M340 X80 Ethernet module. A search limited to “M340 controller firmware” can miss both.
Asset records should therefore include at least the commercial reference, installed firmware, service state, network zone, and business owner. Without those fields, teams cannot reliably match the advisory to deployed equipment.
There is also a timing risk. Organizations that assessed the original 2025 notification may have recorded only the mitigations available at that moment. Later firmware releases do not automatically update internal exception records or maintenance plans.
This creates pressure on three groups. Security teams must reopen and normalize vulnerability records. Control engineers must test the corrected firmware. Operations leaders must authorize disruption where a reboot is necessary.
None of those groups can solve the issue alone. Security staff may know the CVE but not the production consequence. Engineers may understand the rack but lack complete exposure data. Operations staff may control downtime but not firmware validation.
The mixed remediation state is the main reason this republication matters. It converts an old “mitigate and monitor” response into a more precise task: patch four product groups and maintain strict controls around two others.
A High Score Does Not Prove Active Exploitation
The advisory supports urgent inventory and remediation, but it does not support claims of an ongoing attack campaign.
CISA’s structured record does not identify known exploitation in the wild. The vulnerability is also not presented as an entry in CISA’s Known Exploited Vulnerabilities catalog.
That absence should shape the reporting language. CVE-2025-6625 is exploitable under the conditions described by the vendor, but the advisory does not establish that attackers are currently targeting Modicon M340 installations with this technique.
The distinction matters because a severity score measures intrinsic technical characteristics. It does not measure how frequently a vulnerability is being scanned, weaponized, or used against a particular sector.
The CVSS v3.1 vector explains why the score is High. An attacker can reach the vulnerable service over a network, needs no privileges, faces low complexity, and requires no user interaction. Successful exploitation has high availability impact.
Those properties justify prompt action. They do not eliminate the need for environmental analysis.
Network position is the first variable. A properly segmented control network with unauthorized FTP traffic blocked provides fewer attack routes than a controller reachable from broad enterprise or remote-access networks.
Service state is the second variable. Schneider Electric says FTP is disabled by default. Operators should verify that state on each relevant asset and examine whether past maintenance procedures enabled the service.
Operational consequence is the third variable. A denial-of-service condition on a communication module may affect different functions depending on the rack design and process architecture. The public advisory does not calculate plant-specific safety or production outcomes.
Patch availability is the fourth variable. Four product groups have corrected releases, while two remain without fixes. A single organization can therefore have different residual risks for devices covered by the same CVE.
This is where the “High” label can both help and mislead. It attracts attention, but it can encourage a uniform response to a nonuniform product set.
The safer approach is to treat the severity score as a triage signal. Teams should then determine whether the affected component exists, whether its FTP service is reachable, and whether corrected firmware is available.
The weakness definition describes improper input validation as a broad software failure class. The classification does not reveal the exact command, failure state, or recovery behavior of every affected product.
Public information also does not provide a proof-of-concept exploit. That limits independent analysis of repeatability and device recovery. Organizations should avoid testing production controllers with malformed FTP traffic.
Schneider Electric’s legal notice says the notification and suggested actions are provided without a guarantee that they will resolve every situation. That standard disclaimer reinforces the need for site-specific testing rather than blind deployment.
A maintenance team should validate firmware on representative hardware where practical. It should confirm communications, application behavior, configuration retention, and restart recovery before scheduling a broader rollout.
For the unpatched modules, teams should validate the control path itself. A firewall rule is useful only if it covers every route to the device and remains enforced after network changes.
The skeptical conclusion is straightforward. The vulnerability deserves action because it is remotely reachable and affects availability. The public record does not justify presenting it as an active breach, an internet-wide emergency, or a confirmed safety incident.
Network Segmentation Must Carry the Unpatched Modules
BMXNGD0100 and BMXNOC0401 make compensating controls part of the primary defense, not a temporary administrative footnote.
Schneider Electric’s mitigation starts with the FTP service. The vendor says it is disabled by default and should remain disabled when not in use.
Operators should verify that status directly. Configuration records, approved service baselines, and network observations can provide stronger evidence than documentation alone.
Where FTP is necessary, access should be limited to the specific management systems that require it. A broad rule allowing port 21 throughout a control zone preserves much of the attack path.
The vendor also calls for network segmentation. Segmentation separates systems into controlled zones and restricts the traffic that can move between them. In this case, it should prevent unauthorized systems from reaching affected modules over FTP.
A practical review should examine more than the nearest firewall. Remote-access gateways, engineering workstations, jump hosts, temporary vendor connections, and dual-homed systems can create alternate paths.
CISA separately recommends placing control systems and remote devices behind firewalls and isolating them from business networks. It also advises minimizing internet exposure for industrial control devices.
Those controls align with Schneider Electric’s broader security practices. The guidance includes physical access restrictions, locked controller cabinets, controlled programming connections, and screening removable media.
VPN use requires similar care. A VPN encrypts a connection but does not make the connected endpoint trustworthy. Compromised credentials or an infected remote device can still provide a route toward the control network.
Remote access should terminate at a controlled boundary rather than directly on a controller subnet. Authentication, authorization, session logging, and time-limited access can reduce the risk of persistent exposure.
The mitigation plan should also define when FTP can be enabled. For example, a documented maintenance workflow might open access for a limited period, permit only an approved source, and close the rule after verification.
Monitoring can reinforce those controls. Unexpected connections to port 21, repeated malformed sessions, or traffic from new source addresses deserve investigation. The advisory does not publish a device-specific detection signature, so monitoring should focus on deviations from the approved baseline.
Recovery planning matters because the stated impact is denial of service. Teams should know whether a device recovers automatically, requires a restart, or needs engineering intervention after a fault.
The public advisory does not answer those questions for every configuration. Site owners should obtain product-specific support guidance and incorporate it into incident procedures.
A response plan should preserve evidence where operational conditions allow. Network logs, firewall records, device events, and maintenance histories can help distinguish an attack from equipment failure or configuration error.
For patched products, segmentation remains necessary. Firmware addresses this specific flaw, but it does not turn an industrial controller into an appropriate internet-facing service.
For unpatched products, segmentation becomes even more important because no vendor firmware currently removes the weakness. The architecture must reduce the chance that an unauthorized system can deliver the malicious command.
This is the tradeoff at the center of the Schneider Electric Modicon M340 vulnerability. Connectivity supports maintenance and data exchange, but unnecessary service reachability expands the failure path.
Three Signals Will Show Whether the Risk Is Closing
The next phase depends on patch completion, real deployment evidence, and any change in the observed threat picture.
The first signal is a fixed release for BMXNGD0100 or BMXNOC0401. Both remain listed as affected across all versions, and the advisory says Schneider Electric is developing remediation for future versions.
A published fix for either module would narrow the gap between firmware remediation and permanent reliance on compensating controls. It would strengthen the case that the vulnerability can be removed across the complete product set.
Continued silence would not mean the mitigations have failed. It would mean operators must keep validating FTP restrictions and segmentation without a firmware endpoint for those modules.
The second signal is evidence that installed systems have actually adopted the four available fixes. Relevant versions are M340 SV3.70, BMXNOR0200H SV1.7 IR27, BMXNOE0100 3.60, and BMXNOE0110 6.80.
Vendor publication is only the beginning of remediation. Industrial organizations must test, schedule, deploy, and verify each upgrade. Reboots for the BMXNOE modules can make completion slower than a normal endpoint patch cycle.
Organizations should track deployment by asset, not by advisory. A percentage based only on reviewed tickets can hide controllers that were never discovered or modules omitted from the original inventory.
The third signal is a change in exploitation evidence. The current public record does not identify known exploitation, and Tenable reports that no known public exploit is available.
That assessment can change. A proof of concept, observed scanning for exposed FTP services, incident reporting, or addition to the Known Exploited Vulnerabilities catalog would increase the urgency of isolation and patching.
The reverse is also informative. If no exploitation appears while organizations reduce FTP exposure and deploy available firmware, the residual risk becomes more manageable. It does not disappear for the unpatched modules.
Security teams should revisit the Schneider Electric Modicon M340 vulnerability now, even if they processed the original 2025 notice. The remediation picture has changed twice since then, and the CISA republication consolidates those updates.
Start with an asset-level inventory. Separate the six affected product groups, record their firmware, and verify whether FTP is enabled or reachable.
Then assign one of three states to each asset: corrected firmware installed, corrected firmware pending, or no correction currently available. That simple classification prevents an old mitigation ticket from hiding a new patching opportunity.
Finally, test the controls around BMXNGD0100 and BMXNOC0401. Can only approved management systems reach port 21? Is remote access brokered and logged? Would an unexpected FTP session trigger investigation?
The Schneider Electric Modicon M340 vulnerability is not a new zero-day, and the advisory does not document active exploitation. Its importance comes from something less dramatic: an incomplete remediation path across long-lived industrial equipment. The next meaningful update will be a fix for the remaining modules, verified field deployment, or credible evidence that attackers have begun targeting the flaw.
