AVEVA’s Edge HMI/SCADA tool has a new, high‑impact vulnerability that shifts the conversation from “can project files be tampered with?” to “can project files leak live credentials?” — and the short answer is yes, unless operators act now to apply the vendor fix and harden access to project files.
Background / Overview
AVEVA Edge (formerly InduSoft Web Studio) is an HMI/SCADA runtime and engineering suite widely used in critical manufacturing and industrial automation. The product family sits on the Windows engineering/operations stack: engineers design projects on Windows workstations, save them as project files, and deploy runtimes to operator consoles and thin clients across plant networks. AVEVA and national cybersecurity authorities have repeatedly published advisories affecting Edge and companion AVEVA products over the last few years, showing both the product’s broad deployment and the operational sensitivity of project files and runtime caches. In mid‑2025 a new advisory described a weakness in how Edge handles and stores password material inside project artifacts and offline cache files. The vulnerability has been tracked as CVE‑2025‑9317 and was published as part of an AVEVA security bulletin and re‑distributed in national advisories. The core danger: an attacker or insider with read access to project files or Edge’s Offline Cache could run offline, computational brute‑force attacks against
weak password hashes embedded in those files and recover application‑native or Active Directory passwords. That recovered credential material can allow privilege escalation, lateral movement, and unauthorized control actions in OT environments.
What the advisory says (concise summary)
- Affected product: AVEVA Edge (HMI/SCADA authoring and runtime). The advisory specifically calls out Edge: Versions 2023 R2 and prior as being affected until the P01 security update is applied.
- Vulnerability class: Use of a broken or risky cryptographic algorithm — i.e., password hashes in project/offline cache files use weak algorithms and predictable or low‑entropy salts that make offline cracking realistic with modern GPU tooling.
- Assigned identifier: CVE‑2025‑9317. Public advisories report CVSS scores in the high‑8 range (CVSS v3.1 ≈ 8.4; CVSS v4 ≈ 8.3) and emphasize local attack vector with low attack complexity, high confidentiality impact, and no integrity/availability impact associated directly with the hashing weakness.
- Primary exploit scenario: an actor who can read Edge project files (for example, via stolen backups, shared project repositories, removable media, or a compromised workstation) extracts stored hashes and performs offline brute‑force/wordlist attacks to recover plaintext passwords. The advisory notes the weakness is not exploitable remotely by itself — the attacker needs file read access.
Why this matters: operational impact and threat models
Short explanation of the technical risk
Weak hash functions and low‑entropy salts reduce the time and resources needed to obtain plaintext from stored password digests. Where secure systems use memory‑hard algorithms (bcrypt, Argon2, PBKDF2 with high iteration counts) and strong salts, an attacker with a hash must invest a prohibitive amount of compute to recover a password. When hashes are weak (or unsalted/predictably salted), modern GPU clusters and optimized cracking tools can recover many passwords cheaply and quickly. AVEVA Edge project files and offline cache can therefore act as a low‑cost goldmine for credential harvesting if they contain such weak hashes.
Practical offender playbook
- Obtain a copy of an Edge project file, a backup, or the Edge Offline Cache from a development or runtime host. Delivery vectors include stolen backups, contractor file exchanges, compromised engineering workstations, or misconfigured SMB shares.
- Locate the stored password hashes inside the project/offline cache format. These are typically readable once the file is opened or parsed; the advisory indicates these are not protected by a strong crypto wrapper.
- Use optimized cracking tools and wordlists (or targeted password lists for industrial operators) to brute force the hash. Weak algorithms and small salts make this tractable.
- Reuse recovered credentials against local HMI runtimes, engineering tools, or Active Directory accounts to access systems, change configurations or push malicious projects — the classic chain from data disclosure to operational compromise.
Who is at risk
- Engineering workstations and Windows servers that host project files or run Edge development tools.
- Production operator stations and thin clients that retain Offline Cache files containing password digests.
- Organizations that share project files with contractors or keep unprotected backups in network shares.
- Facilities with weak segmentation between corporate/IT and OT networks, where recovered credentials could be reused on higher‑value infrastructure.
Technical details (deep dive)
What is exposed in the file formats
The advisory indicates Edge project files and Offline Cache files contain stored password hash material for both native Edge application users and potentially for Active Directory–linked accounts. Those stored hashes are produced by AVEVA’s internal password‑handling implementation and — crucially — the implementation uses a hashing algorithm or configuration judged
insufficiently strong by modern standards. The advisory does not publish the exact hashing algorithm or iteration counts, likely to avoid enabling faster cracking during coordinated disclosure. That omission means operators must assume the worst‑case (i.e., hashes are trivially crackable) until they can inspect patched project exports or vendor documentation.
Attack vector and prerequisites
- Attack Vector: Local file read (AV:L). An attacker needs read access to project files or caches. That could be local or via file‑share access over the network.
- Privileges: Low privileges may be sufficient if the attacker can read files stored by less‑privileged users. The advisory rates privileges as limited (PR:L).
- Complexity: Low — offline cracking toolchains are widely available, and when hashes are weak, the operation is computationally inexpensive.
CVSS context
CISA and vendor notes put the base CVSS scores in the high‑8 range — these numeric ratings reflect high confidentiality impact (exposed passwords) paired with a non‑remote vector and low attack complexity. The industry increasingly reports both CVSS v3.1 and v4.0 vectors; the advisory lists both to help operators integrate the finding into modern risk models. Treat these scores as
directionally severe: the business risk comes from credential reuse and lateral movement following recovery, not from a simple remote exploit.
Mitigations: immediate, short‑term and strategic
AVEVA and CISA recommend a combination of vendor patching, access control and operational hygiene. The following is a prioritized, pragmatic playbook for Windows and OT teams.
Immediate actions (0–72 hours)
- Apply AVEVA Edge 2023 R2 P01 Security Update where possible — this is the vendor’s published fix that changes the hashing behavior and requires migration of older project files. If production constraints prevent immediate patching, prioritize the most exposed hosts and accounts.
- Force password resets for all AVEVA Edge user accounts and any local accounts discovered in project files or offline caches. Treat exposed hashes as fully compromised.
- Stop sharing project backups and move any shared copies to a secured, auditable repository with ACLs and encryption at rest. Remove legacy backups from accessible network shares and edge devices.
Short‑term operational controls (1–14 days)
- Apply strict Access Control Lists (ACLs) to every folder where project files and Offline Cache files are stored. Restrict read permissions to only authorized engineering and maintenance personnel.
- Establish a trusted chain-of‑custody for project files: track creation, modification, distribution and deployment events in a central log or versioned repository. Prevent ad hoc transfers via USB and uncontrolled email attachments.
- Remove embedded passwords from scripts, worksheets and function parameters inside project documents. Replace them with project tags or secure, centralized credential stores where possible. The advisory explicitly recommends tags over inline passwords.
Medium and long‑term hardening (2–12 months)
- Migrate all persistent production projects to the new format created by Edge 2023 R2 P01 — note that migration is one‑way, meaning older runtimes may not be able to open migrated projects. Plan validation and rollback testing accordingly.
- Demand and verify that vendors use memory‑hard password hashing (Argon2, bcrypt/BCryptPHC, or PBKDF2 with high iteration counts) and unique cryptographic salts for all stored credentials going forward. Where cryptographic choices are undisclosed, treat stored secrets as compromised until proven otherwise.
- Segment engineering and runtime hosts into dedicated OT subnets with tightly controlled jump hosts and multi‑factor authentication (MFA) for any access that crosses boundaries. Minimize direct SMB, RDP or file share exposure between IT and OT networks.
Detection and incident response guidance
- Inventory and triage: locate every file with project extensions and any Offline Cache on engineering stations, jump hosts and thin clients. Hash filenames and collect last‑modified timestamps; move copies to a secured staging area for safe analysis.
- Treat suspected leakage as a compromise: rotate passwords, disable accounts used by Edge until the environment is patched and verified. Preserve disk images for forensics if you suspect an intrusion.
- Monitor for abnormal logins or lateral movement: correlate Active Directory logs, Windows Event Logs, and AVEVA audit trails (if enabled) for authentication successes from unexpected hosts. Set SIEM alerts for anomalous use of privileged accounts.
- Detection signatures: create alerts for large reads of project directories, unexpected exports of .apj/.prj or cached files, and sudden creation of archive files that are transferred offsite. Audit PowerShell or other scripting activity near project file folders.
Cross‑checks, verification and limits of public information
- The advisory text and CVE assignment are public; national sources (CISA mirrors and advisories) and secondary aggregators have republished the finding. However, the vendor did not publish exact hashing algorithm details or iteration counts in the initial advisory — this is a deliberate information‑control choice common in coordinated disclosures. Operators should therefore treat exposed hashes as fully compromised until they can verify the patched behavior or vendor‑supplied migration reports.
- Independent vulnerability writeups and industry trackers have repeatedly shown that weak hashing in ICS tooling is a recurring failure mode; multiple earlier advisories documented similar weaknesses in other vendors’ products and the same operational mitigations (patching, segmentation, access control) apply here. Cross‑referencing those precedents helps prioritize the response but does not reduce the need for immediate remediation of Edge installs.
- Where claims in third‑party writeups are vague or incomplete (for example, statements that “passwords were trivially cracked in minutes”), label those as operational examples rather than universal outcomes. The offline cracking speed depends on password complexity, salt quality and hash configuration — which the vendor has not fully disclosed — so actual recovery times vary. In practice, however, many industrial passwords are short or patterned, which makes them especially susceptible to offline cracking when hashes are weak.
Practical checklist for Windows/OT administrators (actionable sequence)
- Identify all hosts running AVEVA Edge (development, runtime, thin clients) and inventory project file locations.
- Back up project files securely, then restrict all access to those backups; ensure backups are encrypted and access‑logged.
- Apply AVEVA Edge 2023 R2 P01 Security Update where feasible and validate project migration on a test system.
- Rotate AVEVA Edge user passwords and any linked AD accounts after patching or after confirmed project migration. Treat all exposed hashes as compromised prior to rotation.
- Block or isolate hosts that must remain unpatched until they can be upgraded: place them behind jump hosts, restrict network access, and enforce multifactor authentication for maintenance.
- Remove embedded plaintext or inline passwords from projects; convert to token/tag‑based references and secure credential vaults.
- Implement file‑access monitoring and SIEM alerts for suspicious exports or reads of project directories.
- Validate your incident response runbook for OT events and preserve forensic evidence if you suspect data exfiltration.
Critical analysis: vendor response, strengths and residual risks
Strengths
- The vulnerability was assigned a CVE and published through coordinated channels, which is the correct disclosure process for OT‑relevant bugs. That enables customers to track the issue and plan patching.
- AVEVA released a security update (2023 R2 P01) and provided migration guidance; the fix addresses the root cause by changing how password material is hashed and stored, which is the right engineering remedy instead of a simple ACL‑only mitigation.
Residual and systemic risks
- One‑way migration: migrating older projects to the new hash scheme may be irreversible. Organizations that retain archived project files for rollback or legal reasons must lock down those artifacts carefully because they remain readable and vulnerable. Operational realities make it hard to guarantee that every backup is protected.
- Human and supply‑chain factors: engineering projects routinely move between OEMs, contractors and third‑party integrators. Each handoff creates exposure points. Even well‑patched installations can be compromised if a contractor’s workstation holds an old, unprotected copy.
- Lack of full cryptographic transparency: because vendors sometimes withhold exact algorithm and salt details until after a patch, operators cannot fully quantify how easy it would have been to crack specific hashes in their environment. The safe operational stance is to assume weak hashes are recoverable and rotate credentials accordingly.
Detection, monitoring and longer‑term resilience measures
- Harden engineering workstations: apply Windows hardening baselines, ensure host EDR/AV is running and up to date, restrict administrative rights on engineering machines, and block unsanctioned USB devices.
- Version control and artifact signing: store projects in a secured version control system with strict access control and binary signing to detect tampering; do not use ad hoc file sharing for production projects.
- Centralized secret management: shift credentials out of project files into centralized vaults that support access logging and short‑lived credentials. This reduces the blast radius of any file disclosure.
- Crisis rehearsals: conduct tabletop exercises for OT breaches that begin with project file compromise; test password rotation, rollback plans and supplier notifications. These rehearsals should include Windows administrators, OT engineers, and legal/PR teams.
Conclusion
CVE‑2025‑9317 is a timely reminder that files normally considered “configuration” can be as dangerous as exposed databases when they contain sensitive secret material. The technical fix exists — AVEVA’s 2023 R2 P01 update — but real risk remains in unpatched hosts, archived project files, and contractor workflows that routinely move sensitive engineering artifacts. The operational imperative is clear: apply the vendor update where possible, treat all pre‑patch project files as compromised until proven otherwise, enforce strict ACLs and custody for project artifacts, and rotate any exposed credentials immediately. These steps will materially reduce the chance that a leaked project file becomes a foothold for a much larger OT incident.
Source: CISA
AVEVA Edge | CISA