A Hard-Coded Key in Pipeline Integrity Software

CISA published ICSA-26-253-01 on 10 September covering AVEVA Pipeline Integrity Monitor at versions up to and including 2025 SP1 P1 build 7.1.9580.8513. Four issues are listed. CVE-2026-81821 is a hard-coded cryptographic key, CWE-321, scored 8.4 on CVSS v3.1 and 8.3 on v4. CVE-2026-81822 is use of a broken or risky cryptographic algorithm, CWE-327, at the same scores. CVE-2026-81823 is a missing authorisation, CWE-862, at 5.3 and 6.9 — and it is the one exploitable remotely without authentication, permitting unauthorised read operations and information disclosure. CVE-2026-81824 is a cross-site scripting issue at 4.7 and 6.3. AVEVA's remedy is the 2025 SP1 P2 security update, with bulletin AVEVA-2026-006, and it comes with an unusual requirement: legacy project files must be migrated, the migration is one-way because the cryptographic algorithms changed, unmigrated files need stricter access controls in the meantime, and PIMBoards users should be made to reset their passwords.

The pairing of the first two CVEs is the technically interesting part. A hard-coded key and a weak algorithm in the same product are usually the same decision seen twice: an encryption scheme designed to make files portable between installations, where the key had to be somewhere and the algorithm had to be simple. That works until the key is extracted from the binary, at which point every file ever produced by every installation of the product is readable by anyone who has one. This is why the fix cannot be a patch alone — the data encrypted under the old scheme stays weak until it is re-encrypted, which is exactly what the one-way migration is for.

That migration is the operational story. A one-way file conversion in a system of record is not a routine update: it needs a backup taken first, a decision about what to do with archived project files nobody will migrate, and a plan for any integration or script that reads those files directly. Pipeline integrity systems accumulate years of run data and model configuration, and the instinct to migrate only the active projects leaves the archive sitting in the weak format indefinitely, which is a defensible choice only if someone makes it deliberately and writes down where those files are.

For anyone running this product, the sequence is: inventory the installations and versions, confirm that none are reachable from outside the process network — CVE-2026-81823 being the pre-auth one makes exposure the first question — take backups, schedule the migration with the archive explicitly in scope, and force the PIMBoards password reset rather than assuming it will happen. And the general lesson, which applies well beyond AVEVA: any product that encrypts its own files with a key that ships inside it should be assumed to have this problem until its vendor says otherwise.