CISA published ICSA-26-225-01 on August 13, alongside AVEVA’s own security bulletin AVEVA-2026-005, disclosing CVE-2025-7639 — an insecure deserialization vulnerability in AVEVA Enterprise SCADA. The CVSS v3.1 score sits at 7.1 (High), with a vector of AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:H: network-exploitable, high attack complexity, low privileges required, no user interaction, unchanged scope, and a combination of limited confidentiality impact with high integrity and availability impact. That profile — low privilege in, code execution out — is exactly the kind of escalation path that matters most in SCADA environments, where the gap between “operator” and “engineer” access is supposed to be a hard boundary, not a suggestion.
Enterprise SCADA is AVEVA’s rebrand of Citect SCADA, one of the longest-running SCADA platforms in the industry, still widely deployed across mining, water treatment, oil and gas midstream, and manufacturing sites that have run Citect-derived architecture for two decades or more. The affected version range in the advisory spans Enterprise SCADA 2025, all releases from 2024 back through 2021_SP2_P5, and the corresponding Enterprise SCADA HMI builds — meaning this bug has been present across roughly four years of shipped releases before disclosure.
Technical Details
The vulnerability is a classic CWE-502 (Deserialization of Untrusted Data) flaw. Enterprise SCADA uses serialized object data internally to pass state and configuration between components of its “DNA” application framework — the underlying architecture that governs role-based access via named security groups such as “DNA Authority - Operator” and “DNA Apps.” According to CISA’s advisory, an attacker who already holds valid credentials with the DNA Authority - Operator role — a role intended for day-to-day supervisory control, not system administration — can craft and submit tampered serialized data to a component that deserializes it without adequate validation. Because deserialization happens under the privileges of the DNA Apps security group rather than the submitting operator’s own role, successful exploitation results in code execution at a privilege level the attacker was never authorized to reach.
This is a privilege escalation bug wearing a remote-code-execution vulnerability’s clothes. The attack complexity is rated high specifically because building a working malicious payload against a proprietary serialization format requires nontrivial reverse-engineering effort — there’s no public exploit at time of writing, and CISA notes no known exploitation in the wild. But attack complexity is not the same as low risk in this case: once an attacker holds any operator-level credential, whether through phishing, credential reuse, or an insider with limited authorization, the DNA Apps group’s broader reach is exposed to them.
Why This Matters for OT
Role separation is one of the few practical controls SCADA platforms offer to limit blast radius when credentials are inevitably compromised or misused. Enterprise SCADA’s DNA Authority model exists precisely so that an operator seat — used for acknowledging alarms, adjusting setpoints within bounds, and viewing process graphics — cannot be leveraged into engineering-level changes to control logic, historian configuration, or application deployment. CVE-2025-7639 collapses that separation. In a Citect-derived environment where dozens of shift operators hold credentials with far broader network reach than any single engineer needs, this converts a routine operator account compromise into a path toward tampering with SCADA application behavior across the DNA Apps scope.
The sectors most exposed are the ones where Citect/Enterprise SCADA has the deepest install base: mining and mineral processing, water and wastewater treatment, oil and gas gathering and midstream operations, and discrete and process manufacturing sites that adopted Citect in the 1990s and 2000s and have upgraded in place rather than migrating platforms. Many of these sites run flat or loosely segmented networks between the SCADA server and operator workstations, which means credential theft via phishing against a control room operator is a realistic and low-cost initial access vector — the escalation this CVE enables would then let that same attacker reach beyond what the stolen credential should have permitted.
Remediation
AVEVA’s bulletin directs affected users to evaluate exposure against their specific deployment and plan an upgrade to a fixed release; AVEVA support should be engaged for guidance on which build resolves the flaw for a given version line, since the affected range spans multiple major releases with different patch paths. Until upgrades are complete:
- Inventory every Enterprise SCADA and Enterprise SCADA HMI instance and confirm exact version against the affected range (2021_SP2_P5 through 2025).
- Review DNA Authority group membership and strip Operator-level accounts down to the minimum role scope actually required; audit for shared or generic operator logins, which amplify the impact of any single credential compromise.
- Enable and centralize logging on DNA Apps components so that anomalous deserialization activity or unexpected process spawning from SCADA application services is visible to monitoring, not just to the local server.
- Tighten network access to Enterprise SCADA servers so that only authorized operator workstations can reach the relevant service ports — this doesn’t close the vulnerability but narrows who could attempt exploitation even with valid low-level credentials.
- Treat any operator account showing authentication from an unusual workstation or off-shift login pattern as a priority investigation item while the patch rollout is in progress, given the low bar (valid operator credentials, no user interaction) this flaw requires.
No public proof-of-concept exists yet, but CVE-2025-7639’s combination of a widely deployed legacy SCADA platform, a straightforward-to-articulate privilege boundary it breaks, and a CISA advisory now pointing researchers at the exact component involved means the window before someone publishes a working exploit chain should be assumed to be short, not long.