{
"title": "Schneider Electric Plugs XSS Hole in Popular Altivar Drives, but Dozens of Models Still at Risk",
"content": "Schneider Electric has released firmware updates to fix a cross‑site scripting vulnerability in several lines of its Altivar industrial drives and modular components, but a clutch of commonly deployed communication modules remain wide open to attack. The vendor’s advisory, first published in mid‑September 2025 and updated repeatedly through October, assigns CVE‑2025‑7746 a CVSS 3.1 base score of 6.1 (Medium) and confirms that an attacker can inject malicious script into the devices’ web‑based management interfaces.

Fixes Arrive for Some Models, but Critical Modules Still Vulnerable

This vulnerability touches an unusually broad product portfolio. At the time of writing, the following products have received tested, downloadable patches:

  • ATVdPAC module (VW3A3530D): fixed in version 25.0, available on request from Schneider Electric Customer Care.
  • Altivar Process Drives – ATV6xx series: ATV630, 650, 660, 680, 6A0, 6B0, 6L0 – fixed in firmware version 4.5.
  • Altivar Process Drives – ATV9xx series: ATV930, 950, 955, 960, 980, 9A0, 9B0, 9L0, 991, 992, 993 – fixed in firmware version 4.5.
  • Altivar Machine Drives ATV340E: fixed in firmware version 4.5.
The fixes for these models are available for download from the respective product pages on the Schneider Electric website. The vendor has also committed to delivering patches for two additional product families:
  • ATS490 Altivar Soft Starter – fix expected in version 1.2ie05, slated for December 2025.
  • ATV6000 Medium Voltage Altivar Process Drives – fix expected in version 2.2, scheduled for May 2026.
However, three widely used communication modules currently have no fix available and no firm delivery date. The advisory states that Schneider Electric is “establishing a remediation plan” for these, but operators must rely entirely on compensating controls in the interim:
  • VW3A3720 & VW3A3721 Altivar Process Communication Modules (all versions)
  • ILC992 InterLink Converter (all versions)
This split – immediate patches for many drives, a long wait for soft starters and medium‑voltage units, and no timetable for essential networking modules – creates a complex patching schedule that OT teams must navigate carefully.

The advisory classifies the flaw as CWE‑79: Improper Neutralization of Input During Web Page Generation, better known as reflected or stored cross‑site scripting. The official CVSS 3.1 vector string (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N) indicates the attack is network‑based, requires no privileges, and needs user interaction – typically an engineer clicking a crafted link while authenticated to the device’s web UI. The impact scoping (S:C) means a successful compromise of the browser can then affect resources beyond the browser’s own security context, such as the underlying management interface.

Operational Impact: Why This XSS Threat Differs in an Industrial Setting

For enterprise IT teams, a medium‑severity XSS bug might barely register on the daily triage list. In an OT environment, the calculus changes. These drives control pumps, conveyors, compressors, HVAC systems, and other physical processes in critical manufacturing, water treatment, energy generation, and building automation. The web management interface, often left active for convenience, can become a pivot point.

  • Session theft and credential harvesting: An attacker who tricks a maintenance engineer into clicking a malicious URL while that engineer is logged into the drive’s web UI could steal authentication cookies or capture keystrokes. If those credentials are shared across engineering workstations or jump hosts, the attacker gains a foothold on the OT network.
  • Configuration tampering: With a foothold in the browser, an attacker might alter drive parameters visible through the UI. Depending on the drive’s configuration and safety interlocks, this could lead to process disruptions, equipment damage, or unsafe conditions.
  • Lateral movement: Compromised workstations that access multiple drives – a common practice in plant floors – let an attacker propagate across the network, potentially reaching higher‑value assets like SCADA servers or historian databases.
  • Low barrier to entry: No exploit code has been publicly observed as of this writing, but the vulnerability’s low attack complexity and the widespread availability of XSS payload templates mean opportunistic scanning and exploitation are likely.
The medium CVSS score should not breed complacency. The requirement for user interaction is a mitigating factor, but in industrial settings, engineers routinely access drive management pages, and phishing campaigns targeting OT staff have become more sophisticated. One successful click can cascade.

How We Got Here: Convenience Features Become Attack Surface

Web‑based management in industrial equipment has been a double‑edged sword for years. It gives plant personnel a familiar interface for configuration, troubleshooting, and data retrieval without requiring proprietary software. But it also exposes a full HTTP stack on devices that were never designed with the same security scrutiny as a modern web application.

Schneider Electric is far from alone. The ICS‑CERT advisory archive is littered with similar XSS, CSRF, and authentication bypass vulnerabilities across vendors. The Altivar family, known for its variable frequency drives and soft starters, has seen security bulletins before, but this one is notable for the sheer number of affected models.

CVE‑2025‑7746 was reported to Schneider Electric by researchers Thomas Weber and David Blagojevic of CyberDanube. The vendor’s own CPCERT disclosed it to CISA, leading to the publication of ICSA‑25‑259‑01 on September 9, 2025. Since then, the advisory has been updated four times as fixes become available, with the most recent revision at the time of this article adding patches for the ATV6xx, ATV9xx, and ATV340 drives.

The root cause – improper input neutralization – suggests that the device firmware’s web server does not adequately sanitize user‑supplied parameters before reflecting them in HTTP responses. Fixing this across a diverse product line requires rewriting code for each firmware variant, a process that can take months, especially when the affected models include older, end‑of‑life or deeply embedded controllers.

Urgent Steps: Inventory, Patch, Shield, and Monitor

If your organization uses any of the listed Altivar products, treat this advisory as an operational security incident. Move quickly through these priorities, coordinating with OT engineers, IT networking, and cybersecurity teams.

1. Complete an emergency inventory

  • Identify all instances of affected models by serial number and firmware version. Pay special attention to the part numbers VW3A3530D, VW3A3720, VW3A3721, and ILC992.
  • Document which devices have their web server enabled, and which are accessible from corporate IT networks or the internet. Any device with port 80/HTTP open to a non‑isolated subnet is your highest priority.

2. Apply patches where available – now

  • ATVdPAC: Download and deploy VW3A3530D version 25.0 from Schneider Electric’s Customer Care Center. Test in a lab environment first, then roll out through your change control process.
  • ATV6xx and ATV9xx drives: Upgrade to firmware version 4.5. Obtain the firmware from the respective Schneider Electric product pages.
  • ATV340E: Upgrade to firmware version 4.5.
  • For ATS490 and ATV6000, mark your calendar for the vendor’s planned release dates and treat them as pending patches. Until then, apply the mitigations below.

3. Shield unpatched devices with immediate compensating controls

  • Disable the web server on any device where the interface is not strictly required. Most drives can be configured via fieldbus or local HMI without the web UI.
  • Segment your network. Place all OT assets behind a properly configured firewall that blocks all incoming traffic to port 80/HTTP from business networks and the internet. Use VLANs to isolate drive management traffic onto a dedicated operations subnet.
  • Restrict access at the port level. Implement strict ACLs on switches and routers so that only a small set of hardened engineering workstation IPs can reach the drives’ management interfaces.
  • Use VPNs for remote access. If remote management is unavoidable, enforce multi‑factor‑authenticated VPN tunnels