CVE-2025-9317: Patch AVEVA Edge and Schneider Tools After MD5 Hash Exposure

Schneider Electric and AVEVA have confirmed a high‑severity cryptographic weakness that exposes password hashes inside Edge project and offline cache files — CVE‑2025‑9317 — and Schneider Electric has released patches for EcoStruxure Machine SCADA Expert and Pro‑face BLUE Open Studio; operators must treat exposed project files as compromised, apply vendor updates, and follow a prioritized incident and mitigation playbook immediately.

Background / Overview​

On 11 November 2025 AVEVA published Security Bulletin AVEVA‑2025‑006 identifying a critical weakness in AVEVA Edge (formerly InduSoft Web Studio): project files and offline cache files store password hashes generated with the MD5 hashing algorithm. AVEVA assigned the issue CVE‑2025‑9317 and rated it High (CVSS v3.1 8.4, CVSS v4 8.3). Schneider Electric followed with a coordinated advisory (SEVD‑2025‑315‑02, published 11 November 2025) confirming that Schneider products that embed the affected AVEVA component — notably EcoStruxure Machine SCADA Expert and Pro‑face BLUE Open Studio — are impacted when running versions prior to 2023.1 Patch 1. Government and vulnerability databases (NVD, CISA) published the CVE and scoring later in mid‑November 2025.
This is not a remote, unauthenticated backdoor: the weakness is local‑access oriented. However, the real operational risk is significant because project files and offline caches are commonly stored on engineering workstations, file servers, removable media, and shared network shares — all places where an attacker or careless administrator can gain read access. Once an attacker obtains the stored MD5 hashes, modern cracking tools and GPUs can brute‑force or dictionary‑attack weak or reused passwords quickly. The outcome can be credential compromise (local app accounts or even Active Directory passwords), lateral movement, and unauthorized modification of HMI/SCADA projects.

---

What the vendors and authorities confirmed​

• AVEVA explicitly documented that project files and offline cache files contain hashes generated with MD5, and that the weakness could allow a local user with read access to reverse‑engineer both app‑native and Active Directory credentials via brute‑force. The AVEVA bulletin was published 11 November 2025 and instructs customers to apply AVEVA Edge 2023 R2 P01 and migrate old project files; it also warns migrations are one‑way due to the new hashing approach.
• Schneider Electric’s security notification (SEVD‑2025‑315‑02) published 11 November 2025 confirms that its EcoStruxure Machine SCADA Expert and Pro‑face BLUE Open Studio offerings that include the affected AVEVA component are vulnerable in versions prior to 2023.1 Patch 1, and that Schneider’s Patch 1 addresses the issue for those products.
• CISA and national vulnerability databases published coordinated advisories and the CVE entry (CVE‑2025‑9317), and noted there were no known reports of in‑the‑wild exploitation at the time of publication. Multiple vulnerability trackers and vendors reproduced the technical summary and scoring.

These independent confirmations (vendor bulletins and government advisories) remove ambiguity about the root cause (weak cryptographic hashing) and the recommended primary remedy (apply vendor patches and migrate project files).

---

Technical breakdown: what’s wrong and why it matters​

MD5 as a password hash — why this is dangerous​

MD5 is a legacy cryptographic hash function that is cryptographically broken for modern security needs. While MD5 collisions have been known for years, the immediate problem here is that MD5 is:

• Extremely fast and unsalted in many legacy uses, which makes it trivially amenable to brute‑force and dictionary attacks on modern GPUs.
• Not designed for password hashing; it lacks built‑in iteration counts, memory hardness, or salt mechanisms that slow down brute‑force attempts (unlike Argon2, bcrypt, scrypt, or PBKDF2 with high iteration counts).
• Widely supported by cracking tools (Hashcat, John the Ripper), enabling attackers to run massively parallel attacks using common wordlists and targeted password lists.

AVEVA’s bulletin specifically notes “Passwords hashed with MD5” in the affected project files and offline caches. That explicit confirmation elevates the urgency: any hash extracted from those files should be assumed crackable until proven otherwise.

Attack vector, privileges, and scope​

• Attack vector: Local read access to project files or offline cache files. This includes local attackers, low‑privileged users on engineering workstations, contractors with file access, or an adversary who obtains backups or removable media.
• Privileges required: Low privileges (read access). No privilege escalation prerequisite is required to obtain and crack hashes if file reads are allowed.
• User interaction: None required beyond the attacker obtaining the file(s).
• Impact: Confidentiality and integrity — compromised credentials can be reused to access HMI/engineering tools, reconfigure devices, upload malicious projects, or move laterally to higher‑value targets (including AD‑joined servers).
• Exploitability: Low attack complexity; once hashes are in hand, automated cracking workflows can reveal passwords quickly if the passwords are weak or reused.

Why project/offline cache files are high‑value targets​

Project files are frequently copied, archived, and moved between development, testing, and production environments. Offline caches are often stored on operator terminals and thin clients to speed operations. These files therefore proliferate beyond tightly controlled engineering systems — they show up on file shares, backup tapes, contractor laptops, and removable storage. An attacker who harvests these files can run offline cracking campaigns at scale without touching the operational network again.

---

Confirmed scope and affected software​

• AVEVA Edge (InduSoft Web Studio): All versions up to and including 2023 R2 are affected; AVEVA published 2023 R2 P01 as the remediation that changes hashing behavior and requires project migration.
• Schneider Electric: EcoStruxure Machine SCADA Expert and Pro‑face BLUE Open Studio that use the affected AVEVA component are vulnerable when running versions prior to 2023.1 Patch 1; Schneider published 2023.1 Patch 1 for affected products and recommends applying that patch.

Operators should assume any deployment that contains project/offline cache files exported or saved before the patched versions may contain MD5 hashes and therefore be at risk.

---

Immediate actions (0–72 hours) — prioritized incident playbook​

Treat this as an operational compromise if you have pre‑patch project files in accessible storage. The following steps are ordered and practical for Windows and OT teams:

• Apply the vendor patches as the top priority:
• If running AVEVA Edge: apply AVEVA Edge 2023 R2 P01 (or later) and migrate project files per the vendor guidance.
• If running Schneider EcoStruxure or Pro‑face BLUE: apply 2023.1 Patch 1 provided by Schneider Electric.
• If immediate patches cannot be deployed to production systems, isolate the most exposed hosts and storage containing project files (segment or take them offline) and restrict access to a minimal, auditable set of engineering accounts.
• Identify and inventory all project files, offline cache locations, backups, and removable media across the environment. Assume every pre‑patch copy is potentially compromised.
• Force a password reset for:
• All users with credentials stored in affected project or cache files.
• Any system or service accounts that may have been embedded or referenced.
  Resetting credentials eliminates immediate reuse of any cracked password.
• Apply strict Access Control Lists (ACLs) to every folder that contains project files and caches; remove read permissions for everyone except a tightly controlled engineering group.
• Suspend further sharing of project files via uncontrolled channels (email, shared drives without logging, contractor FTP) — move to an auditable repository with encryption and version control.
• Remove inline passwords from scripts, worksheets, and function parameters inside projects — replace with secure tags or centralized credential services where practical.
• If you suspect files may already have been accessed by unauthorized actors, treat this as a potential incident: preserve evidence, collect indicators, and follow internal incident response and reporting processes.

---

Short and medium‑term remediation and hardening (3–30 days)​

• Migrate all projects to the patched product format. Note that AVEVA warns migration is one‑way; test migration in a staging environment before applying to production to avoid irreversible breakage.
• Implement project‑level encryption and a strong master password for project data where supported. Use the vendor‑documented “Data Protection”/project options.
• Remove any embedded or hardcoded credentials; adopt a centralized credential manager (vault), or use secure project tagging and runtime retrieval methods.
• Rotate credentials again after migration and after confirmation that backups and archived copies are cleaned, moved to secure storage, or destroyed.
• Enforce strong password policies and multifactor authentication for engineering accounts and any accounts that can access development systems.
• Scan backups and shared storage for legacy project files and apply ACLs or delete/replace old copies securely.

---

Detection, monitoring and threat hunting steps​

• Search Windows file servers, engineering workstations, and backup repositories for AVEVA/InduSoft project file extensions and offline cache files. Create a file inventory and categorize by last modification date and owner.
• Enable logging and monitor access to folders that store project files; set alerts for anomalous read or copy activity outside normal engineering hours.
• Use file integrity monitoring to detect unplanned copies or exfiltration of project files.
• Correlate authentication events and newly observed logins from engineering accounts with file access events — look for unusual use following password resets.
• If hashes have been extracted or suspicious copies are detected, consider a proactive password audit: simulate a cracking attempt on a copy under controlled, authorized conditions to determine exposure level; treat any cracked credential as compromised.

---

Operational & procedural considerations​

• The AVEVA migration is irreversible: once a project is migrated to the new, stronger hashing scheme, AVEVA states the process cannot be reversed. Therefore, validate migration in a test environment and keep an archived pre‑migration copy stored securely (with limited access and encryption) in case rollback or forensic analysis is required.
• Treat any pre‑patch project file as a potential indicator of compromise. Even if a particular hash resists cracking today, the ability to store hashes offline allows attackers to mount cracking campaigns later when compute power or time increases.
• Update supplier and contractor handling procedures: require encrypted transport and explicit ACL policies for project file exchanges. Do not accept ad hoc email attachments or USB deliveries of project files.
• Coordinate password rotation with operational windows. For AD accounts that are rotated, ensure automation and service dependencies are updated to prevent outages.

---

Technical controls that reduce similar risks long term​

• Require vendors to move password storage to modern, memory‑hard password hashing algorithms: Argon2id, bcrypt, or scrypt with sufficiently high parameters; use per‑user salts and iteration counts appropriate for the threat model.
• Enforce least privilege for engineering workstations; split duties between development and deployment systems (do not allow development workstations on production control networks).
• Use containerized or sandboxed engineering tools where possible, host shared services on hardened servers, and disable offline cache where it isn’t operationally required.
• Apply file‑level encryption (at rest) on repositories containing project files and enforce strict key management tied to roles.

---

Practical checklist for Windows/OT administrators (one‑page quick actions)​

• Patch: Apply AVEVA Edge 2023 R2 P01 (AVEVA) and Schneider Electric 2023.1 Patch 1 (for affected EcoStruxure / Pro‑face BLUE) immediately where possible.
• Inventory: Find all project/offline cache files across servers, workstations, backups, and removable media.
• Isolate & Restrict: Restrict access to those folders with ACLs; isolate critical hosts pending patch.
• Rotate: Force password resets for all accounts referenced or likely stored in projects (including AD accounts if implicated).
• Migrate & Test: Migrate projects using vendor tools in a staging environment; document the one‑way migration impact.
• Remove inline secrets: Replace passwords inside scripts with secure vault retrievals or tags.
• Monitor: Audit access to project repositories; deploy alerts for anomalous behaviors.
• Document: Log every remediation step, file movement, and user password change for compliance and forensic trail.

---

How serious is this? Risk evaluation and likely attack outcomes​

This vulnerability ranks as High because it directly exposes credential material that can be reused across environments. The real-world impact depends on the following variables:

• Password strength and reuse: weak or reused passwords are quickly recovered. If engineering staff reuse AD or privileged passwords inside project files, an attacker could escalate into domain or supervisory systems.
• File proliferation: the more widely project files are copied and shared, the larger the attack surface. Many organizations keep project copies on shared drives or contractor laptops — that increases risk dramatically.
• Segmentation and controls: environments with strict network segmentation, tight ACLs, and vaulting of credentials reduce likelihood of follow‑on compromise even if a hash is obtained.
• Detection and response readiness: organizations with active monitoring and rapid incident response can limit damage by expediting password rotations and patching.

Short version: the technical barrier to abuse (once a file is read) is low, and the consequences can be severe in OT environments where credential reuse and weak segregation are common.

---

What’s not (and cannot be) verified from public advisories​

• The exact distribution of affected installations worldwide and how many project files contain weak MD5 hashes are not published; vendors do not disclose counts of impacted customers.
• The precise cracking difficulty for any specific hash depends on unknowns such as whether salts were used, salt length, password complexity, and whether iteration or obfuscation was applied. AVEVA disclosed MD5 but has not published iteration counts or salt details in the public bulletin—this omission is deliberate to avoid enabling mass cracking during coordinated disclosure.
• No confirmed public exploits were reported at the time the advisories were published; that does not prove the vulnerability was never targeted previously or that private actors have not abused discovered hashes.

Flagging these unknowns is important — defenders should assume worst‑case exposure of password material until proven otherwise.

---

Practical examples: what an attacker would do (simplified)​

• Locate or obtain a copy of a project file/offline cache from a shared folder, backup, or removable media.
• Extract stored hash strings from the file format (file formats are often parseable or documented).
• Feed the hash into a cracking pipeline (Hashcat/John) using targeted wordlists, rule sets, and GPU acceleration.
• If the password is recovered, attempt to reuse it against the HMI runtime, engineering tool login, or associated Active Directory account.
• If successful, escalate privileges and perform malicious project uploads, configuration changes, or lateral movement to process control servers.

This is not theoretical — it is a standard attack chain for credential harvesting from offline file formats. The MD5 weakness simply makes step 3 much easier.

---

Final assessment and recommendations​

This vulnerability is a textbook example of how legacy cryptography embedded inside traditionally offline or “closed” industrial formats becomes a modern attack vector once files escape strict controls. The combination of MD5 password hashing, the ubiquity of project and offline cache files, and common operational practices (file sharing, backups, contractor exchanges) creates a credible and actionable threat.
Immediate priorities for affected organizations:

• Patch now with the vendor fixes (AVEVA Edge 2023 R2 P01; Schneider 2023.1 Patch 1) and plan careful, tested project migrations.
• Assume compromise of pre‑patch project files; rotate credentials and tighten ACLs and chain‑of‑custody on project artifacts.
• Remove inline secrets; move to secure vaulting or project tagging. Test migrations in non‑production environments because AVEVA identifies migration as one‑way.
• Harden detection: inventory files, monitor access, and treat large off‑network cracking campaigns as real threats.

Operators who act quickly — patching, rotating credentials, and reducing the spread of unprotected project files — will dramatically reduce their exposure. For OT and industrial environments, the simple lesson is clear: legacy cryptography in configuration or project files is not a benign artifact — it is a persistent attack surface that must be eliminated or strictly controlled.

---

Source: CISA Schneider Electric EcoStruxure Machine SCADA Expert & Pro-face BLUE Open Studio | CISA