Patch Now: Schneider Electric EcoStruxure Power Build Rapsody Vulnerabilities CVE-2025-13844/13845

Schneider Electric has published coordinated fixes after researchers and internal teams disclosed memory‑corruption vulnerabilities in EcoStruxure Power Build Rapsody that allow specially crafted project (SSD) files to trigger heap corruption, double‑free and use‑after‑free conditions — flaws that, if exploited on engineering workstations, can lead to arbitrary code execution and serious operational risk across energy, manufacturing and commercial facilities worldwide.

Background​

EcoStruxure Power Build Rapsody is Schneider Electric’s engineering tool used to create, import and manage single‑line diagrams and the bill of materials for switchboards and power distribution equipment. The application is commonly used on engineering workstations in industrial and enterprise environments; these machines frequently hold privileged access to operational technology (OT) and control system project files. Because Rapsody’s workflow centers on importing externally created project files, the product’s attack surface for file‑format exploitation is non‑trivial.
Two vulnerabilities were called out in the advisory package:

• CVE‑2025‑13844 — a CWE‑415 double‑free that can cause heap memory corruption when a malicious SSD project file is imported. Successful exploitation could corrupt heap structures and destabilize the process.
• CVE‑2025‑13845 — a CWE‑416 use‑after‑free vulnerability that can be abused by a crafted SSD file to trigger code execution, potentially allowing an attacker to run arbitrary code as the Rapsody process user. This one carries the higher severity rating and elevated impact on confidentiality, integrity and availability.

CISA republished the vendor advisory as part of its ICS advisory stream, emphasizing the cross‑sector exposure (energy, critical manufacturing, commercial facilities) and urging operators to apply vendor updates or mitigations. The vendor and coordination notes identify regional build numbers and explicit patched versions for each language/region build.

---

Why this matters: threat model and operational impact​

Rapsody’s primary interaction model — importing project files (.SSD) — establishes a classic file‑format attack surface. In industrial contexts this vector is meaningful because:

• Engineering workstations routinely receive project files from contractors, OEMs, and cross‑site collaborators, often via removable media or shared drives.
• Many such workstations operate with elevated rights on networks that bridge OT and IT, providing a potential pivot to supervisory systems, historians, or management servers.
• Memory‑corruption bugs (double‑free, use‑after‑free, buffer overflows) historically map to reliable exploitation techniques: once memory manipulation can be shaped, an attacker’s ability to achieve instruction‑stream control grows.

The practical consequences of a successful exploit include local arbitrary code execution on the engineering host, theft or tampering of project data, persistence on engineering systems, and lateral movement into higher‑value OT/IT targets. Given the role of switchboard configuration in physical electrical infrastructures, tampering could extend to supply chain integrity and operational safety if downstream configurations are altered or if attacker‑controlled code is used to disable or corrupt monitoring.

---

What Schneider Electric issued (fixes and guidance)​

Schneider Electric published fixed builds for the affected regional packages and advised immediate update to those builds. The vendor requires restarting the Rapsody service after applying each update. Example fixed builds referenced in vendor guidance include:

• FR V2.8.1.0401
• INT V2.8.6.200
• ES V2.8.5.0301
• BEL(NL) V2.8.3.0201
• BEL(FR) V2.8.8.0201

(Regional mappings vary per CVE and per language build; administrators must match their installed build to the correct vendor fix. Schneider’s published mitigations include the straightforward but critical advice: only open projects from trusted sources and scan project files with up‑to‑date malware tools before opening. Administrators are also told to restart the service post‑installation.
CISA’s advisory reiterates vendor patches and augments vendor guidance with standard ICS hardening guidance: isolate control system networks, minimize exposure, use secure remote access methods, and enforce mobile media sanitation policies.

---

Technical breakdown: CWE‑415 and CWE‑416 in practice​

CWE‑415 — Double Free (CVE‑2025‑13844)​

A double free occurs when the same heap memory block is freed twice. If an attacker can control the timing and contents of heap allocations and deallocations, a second free can corrupt memory‑management metadata or create conditions that an attacker can later exploit to overwrite program control structures. In the Rapsody case, the double‑free is triggered by parsing specific constructs inside an imported SSD file, producing heap memory corruption that may destabilize the process and could — in some exploit chains — be escalated toward code execution. The CVSS for this CVE was published with a medium base score, reflecting the required local user interaction vector and limited immediate confidentiality impact.

CWE‑416 — Use‑After‑Free (CVE‑2025‑13845)​

A use‑after‑free arises when code continues to reference memory after it has been deallocated. If an attacker can cause deallocation and then cause the program to use the freed pointer while also controlling the allocation that occupies that freed memory, they can achieve arbitrary memory corruption and code execution. For Rapsody, crafted SSD content can push execution down paths that use freed objects, and Schneider’s advisory attaches a higher CVSS score to this vulnerability because of the greater potential impact (remote code execution on the local host when a user opens a malicious project).

---

Rapid assessment: exploitability and real‑world likelihood​

• Attack vector: local file import — attacker must supply a malicious SSD file and persuade (socially engineer) an operator to import it, or have the file placed on a host the operator will open. This makes mass remote exploitation less likely but targeted attacks feasible.
• Privileges required: none beyond a user capable of running Rapsody and importing projects; the process runs with user (or higher) privileges on engineering workstations, which is why the impact is severe.
• Known exploitation: as of the published advisory there are no confirmed reports of in‑the‑wild exploitation; however, absence of public reports is not proof of absence — targeted intrusions in OT environments are often detected and remediated without public disclosure. Flagged as no known public exploitation at publication time in coordination notes.

Because exploitation requires human action (opening a file) or a supply‑chain style compromise (infected project file distributed to engineering partners), the most pragmatic attacker profiles are insiders, contractors, or targeted external actors who can convince or trick an operator to open a file. The elevated concern arises from the engineering station’s access to OT assets and the reality that many organizations use shared file exchanges and email for project delivery.

---

What Schneider did well — vendor response strengths​

• Timely fixes for multiple regional builds. Schneider produced fixes mapped to the product’s regional and language builds rather than a one‑size‑fits‑all drop; this reduces the chance of applying an incompatible patch to a production environment.
• Clear immediate mitigations. Vendor guidance to scan files and only open trusted projects is pragmatic and can be implemented very rapidly in operational settings.
• Coordination with national CSIRTs. The advisory was republished in CISA’s ICS advisories, providing broader visibility and consolidating vendor recommendations with national guidance — useful for operators who follow CISA notifications.

---

Where residual risk remains — critical weaknesses and operational friction​

• Local vector is deceptively powerful. Engineering workstations are often less hardened than servers and can be used to bridge OT and IT networks; a local exploit on such a host can be an effective pivot. The advice to open only trusted files is necessary but not sufficient if supply‑chain or contractor processes are weak.
• Patch management complexity. Multiple language/region builds mean patching requires precise build‑matching and careful change control; this can delay remediation in tightly controlled OT maintenance windows.
• Potential for incomplete mitigation. Relying solely on file scanning and “trusted sources” leaves gaps: modern file obfuscation and weaponized documents can evade signature‑based scanning; behavioral protections and sandboxing are also needed.
• Restart requirement and service availability. The vendor explicitly instructs service restart post‑installation; in 24/7 industrial operations, scheduling restarts can be nontrivial and increases window of exposure.

Given these realities, organizations must combine patching with structural mitigations that assume some level of human fallibility.

---

Actionable remediation roadmap (for IT/OT teams)​

• Inventory and triage
• Identify all hosts running EcoStruxure Power Build Rapsody and record exact build strings (language/region tags and full version numbers).
• Prioritize engineering workstations that have network access to OT assets and servers.
• Acquire vendor fixes
• Download the appropriate fixed build matching your regional/language installation.
• Verify file integrity (checksums) before deployment.
• Stage and test
• Apply the update in a test segment or on a single non‑production workstation.
• Validate typical workflows (project import/export, BOM generation) and confirm no regressions.
• Deploy and restart
• Schedule a controlled maintenance window.
• Install the fix and restart the Rapsody service as indicated by the vendor. Confirm successful service start and baseline log health.
• Hardening and compensating controls (immediate and long term)
• Restrict which users can import projects; enforce least privilege for Rapsody users.
• Block project import from unvetted network shares; require sealed, scanned transfer channels (SFTP, signed containers).
• Enable endpoint behavioral monitoring and EDR on engineering workstations to detect anomalous child processes, suspicious memory modifications, or unexpected service behavior.
• Use application allow‑listing to prevent unknown binaries from executing on engineering machines.
• Establish a sandboxed VM or isolated workstation where untrusted project files can be opened for validation prior to importing into production systems.
• Enforce strict removable‑media policies and scan all media prior to use.
• Detection and logging
• Tailor SIEM rules for indicators such as Rapsody process crashes, unexpected memory exceptions, new persistence artifacts, or unusual outbound network connections from engineering hosts.
• Collect and retain import‑action logs and project metadata to support rapid incident triage.
• Incident playbook update
• Add Rapsody project file compromise to your OT incident response procedures and rehearse steps for isolating an infected engineering host, purging compromised project files, and re‑provisioning a clean build.

---

Short‑term mitigations if you cannot patch immediately​

• Only open SSD project files from known, authenticated sources; quarantine and scan all externally sourced files with multiple AV/EDR engines.
• Open suspect files in a transient sandbox or VM that is isolated from both the corporate network and any OT segments. Do not import files directly on production engineering workstations.
• Block inbound connectivity to engineering workstations from untrusted networks and restrict outbound connections to strictly required management endpoints.
• Apply the principle of least privilege: remove local admin from daily engineering accounts and require separate, audited accounts for maintenance tasks.

---

Detection indicators and forensics checklist​

• Rapsody process crashes or repeated exceptions immediately after a project import operation.
• Creation of unexpected child processes or spawning of command interpreters originating from Rapsody.
• New or modified autorun entries, scheduled tasks, or services on the engineering workstation following an import action.
• Outbound network connections from the engineering host to unknown addresses shortly after import.
• Unusual modifications to project files stored in shared repositories, or sudden re‑distribution of the same SSD file to multiple sites.

For any suspected compromise, isolate the host, preserve memory and disk images, and forward artifacts to your incident response and cyber‑forensic teams for analysis and coordinated disclosure.

---

Coordination, disclosure and the broader ecosystem​

Schneider Electric’s CPCERT coordinated disclosure to CISA and acknowledged reporting from independent researchers including Trend Micro’s Zero Day Initiative collaborators and other reporters. This multi‑party reporting model is standard for ICS vulnerabilities and increases confidence that the technical details and remediation mapping have been validated by several actors. Organizations should treat vendor advisories and government advisories together — vendor patches provide the fix, while national CSIRT guidance provides operational‑risk context and recommended mitigations.
Be aware that patch availability and build numbering vary by regional package; confirmation of the exact installed build is essential before applying any update to avoid deployment errors.

---

Verification status and caveats​

The advisory package and coordinated republishing to CISA were used to verify the core technical claims in this analysis. The most load‑bearing statements — the presence of CWE‑415 and CWE‑416 defects, the affected product builds, and the fixed version identifiers — are documented in the vendor advisory and republished CISA advisory. Where advisories state “no known exploitation at time of publication,” that reflects public reporting status; defenders should account for the possibility of undisclosed targeted exploitation and operate with a defensive presumption of compromise if exposures are observed.
If organizations require further verification for audit or compliance purposes, they should request vendor assurance artifacts (signed release notes and checksums) and corroborate fix hashes before deployment.

---

Practical checklist for Windows/IT teams responsible for Rapsody hosts​

• Inventory: Record all Rapsody hostnames, owner groups, installed build, and connectivity to OT assets.
• Patch: Download the matching fixed build for each installed language/region package; apply in test, then production.
• Restart: Follow vendor instruction to restart the Rapsody service after patching.
• Harden: Apply EDR, application control, and restrict user privileges.
• Isolate: Ensure engineering hosts are segmented from the wider enterprise and from internet‑accessible networks.
• Monitor: Add SIEM rules around imports, crashes, and unusual process activity.

---

Final assessment and recommendation​

The reported vulnerabilities in EcoStruxure Power Build Rapsody (double‑free and use‑after‑free on SSD project import) present a credible and actionable risk for organizations that rely on Rapsody for engineering work. While the exploitation vector is local file import — not directly remote network exposure — the operational context of engineering workstations means that the impact of a successful attack can be high.
Action priorities for defenders:

• Treat this advisory as urgent: inventory affected hosts and plan patch deployment immediately.
• Combine patching with structural mitigations: isolate engineering hosts, enforce least privilege, and deploy behavioral detection to catch anomalous process or memory behavior.
• Use sandboxing or isolated VMs for handling untrusted project files, and update organizational file‑exchange workflows to reduce reliance on ad hoc sharing.

By applying vendor fixes promptly and layering compensating controls, organizations can substantially reduce the window of vulnerability and limit the operational risk posed by these memory‑corruption flaws.

---

Keep patch records, restart confirmations, and verification checksums with your change control tickets so auditors and incident responders can confirm that each impacted host was remediated according to vendor guidance.

---

Source: CISA Schneider Electric EcoStruxure Power Build Rapsody | CISA