CISA republished AVEVA’s bulletin as ICSA-26-253-01 on September 10, while AVEVA dated bulletin AVEVA-2026-006 and the associated CVE records September 8. The timing difference does not indicate a second set of bugs: it is the same four-vulnerability release, with the later CISA notice amplifying it for industrial operators.
The immediate operational catch is easy to miss in the advisory summary. AVEVA’s supplied fix requires migration of PIMBoards project files, and that migration is one-way because the release changes password-hashing algorithms and customer-managed encryption keys. Administrators need a tested maintenance plan, a defined rollback strategy at the system level, and an inventory of every project-file copy before beginning the upgrade.
The affected component is PIMBoards, not every Pipeline Integrity Monitor function
AVEVA says the vulnerable surface is PIMBoards, a component of Pipeline Integrity Monitor, rather than describing the entire pipeline-monitoring product as equally exposed. That distinction should guide triage. Teams should first identify systems hosting the PIMBoards API, workstations and servers with local or network access to PIMBoards project files, and any shares, backup locations, transfer folders, or endpoint-management jobs that duplicate those files.
Pipeline Integrity Monitor is used for computational pipeline monitoring, including leak detection and analysis for midstream pipelines. AVEVA describes the platform as supporting multiple monitoring methods and integrated detection workflows. In that setting, project files are not disposable application clutter: they may contain configuration and operational information whose disclosure can create a wider security and safety concern even where the reported vulnerability itself does not alter process controls.
The affected version boundary is unusually clear: AVEVA and the CVE records identify 2025 SP1 P1, build 7.1.9580.8513, and all prior versions as affected. The remedy is Pipeline Integrity Monitor 2025 SP1 P2 or later. Administrators should not use the presence of a newer-looking base year in the product name as proof of safety; the decisive check is the installed build and whether PIMBoards is in use.
Two high-severity issues turn project-file access into a larger compromise
CVE-2026-81821 is a hard-coded cryptographic-key issue. According to the CVE record published through CISA’s CNA process, an attacker with read access to PIMBoards project files could decrypt and view sensitive information. CVE-2026-81822 covers use of a weak or risky cryptographic algorithm; it can permit someone with read access to those project files to computationally brute-force weak hashes for PIMBoards’ application-native passwords and potentially elevate to a PIMBoards administrator account.
Both carry a CVSS v3.1 score of 8.4, rated High. But the scoring should not be read as “unauthenticated internet takeover.” Their documented attack vector is local, and both require low-level privileges plus read access to the relevant project files. That prerequisite narrows the initial path, while also giving defenders a concrete control point: file permissions, backup access, engineering-workstation access, and project-file handling are part of the attack surface.
This is where the upgrade’s one-way migration matters. AVEVA says older project files that cannot be migrated — such as retained backups or temporary copies — should be assessed for password-leakage risk and protected with stricter read access. A patched server does not retroactively fix an old project archive copied to a permissive Windows file share, placed in an accessible backup repository, or retained on a contractor’s engineering laptop.
AVEVA also directs customers to require PIMBoards users to change their passwords following the upgrade. That is not generic password hygiene. It is a necessary follow-through on the weak-hash finding: credentials that may have been recoverable from older project files should be replaced, particularly where staff reused application-native passwords elsewhere.
The network-facing flaws have narrower stated effects
The other two CVEs are network-reachable PIMBoards problems, but neither is described in the records as remote server-side code execution.
CVE-2026-81823 is a missing-authorization flaw. The CVE record says an unauthenticated attacker could perform read operations intended for PIMBoards users, resulting in information disclosure; it explicitly says write operations are not affected. Its CVSS v3.1 score is 5.3 and its CVSS v4 score is 6.9, both Medium.
CVE-2026-81824 is cross-site scripting. An attacker could cause arbitrary JavaScript to execute in a PIMBoards user’s browser session if that user is socially engineered into opening a malicious link. This is a browser-session compromise, not evidence that the attacker can directly execute code on the Pipeline Integrity Monitor server or manipulate pipeline equipment. Even so, a hijacked authenticated session can expose data or enable actions available to that user, which is why industrial organizations should handle suspicious PIMBoards links as an operational security problem rather than dismissing the issue as ordinary web-app XSS.
CVE-2026-81824 is rated 4.7 under CVSS v3.1 and 6.3 under CVSS v4. The difference is a useful reminder that the supplied advisory’s broad “8.4” label applies to the two project-file cryptography findings, not to all four CVEs. Prioritization should reflect the actual exposure: externally reachable or broadly accessible PIMBoards API instances deserve immediate containment, but project-file sprawl may represent the more persistent remediation burden.
What administrators should do before and during the upgrade
CISA reported no known public exploitation specifically targeting these vulnerabilities as of its September 10 advisory. That is good news, but it is not a reason to defer: the CVE entries publicly describe the affected component, version range, attack conditions, and impact. Organizations should use the window to close exposure methodically.
A practical response should include the following actions:
- Confirm whether Pipeline Integrity Monitor 2025 SP1 P1 build 7.1.9580.8513 or an earlier version is installed, and establish whether PIMBoards is deployed or used on that installation.
- Identify every PIMBoards project-file location, including Windows shares, endpoint folders, backup repositories, temporary export areas, disaster-recovery copies, and files transferred to third parties.
- Restrict read access to those project files to specifically authorized personnel and service accounts. Review inherited permissions and group memberships rather than assuming a top-level folder ACL protects nested copies.
- Apply host-based and network firewall rules so that only trusted client systems can connect to nodes hosting the PIMBoards API. CISA’s broader guidance to isolate industrial systems from business networks and avoid direct internet exposure remains applicable here.
- Upgrade to Pipeline Integrity Monitor 2025 SP1 P2 or later in a tested maintenance window, because project-file migration changes password and encryption-key handling.
- Change all PIMBoards user passwords after the upgrade, with special attention to accounts that had administrative roles or may have reused credentials.
- Preserve older project files only where necessary, label them as pre-migration material, and maintain a documented chain of custody. They may remain a source of password exposure even after production has moved to the patched release.
AVEVA credits its own reporting for CVE-2026-81821 and CVE-2026-81822. The remaining two flaws, CVE-2026-81823 and CVE-2026-81824, were reported by researcher Adham Khairy Ramadan through HackerOne. That mix explains the vulnerability set: two weaknesses rooted in stored project-file protection, alongside two externally reported authorization and browser-input issues in the PIMBoards application surface.
The lasting fix includes the files, not only the software
The central remediation consequence is straightforward: Pipeline Integrity Monitor 2025 SP1 P2 closes the reported vulnerabilities, but it also changes the format and security assumptions of PIMBoards project data. Organizations that update the application without locating old project files, tightening access controls, and rotating PIMBoards passwords will leave the most consequential part of the exposure in place.
For Windows and infrastructure teams supporting industrial operations, the priority is therefore to pair the product upgrade with a file-access audit. Every pre-migration PIMBoards project file should be treated as sensitive legacy material until it is migrated or placed behind controls strict enough to prevent the low-privilege read access that enables the two High-severity findings.