The short version
On 13 August 2026, CISA published ICSA-26-225-01 for AVEVA Enterprise SCADA and Enterprise SCADA HMI, the supervisory software that runs industrial processes across Critical Manufacturing. The vulnerability, CVE-2025-7639, is a deserialization of untrusted data issue: a crafted serialized payload sent to the software can be tampered with and trigger code execution during deserialization. CVSS v3 base score 7.1, high attack complexity, and no known public exploitation.
The precondition is the familiar one for OT. An attacker has to reach the SCADA or HMI service to send it that payload. That reach is the part you control.
What the advisory says
Straight from the advisory and the CVE record:
- Products: AVEVA Enterprise SCADA and Enterprise SCADA HMI.
- The flaw: CVE-2025-7639, deserialization of untrusted data leading to code execution during deserialization.
- Affected versions: Enterprise SCADA 2025 and earlier through the listed service-pack levels (2024 up to 2024 SP1 P01, 2023 up to 2023 SP1, 2022 up to 2022 SP2 P2, 2021 up to SP2 P5), plus Enterprise SCADA HMI 2024 and 2023 and earlier.
- Severity: CVSS v3 7.1, high attack complexity.
- How it is reached: an attacker who can deliver a crafted serialized object to the service. Code execution is the outcome.
- Remediation: AVEVA has published fixes in security bulletin AVEVA-2026-005. CISA adds its usual ICS guidance: keep the system off the public internet, isolate it from the business network, and route remote access through a controlled path.
CISA reported no exploitation in the wild. Read it as exposure to close on your terms, not a fire to put out.
Why this keeps happening
SCADA and its HMI are Windows-hosted applications with databases and network services, and they supervise a physical process that cannot simply stop. That is the whole tension of OT security in one sentence. The software carries the same classes of flaw as any enterprise application, deserialization among them, yet you cannot patch it on a Tuesday. A fix waits for a validated maintenance window that may be weeks or a season away, if the vendor certifies it for your version at all. In the meantime the process keeps running and the vulnerable service keeps listening.
That gap between "a fix exists" and "we can safely apply it" is where OT risk actually lives. It is not a failure of the plant team. It is the nature of running software that controls machinery you cannot reboot on demand.
What actually gets exploited
Strip the CVE to its mechanics. An attacker who can open a connection to the SCADA or HMI service sends it a crafted serialized object, and during deserialization that turns into code running on the host that supervises the process. High attack complexity raises the bar on the payload, but the first ingredient the attacker needs is simple: network reach to the service. On a flat OT segment, most of the plant has it.
So the question worth asking on your own network is not only whether AVEVA is patched. It is what can currently open a connection to the SCADA and HMI servers, and whether you would notice if something did. On a flat control network the honest answers are usually "most things" and "no."
The control that actually bounds it
You close this without waiting on the maintenance window by making the SCADA and HMI reachable only through an enforcement point.
The Access Gate sits in the access path to those servers and brokers every session that reaches them. In practice:
- The servers stop answering arbitrary clients on the subnet. The only way to them is a session the gate has already authenticated, so a deserialization flaw loses the thing it needs most, an unauthenticated caller on the wire.
- Every session is tied to a named person or service, scoped to the task, with MFA handled at the gate, and recorded. Nothing on the AVEVA stack is modified, so nothing has to be re-validated or rebooted for this to hold.
- Because the Access Gate is compute on the wire, an agentless enforcement point placed in front of the asset rather than a cloud service, it applies identity and least privilege next to the SCADA server without installing anything on it.
This does not replace the upgrade. Apply AVEVA's fixes when your change process allows. What the enforcement point buys you is time the patch cannot: the exposure is closed now, it stays closed through the next SCADA advisory you have not read yet, and none of it depends on a maintenance window. The mechanics are in what an industrial proxy is, the segmentation side is in OT network security, and the access side is secure OT and vendor remote access for the integrators who maintain these systems.
Where to start this week
- Locate every Enterprise SCADA and SCADA HMI instance, and note which segments can currently open a connection to them.
- Confirm the servers are not reachable from the business network or the internet. If they are, close that first.
- Apply AVEVA's fixes on your normal change process and track them, but do not let the patch date be the only thing between a network-reachable client and code execution.
- Move the SCADA and HMI servers behind an enforcement point so access is identity-bound, least-privilege, and recorded, including for the integrators who service them.
- Run the same check across the rest of the OT stack. The next advisory will name a different product, and the response will not change.
ICSA-26-225-01 is a good prompt to fix something broader than one server. The software that runs the process is still just a server on your network, and in OT you rarely get to patch the flaw on your timeline. So you set the terms on what can reach it instead.