The files that a pipeline monitoring product saves its work into can be made to hand over the passwords of the people who use it. That is the substance of an advisory published this month by the United States cyber agency, carrying the findings of the British software maker whose product it is.
None of it stops a pump or trips a valve. Three of the four defects end in information being read by someone who should not have it, and the fourth runs code inside a logged-in user's browser. The exposure is that credentials protecting a monitoring system are recoverable by anyone holding a copy of the right file, and copies of files are the easiest thing in any plant to lose track of.
If your organisation runs liquid pipelines, or took pipeline condition monitoring as part of a larger control system package, this is a question for whoever holds the backups and whoever commissioned the system. The product is deployed worldwide and sits under critical manufacturing in the agency's own listing.
What a copied file is worth
The product keeps work in what it calls PIMBoards project files, the saved files a user opens to do the job. Two of the four defects say those files do not protect what is inside them. The first is a cryptographic key built into the product itself, which means a file's contents can be decrypted by anyone able to read the file. The second is password hashing weak enough to be worked backwards with ordinary computing time, and the advisory says that can reach an administrator account.
The practical reading is that a backup taken two years ago is still a live set of credentials today. A key shipped inside a product is not a secret any one site controls, and a copied file does not expire. That is why the remediation does not stop at installing the update: it also asks sites to assess the copies that cannot be migrated, restrict who can read them, and make every user of the dashboards change their password.
The migration itself is the part that lands on a change board rather than a laptop. Project files move to the corrected release in one direction only, because both the password hashing and the encryption key handling change underneath them. On plant where a monitoring package was commissioned by an integrator years ago and left alone since, that is a change request whose rollback plan does not exist, which is a different conversation from a routine patch and a different length of maintenance window.
The two remaining defects are smaller and more familiar. An unauthenticated request can read data meant for a signed-in user, with writes unaffected, and a link sent to a user runs attacker-supplied code in that user's browser session. Neither changes what is happening in the field, and no exploitation of any of the four has been reported to the agency, which makes this a scheduling question rather than a call-out.
The questions worth putting to the supplier
The first is for whoever holds the maintenance record: which release is actually running on site, and does the support agreement cover the security update without a commercial negotiation attached.
The second is for whoever owns the backups, and it is the harder one: where do copies of project files exist, who can read them, and how far back does the archive go. The remediation treats copies that cannot be migrated as a standing exposure rather than a closed one, so the answer to that question is the answer to this advisory.
The third is for the vendor or the integrator: what the one-way migration changes for anything else that consumes those files, and what a failed migration looks like when there is no path back.
There is also a question the document does not answer. Nothing in it tells an operator whether a given file has already been read by someone who should not have. That absence is why the first three questions are about where the copies are, rather than about whether anything has happened.
The update repairs the product. It does not repair the copies, which keep their old key and their old hashes wherever they now sit. Of the three steps asked for, the password change is the only one that reduces what an already copied file is worth.
The technical record
Advisory ICSA-26-253-01, released 10 September 2026, republishing AVEVA security bulletin AVEVA-2026-006; the document closes with the agency's standing guidance. Affected: AVEVA Pipeline Integrity Monitor, all versions up to and including 2025_SP1_P1_build_7.1.9580.8513, marked known_affected for all four issues. Sector: critical manufacturing. Deployment: worldwide. Vendor headquarters: United Kingdom.
- CVE-2026-81821, CWE-321, hard-coded cryptographic key. Read access to PIMBoards project files permits decryption of sensitive content. CVSS v3.1 8.4,
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N; CVSS v4.0 8.3. - CVE-2026-81822, CWE-327, broken or risky cryptographic algorithm. Weak hashes in project files yield app-native passwords under brute force, with possible elevation to a PIMBoards administrator. CVSS v3.1 8.4, same vector as above; CVSS v4.0 8.3.
- CVE-2026-81823, CWE-862, missing authorisation. Unauthenticated read of data reserved for PIMBoards users; writes unaffected. CVSS v3.1 5.3,
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N; CVSS v4.0 6.9. - CVE-2026-81824, CWE-79, cross-site scripting. Attacker JavaScript executes in a PIMBoards user's browser session after that user follows a malicious link. CVSS v3.1 4.7,
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N; CVSS v4.0 6.3.
Remediation as published: install the 2025 SP1 P2 security update, then migrate existing project files; for copies that cannot be migrated, such as backups or transient copies, assess the password leakage risk and tighten read access; make PIMBoards users change their passwords. Migration to 2025 SP1 P2 is not reversible, the hashing algorithm and end-user managed encryption key handling both having changed. Reporting credit: the vendor reported two of the four to the agency, and an external researcher reported the other two to the vendor through a bug bounty platform. No exploitation specifically targeting these four has been reported to the agency at publication.
Source
- cisa.gov/news-events/ics-advisories/icsa-26-253-01