AVEVA’s Patch Cannot Secure the Files You Forgot
A patch can close a software flaw without making the files it used to protect safe. That is the uncomfortable detail in the new AVEVA Pipeline Integrity Monitor bulletin. The vendor has fixed four vulnerabilities in its PIMBoards component, but it also tells customers to migrate old project files, protect copies they cannot migrate and require users to change passwords. Teams that stop at the software installer may leave the most durable part of the exposure behind.
AVEVA’s 8 September security bulletin covers Pipeline Integrity Monitor 2025 SP1 P1, build 7.1.9580.8513, and earlier versions. The bulletin gives a date but no publication time. It directs users to the 2025 SP1 P2 security update or later. The affected component is PIMBoards. The bulletin reports no known exploitation or victims. It also makes no claim of disrupted pipeline operations.
Four AVEVA Pipeline Integrity Monitor exposure paths
Two findings concern the project files themselves. CVE-2026-81821 is a hardcoded encryption key: someone who can read an affected PIMBoards project file may be able to decrypt sensitive information inside it. CVE-2026-81822 concerns passwords hashed with MD5. A person with read access to an affected project file could try to recover a PIMBoards user’s application password by offline guessing, potentially gaining that user’s privileges. AVEVA rates both 8.3 under CVSS 4.0. The bulletin does not describe either as a standalone remote break-in. The attacker first needs a project file.
The other two findings involve the application interface. CVE-2026-81823 is missing authorisation on a subset of read-only API methods. AVEVA says an unauthenticated requester could perform reads intended for PIMBoards users; the flaw does not affect write operations. CVE-2026-81824 is reflected cross-site scripting, which requires a PIMBoards user to follow a crafted link before attacker-controlled JavaScript could run in that user’s browser session. The vendor rates them 6.9 and 6.3 respectively under CVSS 4.0. The preconditions are different, so we should not collapse them into a claim of remote pipeline control. As BlackTree noted in its Siemens S7 analysis, read access in industrial environments can matter without proving physical disruption.
The AVEVA Pipeline Integrity Monitor old-file problem
AVEVA’s recommended fix is more than a binary replacement. Customers using affected versions or files should apply 2025 SP1 P2, migrate old project files and require PIMBoards users to change their passwords. The company says project-file migration to SP1 P2 is one-way because the update changes password hashing and uses end-user-managed encryption keys. That has a practical consequence for change planning: teams should test compatibility, recovery and any business need to open historic projects before converting production copies.
Teams will not migrate every copy. Backups, archives and temporary transfers may remain in the older format. AVEVA explicitly says to evaluate the risk of password leakage from those copies and impose stricter read access controls. Find out where project files have travelled, who can read them, and whether a backup system, shared folder or contractor hand-off has preserved an old version. Changing the application password limits one consequence of a stolen old file; it does not make the old encryption scheme sound or erase already copied data.
The distinction also affects incident response. If someone outside the intended group accessed an old project file, the update does not settle what they saw. Investigate that earlier access separately. Scope who could access the file, what secrets it contained, whether users reused credentials and which accounts need further rotation. The public bulletin does not establish that any such access occurred, so this is a conditional investigation path, not a claim of compromise.
An operational sequence
Inventory installed AVEVA Pipeline Integrity Monitor versions and the PIMBoards deployments that are actually in use. Plan the SP1 P2 update with the application owner, then test a copy of representative project files and their recovery workflow. Restrict the PIMBoards API to trusted client systems as AVEVA recommends. Protect all folders containing project files with strong access controls, including backup and transfer locations. Migrate what can be migrated, document what cannot, and require a PIMBoards password change as part of the same change window.
This is not a story about a known attack on a pipeline. It is about why an industrial software fix can have a longer tail than the deployment package. Portable project files can preserve weak cryptography. Secure every surviving copy, not only the updated application.
Sources
- AVEVA, security bulletin AVEVA-2026-006, published 8 September 2026, no time provided.
- AVEVA, Cyber Security Updates index, listing the September bulletin.
