Schneider Electric PowerChute Serial Shutdown Faces an Authentication Weakness

Schneider Electric PowerChute Serial Shutdown versions through 1.5 contain an authentication weakness that permits unlimited login attempts under a specific configuration. The flaw, tracked as CVE-2026-13348, received a 5.3 Medium score under CVSS 3.1. Schneider Electric has fixed it in version 1.6.

The rating sounds moderate, but the affected software occupies an unusually sensitive position. PowerChute monitors uninterruptible power supplies, manages energy events, and initiates graceful operating-system shutdowns during extended outages. Unauthorized access therefore reaches software entrusted with protecting system availability and operational data.

The central conflict is not Schneider Electric against another vendor. It is a routine-looking authentication flaw against the operational trust placed in power-management software. CISA says the product appears across commercial facilities, critical manufacturing, energy, and information technology environments worldwide.

The incident also arrives after several earlier PowerChute security notices. That history changes the practical question for operators. Updating version 1.5 is necessary, but teams must also decide whether their deployment, exposure, and monitoring practices match the software’s operational importance.

What Changed in Schneider Electric PowerChute Serial Shutdown

CVE-2026-13348 turns a missing authentication limit into a path toward unauthorized account access.

Schneider Electric disclosed the issue in security notification SEVD-2026-223-01 on August 11, 2026. CISA republished the information as ICS advisory ICSA-26-260-07 on September 17.

The affected release range is PowerChute Serial Shutdown version 1.5 and earlier. Version 1.6 is the fixed release for supported Windows and Linux installations. Operators should not read references to version 1.6 in machine-readable product listings as evidence that it remains vulnerable.

Those listings distinguish affected software from fixed products installed on Windows, Red Hat Enterprise Linux, and SUSE Enterprise Linux. The underlying CSAF record marks version 1.5 and earlier as known affected. It classifies the version 1.6 platform combinations as fixed.

The vulnerability belongs to CWE-307, or improper restriction of excessive authentication attempts. That category covers systems that fail to limit repeated attempts against an authentication mechanism. Without effective controls, an attacker can keep guessing credentials instead of being slowed or blocked.

Schneider Electric’s description adds an important condition. The arbitrary attempts become possible when redirect handling is disabled. The public notice does not provide a detailed exploitation sequence, so defenders should avoid inventing assumptions about the exact request flow.

The relevant outcome is clearer than the implementation detail. An attacker with network access to the interface can attempt to gain unauthorized access to a user account. No prior authentication or user interaction appears in the published CVSS vectors.

The official CVE record lists a network attack vector, low attack complexity, no required privileges, and no required user action. It assigns a low confidentiality impact without direct integrity or availability impact in the base assessment.

That combination produced a CVSS 3.1 score of 5.3. The CVSS 4.0 assessment is 6.9, also Medium. The difference reflects changes in the scoring framework, not a newly discovered impact.

CISA’s public enrichment describes exploitation as not observed, the attack as automatable, and the technical impact as partial. Those labels matter because automation and confirmed exploitation answer different questions. A weakness can support repeatable attempts even when researchers have not reported active attacks.

Schneider Electric says it found the issue internally and reported it to CISA through its product security response organization. The public materials do not name an external researcher or describe a field incident that triggered the disclosure.

The fix is direct. Install PowerChute Serial Shutdown 1.6, then confirm the installed version through the operating system or the application’s About page. The installation automatically restarts the PowerChute service, which creates a short operational change that administrators should schedule and verify.

Why a Medium Authentication Flaw Still Matters

The software’s role in shutdown orchestration makes exposure and account access more important than the Medium label alone suggests.

PowerChute Serial Shutdown connects a supported UPS to a desktop, workstation, or server. It monitors power conditions and coordinates a graceful shutdown when an outage lasts beyond configured thresholds. That process aims to prevent abrupt power loss, file corruption, and uncontrolled application termination.

This is not the same as a vulnerability inside a UPS controller. The published issue affects the PowerChute software interface, and the CVSS assessment does not assign a direct availability impact. The advisory also does not claim that CVE-2026-13348 lets an attacker cut electrical power.

Those distinctions prevent exaggeration. However, an account within management software can still expose information about the host, the UPS, and configured events. Depending on the account’s available functions, unauthorized access can also interfere with administrative control.

Schneider Electric warns that failed remediation can risk operational disruption and access to system data. That is broader operational language than the base CVSS result, which records only a low confidentiality impact. Administrators should preserve both facts instead of treating either as a complete local risk assessment.

CVSS measures defined technical characteristics under a standardized model. It does not know whether a particular PowerChute instance protects an employee workstation, a lab server, or a system supporting a production process. The same defect can therefore carry different consequences across installations.

The four sectors named in the advisory illustrate that range. Commercial facilities may use the software around building or security systems. Manufacturers can have workstations or servers connected to production support functions. Energy and information technology operators may depend on orderly shutdown behavior for service continuity.

The product is deployed worldwide, according to the advisory. That does not establish how many vulnerable installations exist or how many are reachable over a network. Schneider Electric and CISA did not publish an affected-device count.

Exposure becomes the first local risk multiplier. An interface reachable from an untrusted network gives an attacker an opportunity to make repeated authentication attempts. A tightly restricted management interface removes many potential paths before the application processes a login.

Credential quality is the second multiplier. Unlimited guesses do not guarantee account compromise, especially against a long and unique password. They become more concerning when an organization reuses credentials, keeps weak passwords, or lacks visibility into repeated failures.

Operational dependency is the third multiplier. A PowerChute installation protecting a disposable test machine does not carry the same business consequence as one protecting a critical server. Asset owners must connect the software record to the service it supports.

CISA advises organizations to minimize network exposure for control-system devices and keep them inaccessible from the public internet. It also recommends firewalls, isolation from business networks, and current virtual private network software when remote access is required.

Those controls do not replace version 1.6. They reduce paths to a vulnerable service while an organization tests and deploys the update. They also remain useful after patching because future defects might affect different parts of the management interface.

The practical lesson is simple. A Medium score supports prioritization, but it should not make the decision by itself. Network reachability, credential strength, system role, and recovery requirements determine the urgency inside each environment.

The Real Tradeoff Is Convenience Versus Restricted Access

Power management needs dependable administration, but broad administrative reach gives authentication defects more room to matter.

PowerChute uses a browser-accessible interface backed by a server application. That design lets an administrator review status and configuration without working directly beside the protected UPS. The same convenience creates a network service that must authenticate users correctly.

Remote management becomes attractive when systems sit in server rooms, branch offices, or lightly staffed facilities. Administrators want timely status information and a predictable way to change shutdown behavior. Central accessibility can reduce travel and speed routine maintenance.

The security tradeoff begins when accessibility expands beyond the people and systems that need it. A web interface exposed to a broad corporate network can receive traffic from every compromised endpoint on that network. Direct internet exposure increases the potential audience further.

CVE-2026-13348 sharpens that tradeoff because the weakness involves excessive authentication attempts. The CWE-307 definition describes products that fail to sufficiently restrict repeated attempts against an authentication mechanism. Rate limits, delays, and lockout behavior typically help raise the cost of guessing.

Schneider Electric ties the flaw to disabled redirect handling. Public documentation does not explain why that setting changes enforcement or whether common deployments disable it. Organizations should inspect their actual configuration instead of assuming that a default setting makes them safe.

They should also avoid using configuration as a reason to postpone the update. Settings change, systems get restored from older backups, and administrators can make undocumented adjustments. Moving to the fixed release removes dependence on an uncertain condition.

Network segmentation provides another layer. The PowerChute interface should be reachable only from approved management systems or administrator networks. Firewall policy can enforce that boundary more consistently than informal expectations about who knows the address.

Remote access deserves similar care. Placing the interface behind a VPN reduces direct exposure, but a VPN does not make the connected endpoint trustworthy. A compromised administrator laptop can carry an attacker through the same approved path.

Account practices complete the picture. Administrators should use a unique password, avoid sharing it with other systems, and remove access that no longer has an owner. Failed-login monitoring can reveal repeated attempts even when those attempts never succeed.

The application’s certificate configuration also matters, but it is separate from this CVE. PowerChute installations can use a self-signed certificate for encrypted browser communication. A certificate warning concerns server identity and trust, while CVE-2026-13348 concerns restrictions on authentication attempts.

Treating every security control as interchangeable creates blind spots. Transport encryption does not rate-limit password guesses. A firewall does not repair application logic. A fixed application does not justify unnecessary internet exposure.

Schneider Electric’s security handbook provides product-specific hardening guidance. Teams should use it to review the surrounding deployment after upgrading, particularly network access, accounts, certificates, logging, and host security.

A disciplined remediation sequence starts with inventory. Identify each protected system running PowerChute and record its installed version, operating system, network listeners, and business owner. Include dormant installations and machines that operate outside central software management.

Next, map reachability. Test access from user networks, guest networks, server segments, remote-access paths, and the public internet where appropriate. An inventory entry without an exposure assessment leaves the main attack path unanswered.

Then update to version 1.6 using Schneider Electric’s platform-specific package. The installer restarts the service automatically. Administrators should plan around that restart, especially when the software protects a server with strict monitoring or availability procedures.

After installation, confirm the displayed version. Test communication with the UPS, review the current power state, and verify that configured shutdown behavior remains intact. A successful package installation does not prove that every operational dependency still works.

Finally, review authentication telemetry. Look for clusters of failed logins, unexpected source addresses, and successful access that lacks a maintenance explanation. The vendor says the vulnerability can enable unauthorized account access, so defenders should check for both attempts and possible success.

PowerChute’s Advisory History Raises the Baseline

CVE-2026-13348 is a narrow flaw, but it follows repeated disclosures involving the same management product.

Schneider Electric issued an earlier PowerChute Serial Shutdown notice in December 2024 for CVE-2024-10511. That issue involved improper authentication and could block access to the product’s single web-interface account. The vendor said the application would continue protecting the server despite the web denial of service.

A November 2025 notice covered three more vulnerabilities. They involved path traversal, insufficient restriction of authentication attempts, and incorrect default permissions. Schneider Electric warned of possible privilege elevation or unauthenticated access, with potential operational disruption and access to system data.

In April 2026, another notice addressed seven vulnerabilities in versions 1.4 and earlier. The weakness categories included path traversal, output encoding, excessive authentication attempts, uncontrolled resource consumption, quantity validation, CRLF injection, and sensitive information in log files.

That sequence does not prove version 1.6 is broadly unsafe. Every advisory has its own affected range, prerequisites, and impact. It does show why teams should manage PowerChute as maintained server software rather than a utility installed once and forgotten.

The latest flaw also overlaps conceptually with the 2025 and April 2026 notices. Multiple disclosures have involved restrictions on authentication attempts. Public notices alone do not establish whether they share code, configuration, or root cause.

Administrators should therefore avoid claiming that Schneider Electric failed to fix the same vulnerability repeatedly. The available records do not support that conclusion. They do support closer attention to authentication behavior across upgrades and restored configurations.

Historical advisories matter for asset discovery too. An organization that missed one update may have missed several. Finding version 1.5 should trigger a review of how that machine receives software notices, not only a one-time installation task.

Version checks must use trustworthy evidence. Tenable released a detection plugin that flags releases earlier than 1.6, but its plugin documentation says the check relies on the application’s self-reported version. The scanner does not attempt to exploit the flaw.

That limitation is normal for many vulnerability checks. It also means teams should confirm the result locally before closing a remediation ticket. Software inventory, the operating system’s installed-program view, and PowerChute’s About page can provide corroborating evidence.

The public record has other gaps. No proof-of-concept exploit appears in the cited materials. CISA’s enrichment reported no known exploitation, and Tenable reported no known exploit availability when it published its check.

No known exploitation is useful context, but it is not evidence that an exposed instance will remain untouched. Authentication weaknesses are easy to understand, and automated login attempts are common across reachable services. CISA separately classified the attack as automatable.

The advisory also does not disclose the number of attempts required, the affected account’s exact permissions, or the complete behavior when redirect handling is disabled. Those omissions limit any attempt to calculate a universal probability of compromise.

Nor does the notice report affected customer counts, public exposure measurements, or confirmed incidents. Claims that thousands of systems are vulnerable would therefore be speculative. Operators should base decisions on their inventory rather than an unsupported global estimate.

This is the skeptical angle that matters most: upgrading closes the disclosed condition, but the public evidence cannot prove that an organization’s whole deployment is safe. Network design, credentials, host controls, and validated shutdown behavior remain outside the narrow CVE fix.

The opposite overclaim is also risky. Nothing in the advisory shows that attackers can directly switch off a UPS, rewrite firmware, or cause a physical power failure. The documented outcome is potential unauthorized access to a PowerChute user account.

Accurate scoping helps response teams act faster. It focuses urgent work on vulnerable application versions and reachable login interfaces. It also prevents dramatic but unsupported claims from distracting owners of the affected systems.

What Operators Should Watch After Version 1.6

Three signals will show whether this remains a contained patching issue or becomes a wider operational security concern.

The first signal is evidence of exploitation. CISA’s initial enrichment recorded no observed exploitation, and the vulnerability was not in its Known Exploited Vulnerabilities catalog at publication. A confirmed incident or catalog addition would materially increase urgency for any remaining version 1.5 installation.

Security teams should monitor vendor updates, CISA notices, and their own authentication logs. Repeated failed attempts from unfamiliar systems deserve investigation, especially when followed by a successful login. Teams should preserve relevant host, firewall, and application records before routine retention removes them.

The second signal is a revision to Schneider Electric’s affected-product or remediation data. The current record identifies version 1.5 and earlier as vulnerable and version 1.6 as fixed across supported Windows and enterprise Linux combinations. Any change to that boundary would require renewed inventory work.

Machine-readable advisory displays can be confusing because they list affected and fixed product branches together. Operators should rely on status fields and remediation text, not a flattened list of version numbers. Schneider Electric’s notice states that version 1.6 contains the fix.

The third signal is operational behavior after deployment. Teams should confirm that the PowerChute service restarts, reconnects to the UPS, retains its intended configuration, and continues reporting events. They should also test the organization’s approved shutdown procedure under controlled conditions.

This validation is not an argument against patching. Power-management software acts during the moment when infrastructure is already under stress. A configuration regression discovered during an actual outage would turn a security update into a continuity problem.

Windows administrators can verify version information in Control Panel or the application’s About page. Linux teams should use their package inventory and the application interface where available. Central asset records should capture the evidence, installation date, and responsible owner.

Organizations that cannot update immediately should restrict access while arranging the change. Place the interface behind a firewall, remove public reachability, limit source networks, and use an updated VPN for necessary remote administration. Strengthen the application credential and review login activity.

These steps are temporary risk reduction, not equivalent remediation. A network rule can drift, a remote endpoint can be compromised, and an account password can leak. Version 1.6 addresses the disclosed authentication weakness at its source.

After upgrading, teams should use the incident as a process test. Did the organization know where PowerChute was installed? Did the advisory reach the correct owner? Could administrators schedule the service restart without uncertainty about the protected workload?

If any answer is no, the durable task extends beyond CVE-2026-13348. Add the software to asset and vulnerability-management systems, assign an owner, document its dependencies, and include it in recurring update reviews.

Schneider Electric PowerChute Serial Shutdown sits between electrical resilience and operating-system availability. That position makes quiet maintenance failures consequential, even when an individual CVE carries a Medium rating.

Check every installation now, upgrade releases through 1.5 to version 1.6, and validate both the software version and UPS communication. Then ask the harder question: if the next PowerChute advisory arrived tomorrow, would your team immediately know every affected system, its exposure, and who can safely update it?