ABB’s LVS MConfig versions 1.4.9.21 and earlier contain a high-severity credential-handling vulnerability, CVE-2025-9970, republished by CISA on May 26, 2026, after ABB’s October 8, 2025 advisory for its low-voltage switchgear configuration software. The flaw is not a flashy remote takeover bug, and that is exactly why it matters. It sits in the awkward middle ground where industrial security often lives: local access, operator trust, Windows workstations, and credentials that become dangerous when routine maintenance practices go wrong. ABB’s fix is straightforward — update to MConfig 1.4.9.22 — but the lesson is broader than a version number.
The vulnerability affects ABB LVS MConfig, the Windows-based parameterization software used with ABB low-voltage switchgear components such as motor and feeder controllers, operation panels, temperature monitoring equipment, and protocol converters. According to the advisory, MConfig runs on Windows 11 or later and is used against components physically installed in switchgear located in controlled switch rooms.
That physical-world context is important because it can make the bug sound less urgent than it is. This is not a wormable internet-facing service. An attacker needs access to the host machine running MConfig, and the advisory describes exploitation after a user has logged in, with the attacker exporting a memory dump during runtime.
But industrial security has never been only about internet exposure. Engineering workstations, maintenance laptops, jump hosts, and shared configuration machines are often where the neatly separated worlds of IT and operational technology meet. If credentials are sitting in process memory in recoverable form, then a compromised workstation is no longer merely a compromised workstation; it can become a credential collection point for the equipment it manages.
ABB and CISA describe the issue as cleartext storage of sensitive information in memory, mapped to CWE-316. The practical concern is plain enough: if passwords remain in memory and a dump file is created or mishandled, those credentials can be extracted later. That is an old class of mistake, but old does not mean obsolete. In industrial environments, old mistakes often retain their power because the operational consequences are unusually concrete.
That combination can look contradictory at first glance. If the bug is local and complex, why is it high severity? The answer is that the score is trying to model what happens after the credential exposure, not merely the act of dumping memory. In ABB’s own scenario, credentials plus access to a host running MConfig, plus access to the switch room where the components are installed, could allow an attacker to modify component settings and compromise correct operation.
That is not the same as saying a random internet attacker can flip switchgear settings from across the world. It is saying that once an attacker is in the local operational orbit — on the host, near the software, or able to obtain mishandled dump files — the exposed secret may become the bridge from observation to manipulation.
This is where CVSS often underserves readers outside security teams. A 7.4 in an office productivity tool and a 7.4 in software used to configure low-voltage switchgear do not carry the same operational flavor. The number gives procurement teams, vulnerability managers, and auditors a starting point, but the real prioritization has to include where MConfig is installed, who uses it, how credentials are managed, and whether dump files are retained, copied, attached to support tickets, or swept into centralized troubleshooting archives.
What makes it worth attention is the industrial setting. Memory dumps are a normal part of troubleshooting. When a configuration tool crashes, hangs, or behaves unpredictably, administrators and support teams may collect dumps to diagnose the problem. Those files can then move through help desks, vendor portals, shared drives, email attachments, and ticketing systems — all places where operational security assumptions tend to soften.
A password in memory is not automatically a breach. A password in a memory dump that gets copied into a loosely controlled workflow is a very different thing. The advisory’s warning about mishandled dump files is not bureaucratic boilerplate; it is the most realistic path from a local software defect to a broader credential exposure event.
That path also complicates incident response. If an organization discovers that MConfig dump files were generated while affected versions were in use, the right question is not simply whether the software has now been patched. The better question is whether those dumps were preserved anywhere, who had access to them, and whether credentials used in MConfig should be rotated as a precaution.
The first change is the more directly relevant one for this vulnerability. Clearing authentication-related data after login reduces the window in which sensitive material can be captured from process memory. It does not make memory scraping impossible in every conceivable circumstance, but it addresses the core failure mode described in the advisory: credentials lingering in recoverable form after they no longer need to be there.
The password hashing note deserves a little more caution. Hashing passwords is a necessary control in many storage contexts, but simply saying “SHA-256” does not, by itself, tell us everything about the design. Modern password storage usually depends on salted, deliberately slow password hashing schemes rather than fast general-purpose hashes alone. The advisory does not provide enough implementation detail to judge the full password-handling model, so the fair reading is narrower: ABB changed how MConfig handles authentication data as part of the fix, and customers should not infer more than the advisory states.
Still, the patch reveals a familiar truth. Security fixes are often framed as isolated corrections, but credential handling is an architecture choice. If an application can complete authentication and then promptly remove sensitive material from memory, it probably should have been doing so already. Industrial software has historically been judged most heavily on availability, determinism, and compatibility. This advisory is another data point in the industry’s slow shift toward treating secure memory handling as a baseline requirement, not an optional refinement.
The most interesting part of this advisory is not that an industrial product has a memory-handling vulnerability. It is that exploitation depends on the host machine environment. The attacker needs access to the host, and the advisory specifically describes physical access to the machine with MConfig installed. That means the security of the Windows endpoint is part of the security of the switchgear configuration workflow.
In many organizations, engineering workstations do not receive the same endpoint discipline as corporate laptops. They may be shared by multiple technicians, kept near equipment rooms, exempted from aggressive security controls to avoid disrupting vendor software, or allowed to accumulate diagnostic tools over years of maintenance. Those exceptions are understandable. They are also exactly where a memory dump vulnerability can become practical.
The mitigation advice therefore should not stop at “install version 1.4.9.22.” It should include checking who can log into the MConfig workstation, who can generate dumps, where dumps are stored, whether local admin rights are tightly controlled, and whether endpoint monitoring can distinguish legitimate engineering activity from credential-harvesting behavior. In OT security, the endpoint is often the compromise between operational necessity and security policy. This advisory lands directly on that compromise.
Even so, republication by CISA changes the operational audience. A vendor advisory may reach product owners and integrators; a CISA ICS advisory reaches security operations centers, vulnerability management teams, auditors, and critical infrastructure defenders who track advisories across vendors. For many organizations, that is the difference between a PDF sitting on a vendor site and a ticket entering a patch queue.
The affected sectors listed are broad: chemical, critical manufacturing, energy, food and agriculture, transportation systems, and water and wastewater. The advisory also lists worldwide deployment and ABB’s headquarters in Switzerland. That breadth does not mean every facility in those sectors uses MConfig. It means the product lives in the kind of environments where configuration changes can have consequences beyond an ordinary workstation.
CISA’s standard recommended practices are predictable but still relevant: minimize network exposure, keep control system devices off the internet, isolate control system networks from business networks, use secure remote access methods when remote access is necessary, and perform impact analysis before deploying defensive measures. In this case, the most useful reading of that guidance is not as a direct exploit blocker. It is as a reminder that local flaws become less local when networks, remote access paths, and shared administrative practices are poorly segmented.
This is why “physical access required” should not calm anyone too quickly. Physical access in industrial settings is not binary. Contractors, vendor technicians, maintenance personnel, plant engineers, and IT staff may all have legitimate reasons to be near systems that would be considered highly sensitive in a pure cybersecurity diagram.
Likewise, “local access” does not always mean a person standing at a keyboard. If a remote support tool, VPN session, jump server, or compromised management account provides interactive access to the MConfig host, the practical distinction between local and remote can blur. The advisory says the vulnerability can only be exploited with physical access to the host machine, but defenders should still examine whether their own remote administration model effectively extends that host’s reach beyond the switch room.
The better operational question is not whether the exploit scenario sounds easy. It is whether the organization has reduced the number of people, sessions, tools, and stored files that could make the scenario plausible.
Industrial environments are rarely that simple. Configuration software may be tied to validated procedures, site acceptance testing, vendor support contracts, change windows, or internal rules that treat engineering software updates as operational changes. Some facilities may not know where every copy of MConfig is installed, especially if it lives on laptops used by maintenance teams or integrators rather than centrally managed desktops.
That makes inventory the real first step. A vulnerability in a configuration tool cannot be remediated if nobody knows where the tool resides. Security teams should look beyond servers and domain-joined workstations and include maintenance laptops, engineering images, offline machines, vendor-supplied systems, and spares kept for emergency work.
Where immediate update is not feasible, ABB points customers toward general security recommendations and mitigation factors. Those mitigations should be treated as temporary risk reduction, not a substitute for the fixed release. Memory-handling bugs are precisely the sort of issue that becomes harder to reason about the longer affected software remains in use, because every troubleshooting artifact generated during that period may become part of the exposure surface.
If affected versions were used in production, organizations should consider whether memory dumps were generated while MConfig was running. That includes crash dumps, manual dumps, support bundles, diagnostic archives, and any files collected during troubleshooting. If such files exist, they should be treated as sensitive until proven otherwise.
Credential rotation is especially important where MConfig credentials have privileged access to switchgear configuration functions. The advisory’s own scenario warns that extracted credentials, combined with access to a host machine and physical access to components, could allow modification of settings. Rotating credentials after patching reduces the value of any secrets that may already have escaped.
This is not a call for panic. It is a call for proportionate hygiene. If a password may have lived in a recoverable memory dump, patching the application prevents the same exposure from recurring, but it does not retroactively sanitize old files or invalidate old credentials.
But industrial systems create risk in quieter ways. A local credential exposure flaw in configuration software may not trend on social media, yet it can sit close to equipment that facilities depend on. The impact is bounded by access prerequisites, but those prerequisites may already exist inside the operational environment.
This is the kind of advisory that separates asset-aware vulnerability management from spreadsheet vulnerability management. A central scanner may not see MConfig. A CVSS-driven dashboard may under-contextualize it. A plant engineer may know exactly which workstation matters but may not be plugged into the cybersecurity ticketing process.
The organizations that handle this well will be the ones that connect those worlds. They will know where the software is installed, who uses it, what credentials it touches, and how diagnostic artifacts are handled. The organizations that handle it poorly will argue over whether a local vulnerability “counts” while old dump files quietly age on shared storage.
ABB’s MConfig Bug Is a Reminder That Local Does Not Mean Harmless
The vulnerability affects ABB LVS MConfig, the Windows-based parameterization software used with ABB low-voltage switchgear components such as motor and feeder controllers, operation panels, temperature monitoring equipment, and protocol converters. According to the advisory, MConfig runs on Windows 11 or later and is used against components physically installed in switchgear located in controlled switch rooms.That physical-world context is important because it can make the bug sound less urgent than it is. This is not a wormable internet-facing service. An attacker needs access to the host machine running MConfig, and the advisory describes exploitation after a user has logged in, with the attacker exporting a memory dump during runtime.
But industrial security has never been only about internet exposure. Engineering workstations, maintenance laptops, jump hosts, and shared configuration machines are often where the neatly separated worlds of IT and operational technology meet. If credentials are sitting in process memory in recoverable form, then a compromised workstation is no longer merely a compromised workstation; it can become a credential collection point for the equipment it manages.
ABB and CISA describe the issue as cleartext storage of sensitive information in memory, mapped to CWE-316. The practical concern is plain enough: if passwords remain in memory and a dump file is created or mishandled, those credentials can be extracted later. That is an old class of mistake, but old does not mean obsolete. In industrial environments, old mistakes often retain their power because the operational consequences are unusually concrete.
The CVSS Score Captures the Tension but Not the Whole Risk
CVE-2025-9970 carries a CVSS v3.1 base score of 7.4, rated high. The vector tells the story in compressed form: local attack vector, high attack complexity, low privileges required, user interaction required, changed scope, low confidentiality impact, and high integrity and availability impact.That combination can look contradictory at first glance. If the bug is local and complex, why is it high severity? The answer is that the score is trying to model what happens after the credential exposure, not merely the act of dumping memory. In ABB’s own scenario, credentials plus access to a host running MConfig, plus access to the switch room where the components are installed, could allow an attacker to modify component settings and compromise correct operation.
That is not the same as saying a random internet attacker can flip switchgear settings from across the world. It is saying that once an attacker is in the local operational orbit — on the host, near the software, or able to obtain mishandled dump files — the exposed secret may become the bridge from observation to manipulation.
This is where CVSS often underserves readers outside security teams. A 7.4 in an office productivity tool and a 7.4 in software used to configure low-voltage switchgear do not carry the same operational flavor. The number gives procurement teams, vulnerability managers, and auditors a starting point, but the real prioritization has to include where MConfig is installed, who uses it, how credentials are managed, and whether dump files are retained, copied, attached to support tickets, or swept into centralized troubleshooting archives.
Memory Dumps Are Useful Until They Become Evidence Lockers for Passwords
The vulnerability’s mechanics are unglamorous: during runtime, an attacker can export a memory dump file from the operating system; if passwords are stored in plain text in memory, those passwords are included in the dump. That is not a novel exploitation chain. It is the kind of weakness that has haunted desktop applications, admin consoles, and enterprise agents for years.What makes it worth attention is the industrial setting. Memory dumps are a normal part of troubleshooting. When a configuration tool crashes, hangs, or behaves unpredictably, administrators and support teams may collect dumps to diagnose the problem. Those files can then move through help desks, vendor portals, shared drives, email attachments, and ticketing systems — all places where operational security assumptions tend to soften.
A password in memory is not automatically a breach. A password in a memory dump that gets copied into a loosely controlled workflow is a very different thing. The advisory’s warning about mishandled dump files is not bureaucratic boilerplate; it is the most realistic path from a local software defect to a broader credential exposure event.
That path also complicates incident response. If an organization discovers that MConfig dump files were generated while affected versions were in use, the right question is not simply whether the software has now been patched. The better question is whether those dumps were preserved anywhere, who had access to them, and whether credentials used in MConfig should be rotated as a precaution.
The Patch Fixes a Bug, but It Also Admits a Design Problem
ABB says the issue is resolved in MConfig version 1.4.9.22. The advisory states that the update clears authentication-related memory data after successful login and hashes passwords using SHA-256.The first change is the more directly relevant one for this vulnerability. Clearing authentication-related data after login reduces the window in which sensitive material can be captured from process memory. It does not make memory scraping impossible in every conceivable circumstance, but it addresses the core failure mode described in the advisory: credentials lingering in recoverable form after they no longer need to be there.
The password hashing note deserves a little more caution. Hashing passwords is a necessary control in many storage contexts, but simply saying “SHA-256” does not, by itself, tell us everything about the design. Modern password storage usually depends on salted, deliberately slow password hashing schemes rather than fast general-purpose hashes alone. The advisory does not provide enough implementation detail to judge the full password-handling model, so the fair reading is narrower: ABB changed how MConfig handles authentication data as part of the fix, and customers should not infer more than the advisory states.
Still, the patch reveals a familiar truth. Security fixes are often framed as isolated corrections, but credential handling is an architecture choice. If an application can complete authentication and then promptly remove sensitive material from memory, it probably should have been doing so already. Industrial software has historically been judged most heavily on availability, determinism, and compatibility. This advisory is another data point in the industry’s slow shift toward treating secure memory handling as a baseline requirement, not an optional refinement.
Windows Workstations Remain the Soft Edge of OT
For WindowsForum readers, the Windows angle is not incidental. MConfig is a Windows application, and the advisory says the host machine should run Windows 11 or later. That places the affected workflow on familiar terrain: endpoint hardening, local privilege control, dump creation permissions, credential hygiene, and user behavior.The most interesting part of this advisory is not that an industrial product has a memory-handling vulnerability. It is that exploitation depends on the host machine environment. The attacker needs access to the host, and the advisory specifically describes physical access to the machine with MConfig installed. That means the security of the Windows endpoint is part of the security of the switchgear configuration workflow.
In many organizations, engineering workstations do not receive the same endpoint discipline as corporate laptops. They may be shared by multiple technicians, kept near equipment rooms, exempted from aggressive security controls to avoid disrupting vendor software, or allowed to accumulate diagnostic tools over years of maintenance. Those exceptions are understandable. They are also exactly where a memory dump vulnerability can become practical.
The mitigation advice therefore should not stop at “install version 1.4.9.22.” It should include checking who can log into the MConfig workstation, who can generate dumps, where dumps are stored, whether local admin rights are tightly controlled, and whether endpoint monitoring can distinguish legitimate engineering activity from credential-harvesting behavior. In OT security, the endpoint is often the compromise between operational necessity and security policy. This advisory lands directly on that compromise.
CISA’s Republication Turns a Vendor Advisory Into an Operational Signal
CISA’s May 26, 2026 republication of ABB PSIRT advisory 4TZ00000006008 is described as a verbatim CSAF conversion, provided as-is for visibility. That caveat matters. CISA is not claiming new exploitation intelligence in the text provided, nor does the advisory indicate that the vulnerability is known to be actively exploited.Even so, republication by CISA changes the operational audience. A vendor advisory may reach product owners and integrators; a CISA ICS advisory reaches security operations centers, vulnerability management teams, auditors, and critical infrastructure defenders who track advisories across vendors. For many organizations, that is the difference between a PDF sitting on a vendor site and a ticket entering a patch queue.
The affected sectors listed are broad: chemical, critical manufacturing, energy, food and agriculture, transportation systems, and water and wastewater. The advisory also lists worldwide deployment and ABB’s headquarters in Switzerland. That breadth does not mean every facility in those sectors uses MConfig. It means the product lives in the kind of environments where configuration changes can have consequences beyond an ordinary workstation.
CISA’s standard recommended practices are predictable but still relevant: minimize network exposure, keep control system devices off the internet, isolate control system networks from business networks, use secure remote access methods when remote access is necessary, and perform impact analysis before deploying defensive measures. In this case, the most useful reading of that guidance is not as a direct exploit blocker. It is as a reminder that local flaws become less local when networks, remote access paths, and shared administrative practices are poorly segmented.
The Real Exposure May Be in Old Maintenance Habits
The advisory’s most uncomfortable implication is that the bug’s exploitability may depend less on a sophisticated attacker than on ordinary maintenance habits. Shared engineering stations, unattended sessions, local admin privileges, ad hoc dump collection, and vendor support workflows can all create the conditions in which cleartext credentials in memory become recoverable secrets.This is why “physical access required” should not calm anyone too quickly. Physical access in industrial settings is not binary. Contractors, vendor technicians, maintenance personnel, plant engineers, and IT staff may all have legitimate reasons to be near systems that would be considered highly sensitive in a pure cybersecurity diagram.
Likewise, “local access” does not always mean a person standing at a keyboard. If a remote support tool, VPN session, jump server, or compromised management account provides interactive access to the MConfig host, the practical distinction between local and remote can blur. The advisory says the vulnerability can only be exploited with physical access to the host machine, but defenders should still examine whether their own remote administration model effectively extends that host’s reach beyond the switch room.
The better operational question is not whether the exploit scenario sounds easy. It is whether the organization has reduced the number of people, sessions, tools, and stored files that could make the scenario plausible.
Version 1.4.9.22 Should Be the Easy Part
Updating to MConfig 1.4.9.22 is the obvious first move. ABB says the vulnerability is fixed in that version and advises users to update to the latest software release. For organizations that can patch quickly, this should be a low-drama remediation task: identify installations, confirm versions, deploy the update, and document completion.Industrial environments are rarely that simple. Configuration software may be tied to validated procedures, site acceptance testing, vendor support contracts, change windows, or internal rules that treat engineering software updates as operational changes. Some facilities may not know where every copy of MConfig is installed, especially if it lives on laptops used by maintenance teams or integrators rather than centrally managed desktops.
That makes inventory the real first step. A vulnerability in a configuration tool cannot be remediated if nobody knows where the tool resides. Security teams should look beyond servers and domain-joined workstations and include maintenance laptops, engineering images, offline machines, vendor-supplied systems, and spares kept for emergency work.
Where immediate update is not feasible, ABB points customers toward general security recommendations and mitigation factors. Those mitigations should be treated as temporary risk reduction, not a substitute for the fixed release. Memory-handling bugs are precisely the sort of issue that becomes harder to reason about the longer affected software remains in use, because every troubleshooting artifact generated during that period may become part of the exposure surface.
Credential Rotation Belongs in the Remediation Plan
A narrow patch plan would update MConfig and close the ticket. A better plan would ask whether credentials used with affected versions may already have been exposed through dump files or compromised host access. The advisory does not say exploitation has occurred, but it describes a mechanism that can leave artifacts behind.If affected versions were used in production, organizations should consider whether memory dumps were generated while MConfig was running. That includes crash dumps, manual dumps, support bundles, diagnostic archives, and any files collected during troubleshooting. If such files exist, they should be treated as sensitive until proven otherwise.
Credential rotation is especially important where MConfig credentials have privileged access to switchgear configuration functions. The advisory’s own scenario warns that extracted credentials, combined with access to a host machine and physical access to components, could allow modification of settings. Rotating credentials after patching reduces the value of any secrets that may already have escaped.
This is not a call for panic. It is a call for proportionate hygiene. If a password may have lived in a recoverable memory dump, patching the application prevents the same exposure from recurring, but it does not retroactively sanitize old files or invalidate old credentials.
The Advisory Also Tests How Seriously Organizations Treat “Non-Internet” Bugs
Security teams are conditioned to chase remote code execution, exploited zero-days, and internet-facing appliances. That triage instinct is rational. Resources are finite, and the loudest fires usually deserve attention first.But industrial systems create risk in quieter ways. A local credential exposure flaw in configuration software may not trend on social media, yet it can sit close to equipment that facilities depend on. The impact is bounded by access prerequisites, but those prerequisites may already exist inside the operational environment.
This is the kind of advisory that separates asset-aware vulnerability management from spreadsheet vulnerability management. A central scanner may not see MConfig. A CVSS-driven dashboard may under-contextualize it. A plant engineer may know exactly which workstation matters but may not be plugged into the cybersecurity ticketing process.
The organizations that handle this well will be the ones that connect those worlds. They will know where the software is installed, who uses it, what credentials it touches, and how diagnostic artifacts are handled. The organizations that handle it poorly will argue over whether a local vulnerability “counts” while old dump files quietly age on shared storage.
The Lesson From ABB’s MConfig Fix Is Smaller Than a Breach and Larger Than a Patch
For defenders, this advisory is not a five-alarm event, but it is a useful test of operational maturity. It asks whether teams can treat an engineering workstation as part of the control environment rather than as an ordinary PC with unusual software installed.- ABB LVS MConfig versions 1.4.9.21 and earlier are affected by CVE-2025-9970, a cleartext-in-memory credential vulnerability rated high under CVSS v3.1.
- ABB says MConfig version 1.4.9.22 fixes the issue by clearing authentication-related memory data after login and changing password handling.
- Exploitation requires local access conditions and user interaction, but exposed credentials could matter because MConfig is used to configure low-voltage switchgear components.
- Organizations should look for affected installations on engineering workstations, maintenance laptops, jump hosts, and vendor-supported systems, not just centrally managed endpoints.
- Old memory dumps, crash dumps, diagnostic bundles, and support archives should be treated as potentially sensitive if they were created while affected MConfig versions were running.
- Patching should be paired with credential review, endpoint hardening, access control, and network segmentation rather than treated as a standalone checkbox.
References
- Primary source: CISA
Published: 2026-05-26T12:00:00+00:00
ABB LVS MConfig | CISA
www.cisa.gov
- Related coverage: johnsoncontrols.com
