The short version
On 10 September 2026, CISA published ICSA-26-253-01 for AVEVA Pipeline Integrity Monitor, the software operators use to watch the condition of a pipeline, in the Critical Manufacturing sector and deployed worldwide. It carries four CVEs, CVE-2026-81821 through CVE-2026-81824, covering a hard-coded cryptographic key, a broken or risky cryptographic algorithm, a missing authorization check, and a cross-site scripting flaw.
The headline number is 8.4. The number that should drive your week is the attack vector next to it: the two 8.4s are local. They need an attacker who already has a low-privileged foothold on that host. Everything about how urgent this is for you depends on how hard that foothold is to get.
What the advisory says
Straight from the advisory:
- Product: AVEVA Pipeline Integrity Monitor, versions up to and including 2025_SP1_P1_build_7.1.9580.8513.
- The flaw classes: use of a hard-coded cryptographic key (CWE-321), use of a broken or risky cryptographic algorithm (CWE-327), missing authorization (CWE-862), and cross-site scripting (CWE-79).
- Severity, and this is where to read carefully:
| CVE | CVSS v3.1 | Vector | Reachable from |
|---|---|---|---|
| CVE-2026-81821 | 8.4 | AV:L/AC:L/PR:L/UI:N/S:C | Local, needs low privilege on the host |
| CVE-2026-81822 | 8.4 | AV:L/AC:L/PR:L/UI:N/S:C | Local, needs low privilege on the host |
| CVE-2026-81823 | 5.3 | AV:N/AC:L/PR:N/UI:N | Network, no privileges needed |
| CVE-2026-81824 | 4.7 | AV:N/AC:L/PR:N/UI:R | Network, needs user interaction |
- Remediation: AVEVA has published the 2025 SP1 P2 Security Update, documented in security bulletin AVEVA-2026-006. The vendor also directs operators to migrate old project files, evaluate the risk of password leakage and tighten read access, and require PIMBoards users to change their passwords.
- CISA's standing guidance: minimize network exposure, isolate control systems from the internet, and use VPNs for remote access.
The two 8.4s are a reachability problem, not a patching problem
AV:L is the most useful character in this advisory. Both of the high-scoring issues are local: they do not let someone on the internet, or even someone elsewhere on your plant network, do anything at all. They pay off only after an attacker is already executing code on that machine with some low level of privilege.
That changes the question you should be asking. Not how bad is an 8.4, but how many people and systems can currently open a session to the host running Pipeline Integrity Monitor, and do all of them need to? For most estates the honest answer to the second half is no, and the list is longer than anyone expects: engineering workstations, a jump host, an integrator's laptop, a service account nobody has audited since commissioning.
Cut that list and you have bounded the severe half of this advisory without touching the software. That is a control you can put in place this week. The update is a control you can put in place when your maintenance window allows.
The part you genuinely cannot mitigate
Most advisories give you room to manoeuvre while you wait for a window. A hard-coded cryptographic key does not.
A key compiled into the product is the same key on every installation of that version, everywhere in the world. The operator cannot rotate it. No password policy touches it, no firewall rule changes it, and no amount of hardening the host makes it a different key. It stops being a secret the moment anyone extracts it from any copy of the software, and it stays not-a-secret until the vendor ships a build that uses a different one.
That is why AVEVA-2026-006 is not optional here, and why it deserves a real slot in your change calendar rather than the end of the backlog. It is also why the access-control work matters in the interim: when the cryptographic guarantee is the thing that is broken, the remaining guarantee has to come from somewhere else, and the only place left is who is allowed to reach the software.
On CISA's VPN line
CISA's standing ICS guidance closes with "use VPNs for remote access", and CISA is careful to add that a VPN is only as secure as the devices connected to it. That caveat is doing a lot of work, and it is worth spelling out for this advisory in particular.
A VPN authenticates a device onto a network and then hands it a route. The serious flaws here are local to the host. So the control that actually bounds them is not one that decides who gets onto the network, it is one that decides who gets onto that machine.
The sharper version of CISA's instruction, and the one that fits an AV:L advisory, is access brokered per asset: a named identity, authenticated before anything connects, scoped to the one system and the one protocol the job needs, time-boxed to the window, and recorded end to end. A compromised integrator laptop then reaches one monitored host for one task instead of inheriting a route to the segment. Same instruction as CISA's, enforced one asset at a time rather than one network at a time.
What to do this week
- Check your build string against
2025_SP1_P1_build_7.1.9580.8513. If you are at or below it, you are in scope. - Schedule AVEVA-2026-006 (the 2025 SP1 P2 Security Update) on your validated process. The hard-coded key is not fixable any other way.
- Enumerate who can reach the host today. Every workstation, every account, every vendor path. This is the single action that changes your exposure before the window arrives.
- Do the three housekeeping items the vendor names: migrate old project files, tighten read access on anything that could leak a password, and force the PIMBoards password change.
- Decide how you would know. If someone did get low-privileged execution on that host, what would tell you? For most OT estates the answer is nothing, and that answer is worth more attention than the CVSS score.