Hard-Coded Keys Travel With the Project File

Four CVEs in AVEVA Pipeline Integrity Monitor went public on 10 September 2026, in CISA advisory <a href="https://www.cisa.gov/news-events/ics-advisories/icsa-26-253-01">ICSA-26-253-01</a>. Two score 8.4 on CVSS v3.1. Neither of those two needs the network: CVE-2026-81821 is a hard-coded cryptographic key, so a user who can read a PIMBoards project file can decrypt sensitive information inside it, and CVE-2026-81822 sits in the same files, where passwords are hashed weakly enough that brute force recovers them, up to and including a PIMBoards administrator's. Everything through the 2025 SP1 P1 build is affected. AVEVA reported both of the high-scoring flaws to CISA itself; the two medium-severity ones reached AVEVA from an outside researcher through HackerOne. The remedy is the 2025 SP1 P2 security update plus a migration of old project files, and that migration runs one direction only.

Most plants reading this don't monitor a pipeline. The sector line on the advisory reads Critical Manufacturing, and the shape of the defect is ordinary enough that the product name is nearly incidental: an engineering application keeps its configuration in a project file, the file carries credentials and connection details, and the software protects them with a secret shipped inside the product rather than one the plant chose. The same sentence describes a batch recipe editor on a CIP skid, an HMI project archive for a waste-to-energy boiler hall, a drive-parameter backup for a conveyor line, a historian collector configuration with a login in it. For an engineer who runs none of this particular software, the useful part of the advisory is the remediation list, because it names what a patch can't reach.

An 8.4 that never touches the network

The vector is CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N. Read it across: local access, low attack complexity, low privileges, no user interaction, then the term carrying the score. S:C means scope changed. Confidentiality and integrity impacts are rated High, availability untouched. A flaw that needs a local foothold and an ordinary user account often scores lower than that; the other two issues in the same advisory sit in the medium band (5.3 for an unauthenticated read path, 4.7 for cross-site scripting). This one doesn't, because the modelled damage leaves the application. What the attacker walks away with is a credential. And credentials work elsewhere.

A hard-coded key is one secret shared by every installation of a product. Not per-site, not per-project, not derived from anything the owner picked: a single value, the same in every plant that installed the same release. Recovering it is a one-time reverse-engineering job against a copy of the software, and once that job is done the result applies to every file the key ever protected. There is no server in the path to rate-limit attempts, no lockout, no audit record. Decryption happens on the attacker's own machine, against a copy, at whatever pace suits them.

The local, low-privilege user in that vector covers a longer list than the phrase suggests: a contractor with read rights to the engineering share for the length of a project; a backup administrator who has never opened a process application; the laptop that left site in a bag and came back three owners later; commodity malware already resident on an office PC that happens to hold a mapped drive. None of them has to understand pipeline integrity, or even launch the software. File read is the whole requirement, and files travel.

The hashing flaw sits beside it and compounds it. Recovering a password from a weak hash is a wordlist exercise rather than a cryptographic one, and the gap between a fast general-purpose digest and a memory-hard key-derivation function with a tuned work factor runs to many orders of magnitude in attacker cost. That margin is what a password store exists to provide. Plant passwords, meanwhile, tend to be short and patterned: a unit tag, a site abbreviation, a year, a season. Structure helps the attacker. CISA's wording on CVE-2026-81822 goes as far as elevation to a PIMBoards administrator user, which is the account that decides what the boards display and who gets to see them.

Every copy of that file carries the same key

AVEVA's remediation guidance has a second bullet after "apply the update and migrate", and it's the one that sets the real scope of work. For project files that can't be migrated (the advisory names backups and transient copies), the owner is told to evaluate the risk of password leakage and apply stricter read access controls. Read plainly, that's the vendor saying the update fixes the program. But the program was never the whole exposure.

Follow one project file through a normal process site. It's created on an engineering workstation during a control upgrade. Within a year its contents also exist in the nightly image of that workstation, in the offsite backup set, in a second copy somebody put on the file share because two people needed it during commissioning, on the integrator's laptop alongside the project files of a dozen other sites, on a USB stick in the panel drawer labelled as-built, and in an email attachment on a support ticket. In food and beverage there's one more, by design: the qualification dossier holds as-built configuration for the regulated life of the line.

Each of those copies opens with the same key, and installing the security update touches none of them. Backup retention, normally a virtue, works for the attacker here: a project file archived years ago decrypts exactly as well as the live one, which is what "hard-coded" means in practice. So the first task after reading an advisory like this one isn't patching. It's a census - a file-extension sweep across the engineering network, the backup catalogues, and the shares, plus a straight question to the integrator about what's on their machines. Dull work, and it's the only step that puts a boundary around the problem.

Put the question to the integrator in writing rather than over the phone: which of our project files do you hold, on which machines and in which backup sets, and what will you confirm once they're deleted. A firm that can't answer inside a week has told you something useful about how it handles the rest of its clients' configuration.

"Transient copies" repays a second look as well, because the phrase hides the copies no register ever listed: temp directories, Windows shadow copies, a crash dump written while the project was open, the working folder a technician unzipped during a callout and never cleaned up. A census that covers shares and backup catalogues still leaves those, which is one reason the result is a bounded estimate rather than a count.

A recovered password rarely stays in one application

The third bullet in the advisory tells owners to require PIMBoards users to change their passwords. Treat that as the smaller half of the task. A password pulled out of a project file is a string a person chose, and people reuse strings across the interfaces they touch in a day. Which of your interfaces would accept that same string today? The local account on the engineering workstation, plausibly. The drive's embedded web page. The managed switch in the MCC. The OPC-UA client credential on an edge gateway. A vendor remote-support portal. The domain account too, at any site that never enforced separation between office and plant identities. S:C in that vector string is the formal way of saying the same thing.

Rotation scope therefore follows the reuse, not the product. A plant with per-person credentials on every interface and a password manager in the maintenance office has a contained incident and a short afternoon of work. A plant where one shared maintenance login opens fourteen devices has a week of work, a change-control queue, and an argument about who gets told. So the inventory the second plant needs is the one most sites have been putting off: shared accounts, service accounts, and whatever is taped inside the cabinet door.

Then there's the integrity half of the score, which draws less attention than the stolen data. An administrator of a monitoring application can move thresholds, redefine calculated tags, and change what a board shows; the plant equivalent is a reporting layer that keeps showing green while the measurement underneath it has been re-scaled. An alarm you never received looks identical to an alarm that never needed to fire. Recovery work after this class of advisory therefore includes a line item people skip: compare the live configuration against a known-good export before anyone trusts the screens again.

One-way migration leaves you without a rollback

CISA's note on the fix is specific about why there's no going back. Migration from older versions to 2025 SP1 P2 is one-way, in the advisory's words, "due to the changes in password hashing algorithms and end-user managed encryption keys". Read at face value, that sentence carries two consequences.

Custody of a key arrives on your side of the line. That's the right design, and it brings duties the old version never asked for. Generate the key. Store it somewhere other than the machine it protects, back it up separately from the data it decrypts, write down who may retrieve it, and rotate it when the person who set it up changes employer. A site that has never operated a key escrow finds out it needs one on the day a workstation power supply dies.

And rollback disappears. A migrated project won't open in the old version, so the only route back from a failed migration is a pre-migration copy, which is exactly the artifact the whole exercise exists to retire. Keep one on purpose, keep it where two named people can reach it and nobody else can, and put a destruction date on it in writing. A sequence that holds up in a plant looks like this:

1. Inventory every copy, including backup catalogues and the integrator's machines.
2. Install the update on a non-production workstation and migrate the oldest, largest project first, because age is where the format surprises live.
3. Verify the migrated project computes what the old one did: same boards, same calculated tags, same limits, same user list and roles. Diff the exports where the product can export.
4. Decide retention for the pre-migration copies in writing - which single copy survives, who can read it, when it's destroyed.
5. Rotate credentials in order of blast radius: shared first, then anything that reaches the control network, then anything with remote access, then the rest.

Test a restore after the migration, not before. A backup written beforehand restores a project the new version refuses to open; a backup written afterwards restores a project that needs the key you generated, and if that key isn't part of the documented restore procedure then the restore doesn't work. Sites tend to learn this during an unplanned recovery, which is the worst moment to go looking for a key custodian.

What to write into the next purchase order

Two parts of the ISA/IEC 62443 series split the responsibility cleanly. <a href="https://www.isa.org/standards-and-publications/isa-standards/isa-iec-62443-series-of-standards">ISA-62443-4-1 (2018)</a> covers the secure product development lifecycle, meaning how the supplier builds the software; 62443-4-2 (2018) covers technical security requirements for the components themselves. As an asset owner you can't audit anyone's source tree. You can ask for artifacts, and you can ask before the money moves, which is the only moment a vendor's answer costs them anything:

• Key material: per-installation keys, generated at install time, with a documented escrow and rotation path. No value shared across customers.
• Password storage: the key-derivation function named in the documentation, with its work factor. "Industry-standard encryption" in a datasheet is an answer to a different question.
• Configuration upgrade path: is a format migration reversible? If not, what's the supported rollback, and does the vendor's migration tool report what it changed?
• Machine-readable advisories: a CSAF or VEX feed, so your asset inventory matches versions automatically rather than somebody reading a bulletin email. CISA publishes these advisories in CSAF; plenty of vendors still don't.
• Support lifetime: which releases get security fixes, for how long, and whether a security fix can arrive bundled with a feature upgrade. This advisory is a reminder that a patch sometimes carries a data migration along with it.

One practical note on where the clause belongs. On most sites the engineering project files live with the system integrator as much as with the owner, so credential-storage and file-handling requirements belong in the integration contract alongside the software purchase. The integrator's laptop is part of your attack surface whether or not your procurement documents admit it.

When a file walks out, the instruments stay silent

Very little, and that's worth being straight about. Reading a file produces no vibration signature, no flow deviation, no alarm. Nothing in the process data changes when a project file is copied to a USB stick, so the theft itself is invisible to the instruments a plant already trends. What can be instrumented is narrower and still useful.

Version attestation comes first. Knowing continuously which engineering workstations run which build turns an advisory into a query that returns in seconds, rather than a fortnight of asking people what they have installed. Collecting it means reading installed-product data off the machines themselves on a schedule, because a spreadsheet maintained by hand is accurate on the day it was written and drifts from there. Access logging on the shares and backup catalogues that hold project files comes second, with alerting on bulk reads rather than single ones. Both are dull controls with high yield, and both sit on the IT side of the fence where plant engineering rarely looks.

Correlation is the third, and it's where process data earns a place in a security conversation. Credential misuse shows up as behaviour: a login from a source that account never used, at an hour that shift never works, followed by a configuration write. Correlating that authentication evidence with what the plant measured at the same minute is a different data set from the vibration and temperature streams that an edge layer carrying a plant's sensor and event history usually serves, but it lands in the same place. A setpoint that moved without a work order, a recipe version that doesn't match the batch record, a totaliser that steps while the site was empty - those are corroboration, and they're the half most plants already have. The authentication half is usually the one missing.

Where this doesn't scale down

A single-engineer site with one local account, no password reuse, and project files that never left the workstation has a small problem that should be treated as one. Patch it, migrate it, change the password, log the date. A multi-week credential-rotation programme there would be money spent on paperwork rather than on risk.

A leased or vendor-maintained skid inverts the problem. The panel PC image belongs to the OEM, the support agreement forbids you from touching it, and there's no path by which you could migrate anything even if you wanted to. What's left are the controls around the box: a network segment with no route to the business network, remote access only when it's brokered and logged, and a contractual date by which the vendor ships a fixed image. The pre-migration copies, in that arrangement, sit in someone else's backup under someone else's retention rules.

For the operators who genuinely run Pipeline Integrity Monitor, none of this is an analogy, and the schedule is tighter than what I've described, because the inventory includes every project file their integrity engineers have archived since commissioning.

Yet the census carries its own limit. It bounds the copies you can enumerate and says nothing about the ones you can't: a laptop you don't administer, a mailbox with no retention rule, a drawer in a panel room at a site that has changed hands twice since the software went in. Where the copies are genuinely unaccountable, the defensible assumption is that the key is already out, and the question stops being whether to patch. It becomes whether every password that ever lived in those files has since been changed somewhere other than the application that leaked it.

Notes

Scores, version strings and remediation wording above are from the 10 September 2026 advisory; AVEVA's own bulletin, referenced there as AVEVA-2026-006, is the vendor document behind that remediation list, and a site under support should read it before scheduling the migration. The file-custody argument generalises past this product, but the credential half doesn't always: where a plant's engineering applications authenticate against a central directory instead of keeping per-project accounts, the rotation work shrinks sharply while the inventory of file copies stays exactly as large.