August 18, 2026 · 14 min read

IEC 62443-4-2 / 4-1 / 2-4CRA Annex I / NERC CIP-007CVE-2026-65311 / CVE-2026-65313

When the Audit Log Had an Off Switch: The ANDRITZ HIPASE-250 Advisory (ICSA-26-225-05) Through an IEC 62443-4-2 and CRA Annex I Lens

Three of the four flaws in this advisory are the ones you expect. Passwords stored in a reversible format. A data endpoint with no authentication and permissive CORS. A fixed remote-desktop password baked into an installation script. Ordinary findings, ordinary fixes. The fourth one is the interesting one, and it scored the lowest: an undocumented HTTP endpoint that changes the logging level and log destination, reachable by anyone on the network, with no credentials at all. CVSS gave that a 5.3. CVSS is scoring the component. What the plant actually lost was its ability to know anything happened.

On August 13, 2026, CISA published its usual large batch of ICS advisories — fifteen by WaterISAC's count, fourteen by others, which tells you something about how these get tracked. One of them was ICSA-26-225-05, covering ANDRITZ HIPASE-250 and its predecessor product name, 250 SCALA. INCIBE-CERT picked it up the next day as INCIBE-2026-558. The four CVEs were reserved on July 21, 2026 and published July 31, assigned by CyberDanube as CNA, and found by Duc Anh Nguyen and Ta Duc Thien of the NTCS OT penetration testing team.

Before the standards discussion, a precision point that matters for anyone triaging this: the CVEs are against the SCADA layer, not the relay. ANDRITZ's HIPASE platform has two distinct things in it. There are HIPASE devices — HIPASE-P protection, HIPASE-E excitation, HIPASE-S synchronization, HIPASE-T turbine governor, and the combined HIPASE-PS and HIPASE-ET variants — which are 19-inch rack IEDs speaking IEC 61850 MMS and GOOSE, IEC 60870-5-103 and -104, Modbus TCP, OPC UA and FTP. And there is HIPASE-250, the control-center SCADA system that operates, monitors and controls the plant above those devices, along with the engineering workstations that configure the whole platform. This advisory lands on the second one. Nobody has published a protection-firmware flaw here. What has been published is a set of flaws in the layer that operators sit in front of, that engineers configure devices from, and that generates the record of who did what.

The public record

CVE-2026-65309 — passwords stored and transmitted reversibly. CVSS v3.1 7.5, vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. CWE-327 and CWE-257. The CVE text is direct: HIPASE-250 "stores and transmits user passwords using a reversible format instead of a one-way password hash," so an attacker who can read the credential store or capture network traffic recovers all stored passwords. Not one password. All of them. Fixed in 7.50.

CVE-2026-65310 — unauthenticated data and configuration endpoint with permissive CORS. CVSS v3.1 7.5, same vector. CWE-306 and CWE-942. In the default configuration, the data and configuration endpoint answers without authentication and returns permissive CORS headers on every response, so an unauthenticated attacker with network access reads live process values and server configuration. Fixed in 7.40.

CVE-2026-65313 — hard-coded x11vnc credential written by the provisioning script. CVSS v3.1 8.1, vector AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N. CWE-798 and CWE-1392. This is the highest-scored of the four, and note the integrity impact is High, not None: VNC into an engineering workstation is not a read. The provisioning script used when installing HIPASE-250 engineering workstations sets a fixed x11vnc password, and because the same script provisions every workstation, the same credential is on all of them. Fixed in 8.15.

CVE-2026-65311 — undocumented, unauthenticated logging-configuration endpoint. CVSS v3.1 5.3, vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N. CWE-306, CWE-532, CWE-284. The HTTP server component "exposes an undocumented endpoint that changes the server's logging level and target without requiring authentication," and the CVE description says the quiet part out loud: a remote unauthenticated attacker "may suppress audit logging, potentially concealing other activity on the system." Fixed in 8.00.

Affected versions per the advisory are HIPASE-250 and 250 SCALA at 7.20 and earlier, and ANDRITZ points operators at V8.00.00 and V8.15.00. But read those four "fixed in" fields again, because they are not the same number: 7.40, 7.50, 8.00, 8.15. Four fixes, four releases, spread across two major versions. An asset owner sitting on 7.50 has closed two of four and has no way to know that from the advisory banner alone. Only 8.15 closes all four. That gap between "affected versions" as stated and remediation state as actually shipped is its own finding, and I will come back to it.

One more piece of public record, because the contrast is the whole point. ANDRITZ's own HIPASE-250 product page says the system offers "TLS encryption for all communication protocols, system hardening according to CIS Level 2, a secure kiosk mode, role based access control (RBAC), Single Sign-on (SSO), two-factor authentication (2FA) with smartcards." The HIPASE device page opens its security section with "Cybersecurity is at the core of the HIPASE platform." None of that is marketing dishonesty — those features are real, and the split of the communication CPU from the application CPU on the devices is genuinely good architecture. It is simply that a product can offer smartcard 2FA at the front door and still store the password file in a format you can run backwards, still answer configuration queries to a stranger, and still ship an installer that writes the same VNC password on every workstation in the fleet. Feature lists are not a security posture. Verified requirements are.

CISA reports no known public exploitation of any of the four as of publication.

The standards lens

This is an energy-sector IACS. The applicable frame is IEC 62443, and the four findings map onto it with unusual tidiness — which is what happens when the missing artifact is a requirements set rather than a subtle design error.

IEC 62443-4-2, component requirements. HIPASE-250 is a software application, so the SAR profile applies on top of the common requirements.

CR 1.5 (Authenticator management) requires that authenticators be protected from unauthorized disclosure and modification, both when stored and when transmitted. CVE-2026-65309 fails both halves in one line of design.
CR 4.1 (Information confidentiality) covers information at rest and in transit for which disclosure is a concern. Same CVE, second violation.
CR 2.1 (Authorization enforcement) requires the component to enforce authorizations assigned to all human users, software processes and devices. CVE-2026-65310 has no authorization decision to enforce; CVE-2026-65311 has one and skips it on a route that is not in the documentation.
CR 1.7 (Strength of password-based authentication) is where CVE-2026-65313 lives, and CR 1.5 again — a credential that is identical across every installed instance has no strength at all, regardless of its character count.
CR 2.8 (Auditable events) and CR 2.10 (Response to audit processing failures) are the pair CVE-2026-65311 breaks. CR 2.8 requires an audit capability for access control, request errors, control-system events, backup and restore, configuration changes and audit-log events. CR 2.10 requires the component to respond when the audit process itself fails. An unauthenticated party turning the log level down is an audit processing failure, and nothing responds to it.

IEC 62443-3-3, system requirements. Zoom out one level and the same defect becomes worse. FR 6, Timely Response to Events, is the foundational requirement family that gives an asset owner the ability to notice and reconstruct an incident: SR 6.1 audit log accessibility, SR 6.2 continuous monitoring. A plant claiming SL-T 2 or SL-T 3 on FR 6 is, in practice, claiming that the SCADA writes a reliable record. That claim is only as strong as the weakest way to stop the writing, and the weakest way here needs no account.

IEC 62443-4-1, secure development lifecycle. Two practices are implicated, and they are different in character.

SVV-3 (Vulnerability testing) and SVV-4 (Penetration testing) are the activities that find undocumented endpoints and reversible credential stores. They were performed — by two external researchers on someone else's schedule, which is the definition of the control not being in the supplier's process.
SG-3 (Product hardening guidelines) and SG-1 (Product defense in depth) are where the provisioning script belongs, and this is the finding I would write up first. The script is not application code. It is a commissioning artifact — the kind of thing that lives in a services repository, gets copied between projects, and is maintained by the team that installs plants rather than the team that builds product. It is also, functionally, part of the shipped product's security posture, because it determines the credential state of every engineering workstation in the field. If your secure-development scope is drawn around the source tree and stops at the installer, you have drawn it in the wrong place.

IEC 62443-2-4 is the other half of that. HIPASE-250 is delivered as an integrated solution with installation, commissioning and operator training, and 62443-2-4's account-management and hardening requirement groups govern exactly the credentials the integrator creates during that process. A fixed x11vnc password is a 2-4 finding against the service delivery, not only a 4-1 finding against the product.

Regulatory overlay. Two matter, and one has a date attached.

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) Annex I, Part I sets essential requirements that read like they were drafted with this advisory open. Requirement (2)(b) — protection from unauthorised access by appropriate control mechanisms including authentication and access management. Requirement (2)(d) — protect the confidentiality of stored and transmitted data, including by encryption. And requirement (2)(j) — provide security-related information by recording and monitoring relevant internal activity, including access to or modification of data, services or functions, with an opt-out mechanism for the user. An opt-out for the user. Not an opt-out for an unauthenticated party on the network. ANDRITZ is an Austrian manufacturer selling into the EU; CRA vulnerability-reporting obligations begin applying in September 2026 and the full essential requirements in December 2027. This advisory is a rehearsal.

For NERC CIP, the caveat first: a lot of hydro sits below the BES thresholds and is not registered, so CIP may not apply to a given HIPASE-250 installation at all. Where it does apply, CVE-2026-65311 is a direct problem for CIP-007-6 R4 — security event monitoring requires logging detected events, alerting on them, retaining ninety days of logs and reviewing them at least every fifteen calendar days. A review process cannot detect the absence of records it was never going to receive. CVE-2026-65313 is CIP-007-6 R5.4 (default and generic account passwords, per cyber asset capability) and CIP-005 R2 (interactive remote access), since x11vnc on an engineering workstation is interactive remote access whether or not anyone declared it as such.

A worked risk assessment: IEC 62443-3-2 zone rows and the attack chain

Here is the assessment I would put in front of a plant owner. Zone model: Zone 1 is the control room and the HIPASE-250 servers and engineering workstations; Zone 2 is the plant-control LAN carrying IEC 61850 and IEC 60870-5-104 to the HIPASE devices; the conduit between them is the one everybody assumes is doing more work than it is.

| ID | Zone / asset | Threat scenario | CVE | Unmitigated SL-A | SL-T | Consequence | | --- | --- | --- | --- | --- | --- | --- | | ZCR-01 | Z1 — HIPASE-250 server | Unauthenticated read of live process values and server configuration; used for target mapping | CVE-2026-65310 | SL 0 (FR 1, FR 4) | SL 3 | Full disclosure of plant topology, tag names, unit states | | ZCR-02 | Z1 — credential store / network | Recovery of every stored operator and engineer password from the store or from captured traffic | CVE-2026-65309 | SL 0 (FR 1) | SL 3 | All accounts compromised; 2FA and RBAC bypassed at the credential layer | | ZCR-03 | Z1 — engineering workstation | VNC session established with the fleet-wide fixed password from an adjacent network position | CVE-2026-65313 | SL 1 (FR 1, FR 2) | SL 3 | Interactive control of the engineering tool that configures HIPASE-P/E/S/T devices | | ZCR-04 | Z1 — HIPASE-250 HTTP server | Audit level and log destination lowered by an unauthenticated request before and after the above | CVE-2026-65311 | SL 0 (FR 6) | SL 2 | Loss of detection and of forensic reconstruction; incident becomes unattributable | | ZCR-05 | Conduit Z1 to Z2 | Configuration change pushed to a protection or governor device from a compromised workstation session | (chained) | SL 1 | SL 3 | Protection settings or governor parameters altered; unit trip behaviour changed |

The individual CVSS scores do not capture ZCR-05, because CVSS scores components and this is a system property. The chain is what matters:

TOP EVENT: Unauthorized and unattributable change to hydro unit
           protection / governor configuration
    |
    +-- AND --------------------------------------------------+
    |                                                         |
[A] Attacker obtains interactive session on an           [B] Change is not
    engineering workstation                                  detected or attributed
    |                                                         |
    +-- OR ------------------+                                +-- OR --------------+
    |                        |                                |                    |
 [A1] x11vnc with the     [A2] Valid credentials         [B1] Audit level      [B2] Log target
      fleet-wide fixed         recovered from the             lowered via            redirected via
      password                 reversible store or            unauthenticated        the same
      (CVE-2026-65313)         from captured traffic          endpoint               endpoint
                               (CVE-2026-65309)               (CVE-2026-65311)       (CVE-2026-65311)
                                    |
                               [A2.1] Credential store or
                                      traffic first located via
                                      unauthenticated config read
                                      (CVE-2026-65310)

Read the tree left to right and the design problem is obvious. Branch [A] has two independent paths, either of which is sufficient. Branch [B] has no independent leg at all — every path through it is the same endpoint, because there is only one audit subsystem and it has one unauthenticated control surface. A detection control with a single point of defeat is not a layer of defense. It is a checkbox with a wire running to it.

Mapping the four findings to the frameworks an auditor will actually cite:

| CVE | CWE | CVSS v3.1 | IEC 62443-4-2 | IEC 62443-3-3 | CRA Annex I Pt I | NERC CIP (where registered) | | --- | --- | --- | --- | --- | --- | --- | | CVE-2026-65309 | CWE-327, CWE-257 | 7.5 High | CR 1.5, CR 4.1 | SR 1.5, SR 4.1 | (2)(d) | CIP-007-6 R5.5, CIP-011 | | CVE-2026-65310 | CWE-306, CWE-942 | 7.5 High | CR 2.1, CR 4.1 | SR 2.1, SR 5.1 | (2)(b) | CIP-005 R1 | | CVE-2026-65313 | CWE-798, CWE-1392 | 8.1 High | CR 1.5, CR 1.7 | SR 1.5 | (2)(b) | CIP-007-6 R5.4, CIP-005 R2 | | CVE-2026-65311 | CWE-306, CWE-532 | 5.3 Medium | CR 2.1, CR 2.8, CR 2.10 | SR 6.1, SR 6.2 | (2)(j) | CIP-007-6 R4 |

Note which row is scored lowest and which row has the widest regulatory footprint. They are the same row.

Derived requirements (excerpt)

Five requirements I would write against this platform. Numeric, testable, and each one has a test that can fail.

HP-CSR-01 — Irreversible authenticator storage. All user authenticators shall be stored using a memory-hard one-way key derivation function (Argon2id with m ≥ 64 MiB, t ≥ 3, p ≥ 1, or PBKDF2-HMAC-SHA-256 at ≥ 600,000 iterations per NIST SP 800-63B), with a unique 128-bit random salt per credential. No code path in the product shall be capable of recovering a plaintext authenticator. Authenticators shall be transmitted only inside TLS 1.3 and never as a reversible field in an application payload. Verification: static review of the credential store plus packet capture on every exposed protocol interface; recovery of any plaintext fails the requirement. Traces to: CR 1.5, CR 4.1, CRA (2)(d).

HP-CSR-02 — Zero unauthenticated data routes. Every HTTP route that returns process values, configuration, diagnostics or version information shall require an authenticated session. Access-Control-Allow-Origin shall be set from an explicit configured allow-list and shall never be the wildcard, and shall never accompany a credentialed response. Verification: an automated route-inventory test enumerates every registered route at build time and issues each one with zero credentials; the acceptance criterion is 0 routes returning process or configuration data, with the sole permitted exception being a static liveness probe that returns no plant data. Build fails otherwise. Traces to: CR 2.1, CRA (2)(b).

HP-CSR-03 — Per-instance commissioning secrets. No provisioning, imaging or commissioning script shall write a credential, key or certificate that is identical across two installations. Each engineering workstation shall generate a per-instance secret of ≥ 128 bits of entropy at first boot, and any remote-desktop service shall be disabled by default, require explicit enablement, and authenticate per named user. Commissioning scripts are in scope for the secure-development lifecycle and shall be reviewed under the same SI-1 gate as application source. Verification: two clean installs performed by the standard commissioning procedure; extract and diff all credential material; any identical value fails. Traces to: CR 1.5, CR 1.7, IEC 62443-4-1 SG-3, IEC 62443-2-4 account management, NERC CIP-007-6 R5.4.

HP-CSR-04 — Non-defeatable audit path. Audit level, audit destination and retention shall be modifiable only by an authenticated principal holding an explicit SecurityAdmin role. Every such change shall itself generate an audit record that cannot be suppressed by the change it describes. All audit records shall be forwarded to an external collector within 5 s of generation. Loss of the external log path for more than 60 s shall raise an operator-visible alarm on the HMI and shall be recorded locally. Verification: attempt the change unauthenticated (must fail closed), then authenticated as a non-SecurityAdmin (must fail closed), then sever the collector link and time the alarm. Traces to: CR 2.1, CR 2.8, CR 2.10, SR 6.1, SR 6.2, CRA (2)(j), NERC CIP-007-6 R4.

HP-CSR-05 — Per-CVE remediation state, machine-readable. Security advisories and release notes shall state, for each CVE, the first product release containing the fix. The product shall expose an authenticated endpoint returning a machine-readable inventory of component versions and applied security fixes, so an asset owner can determine achieved security level without vendor correspondence. Rationale: the four fixes in this advisory shipped in 7.40, 7.50, 8.00 and 8.15 while the advisory presents a single affected-version banner of "7.20 and earlier"; an operator on 7.50 cannot self-serve the answer to "which two do I still have." Traces to: IEC 62443-4-1 DM-4 and DM-5, CRA Annex I Part II (vulnerability handling), and the SBOM expectation that comes with it.

What the headline really tells us

The headline is "four vulnerabilities in a hydropower SCADA product, patch to 8.15." That is true and you should do it. The engineering story is smaller and more general than that.

Three of these four findings are ordinary. They will be fixed, they were fixed, and every supplier in this sector has shipped something like them. The fourth is the one worth keeping. An audit subsystem is a detection control — it exists so that when a preventive control fails, somebody can find out. In a safety context we would call this a monitor, and we would immediately ask the two questions we always ask of a monitor: what is its availability, and what defeats it. Those questions are routine in ISO 26262-9 dependent failure analysis and in ARP4761A common-mode analysis. They are much less routine in security architecture, where logging is often treated as infrastructure rather than as a control with an integrity requirement of its own.

Here the answer to "what defeats it" was one unauthenticated HTTP request to a route that was not in the documentation. And because it was undocumented, it was also almost certainly outside the test scope — you do not write a negative test for an endpoint you have forgotten you have. That is the mechanism by which a debug affordance becomes a security control's off switch: not malice, not incompetence, just a route added for a good reason during development, never registered as an interface, and therefore never inheriting the authorization requirement that every registered interface got.

The provisioning script has the same shape. It is a real part of the delivered system that sits outside the boundary somebody drew around "the product." Draw your secure-development scope around the source tree and you will keep finding your credentials in the installer, your undocumented routes in the debug handler, and your audit off switch in a place no requirement ever pointed at.

CVSS gave the audit endpoint a 5.3, and for a component score that is defensible — confidentiality none, integrity low, availability none. But the thing that was actually damaged is not a property of the component. It is the plant's ability to answer the question every incident starts with, which is what happened and who did it. There is no CVSS metric for that, which is precisely why the security level target has to be written at the zone, and why FR 6 exists as its own foundational requirement family instead of as a footnote under access control.

Patch to 8.15. Then go find out what else in your estate can turn its own logging down without being asked who it is.