GE Vernova UR relay vulnerabilities: the 2025 CVE chain, explained

GE Vernova's UR (Universal Relay) family is a line of protection, control and monitoring relays deployed in electrical substations to detect fault conditions and trip breakers before equipment or personnel are harmed — CISA's ICSA-21-075-02 advisory names the family's models directly: B30, B90, C30, C60, C70, C95, D30, D60, F35, F60, G30, G60, L30, L60, L90, M60, N60, T35 and T60. The N60 Network Relay, the device Nozomi Networks Labs examined in its 2025 research, is one member of that family. EnerVista UR Setup is GE Vernova's Windows client software for configuring a UR relay, reading its status, and pushing firmware or configuration changes — the single piece of software responsible for four of the five 2025 CVEs, with the relay's own onboard firmware responsible for the fifth.

A protection relay sits at one of the most consequence-heavy points in a power grid: it is the device deciding, in milliseconds, whether to trip a breaker to prevent equipment damage or a wider outage. That is also exactly why an attacker who can reconfigure one, or replace its firmware outright, has a materially different kind of leverage than an attacker on a typical IT endpoint.

These two chain together into the research's headline finding. NVD's record for CVE-2025-27256 (CVSS v3.1 8.3, CWE-306 Missing Authentication for Critical Function) describes "a missing SSH server authentication" in EnerVista UR Setup versions 7.0 through 8.60 that "allows Authentication Bypass" — concretely, "an attacker may perform a man-in-the-middle attack on the network in order to steal credentials or forge malicious traffic." NVD's record for CVE-2025-27257 (CVSS v3.1 6.1, CWE-345 Insufficient Verification of Data Authenticity) describes the second half of the chain: "an authenticated user" can "install a modified firmware" because "the firmware signature verification is enforced only on the client-side dedicated software Enervista UR Setup" and not on the N60 relay itself.

Nozomi Networks Labs' own write-up states the combined effect in plain terms: "By executing the MITM attack, an attacker can intercept and acquire valid credentials for the GE Vernova N60 Network Relay. With these credentials, and due to the lack of firmware verification, the attacker can then upload malicious firmware to seize control of the device." Neither step alone requires the attacker to already hold valid relay credentials — the missing SSH authentication is what gets them the credentials in the first place.

The remaining three CVEs, all published by NVD on the same day (10 March 2025) and all credited to Nozomi Networks Labs' responsible disclosure, affect EnerVista UR Setup rather than the relay's own firmware:

Two of the three (CVE-2025-27254, CVE-2025-27255) score High, not Medium — a shared, hardcoded decryption key and a user-editable registry flag guarding "startup authentication" are both the kind of design choice that defeats the software's own access control with no privileged access required to exploit, only local access to a machine running EnerVista UR Setup.

Yes. Nozomi Networks Labs' advisory states the remediation directly: "Update the EnerVista UR software to the latest 8.60 version and ensure that the N60 firmware is also upgraded to the newest available release" — check GE Vernova's own current advisory for the latest shipping version before acting, since UR Setup has had further releases since. Beyond patching, Nozomi's write-up recommends the standard compensating controls for any protection relay on a substation network: "Placing the UR inside an electronic security perimeter, deploying and maintaining access controls, robust network monitoring and Intrusion Detection, network segmentation and firewalls." Every one of the five 2025 CVEs assumes the attacker already has network access to the relay's management plane or local access to a workstation running EnerVista UR Setup — none is exploitable from the open internet with no foothold at all, which is exactly what NERC CIP-005's electronic security perimeter requirement is built to deny in the first place.

No — it is at least the second round in four years. CISA's ICSA-21-075-02, filed in 2021, covers nine separate CVEs against the same UR family, including CVE-2021-27426 (Insecure Default Variable Initialization) at CVSS v3 9.8 — the practical ceiling of the scale — and CVE-2021-27430 (Use of Hard-coded Credentials) at 8.4. That advisory credits its findings to "SCADA-X, DOE's Cyber Testing for Resilient Industrial Control Systems (CyTRICS) program, Verve Industrial, and VuMetric" and states that the UR bootloader binary shipped with "unused hardcoded credentials" through firmware version 7.02, plus a separate finding that "a user with physical access to the UR IED can interrupt the boot sequence by rebooting the UR." Two independent CVE rounds against the same relay family, four years apart, found by four different research groups the second time around (Nozomi, versus SCADA-X/DOE CyTRICS/Verve/VuMetric the first time), is the kind of recurring pattern MITRE ATT&CK for ICS and IEC 62351's power-systems communications security guidance both assume will keep happening in fielded protection relays — which is why the relevant question for an asset owner is less "has this specific CVE been patched" and more "is this device inside an electronic security perimeter with change management that would catch an unauthorized firmware push."

It is worth naming plainly, without overclaiming: Nozomi Networks, the firm that found and disclosed these five CVEs, also sells commercial OT network-monitoring sensors built around exactly the compensating control its own advisory recommends. Nozomi's own Guardian product page describes the mechanism as passively learning "a baseline of normal behavior patterns" from traffic and device interactions, then continuously monitoring "for deviations from the baseline to detect anomalous traffic, unusual process values and threats." That is a real, commercially available technique — behavioral baselining of OT protocol traffic, not a vague "AI will catch it" claim — and it is a genuinely useful compensating control for exactly the gap these CVEs expose: a relay with no firmware-signature enforcement of its own has no way to refuse a malicious update, so the practical defense shifts to the network layer, watching for the kind of unusual engineering-workstation-to-relay traffic a firmware push or credential-harvesting MITM would generate. It does not, on its own, fix a missing SSH authentication check or a hardcoded password — those still need the vendor patch.