Lede

Dragos's ninth annual OT Cybersecurity Year in Review, released February 17, 2026, will mostly be read for one finding: VOLTZITE crossed into Stage 2 of the ICS Cyber Kill Chain in 2025. The path there is now fully documented: VOLTZITE compromised Sierra Wireless Airlink RV50 and RV55 cellular gateways at U.S. midstream pipeline operations (with activity extending into upstream and downstream environments too), using the gateways' exposed web management interfaces, then pivoted from those gateways to engineering workstations, where it manipulated industrial software to dump configuration files and alarm data — explicitly to investigate what would trigger operational processes to stop. That capability shift, moving from data theft to direct interaction with engineering workstations, is what earned VOLTZITE its Stage 2 designation. It's a real escalation, and it's the headline most outlets chasing this report will run with.

It's not the most important finding in the report.

Further into the report's vulnerability section is a quieter, less narratively satisfying set of findings: following a U.S. Department of Energy whitepaper on battery energy storage systems (BESS), Dragos ran its own internal research project evaluating Nuvation BMS battery management systems and Nuvation's Multi-Stack Controllers (MSCs) — U.S./Canada-manufactured, globally distributed. Dragos found authentication bypass and OS command injection vulnerabilities in the MSC, the internet-facing component, along with a separate flaw in Nuvation's cloud management service that let any authenticated user manipulate other customers' battery systems. The picture is more mixed than "patched and closed," though: of the seven CVEs Dragos's own advisory documents for this disclosure (CVE-2025-64119 through -64125), most are fixed in MSC firmware 2.5.1, but the highest-severity flaw in the set — CVE-2025-64123, CVSS 9.9 — is explicitly listed as still present and impacting the MSC including its current release. Full details are published under Dragos advisory VA-2025-06.

Separately — and this is the detail that got flattened in press coverage — Dragos scanned the internet for devices implementing SunSpec, an industry-standard data-model overlay used on Modbus and DNP3 for solar inverters, battery systems, and other distributed energy hardware broadly, not just Nuvation's. That scan turned up just over 100 exposed devices, including 1MW-class power inverters built to feed power directly into utility grids, several of which appeared to be live in production with readable output in the 500–900kW range. SunSpec-Modbus, as a control-systems protocol, permits manipulation without authentication by design — this isn't a single vendor's bug, it's a protocol-level exposure across an entire hardware category.

We think that's the sharper story for 2026, and here's the analytical case for why.

Why BESS over VOLTZITE. VOLTZITE's Stage 2 capability is significant, but it describes an adversary getting better at something defenders have spent a decade building doctrine around: engineering-workstation compromise, kill-chain staging, ICS-specific detection. The institutional muscle memory — however imperfect in practice — exists. BESS is different. Grid-scale battery storage is a comparatively new asset class, deployed at speed to meet renewable-integration and grid-stability demand, and Dragos's own reporting makes the scrutiny gap explicit: it found no SunSpec device yet implementing the SunSpec Alliance's own published security specifications, and remains skeptical those specifications would meaningfully stop a modern threat group even where implemented. An authentication bypass on a legacy PLC is a known failure mode defenders have learned to hunt for. Unauthenticated-by-design manipulation of a 1MW inverter sitting on the public internet is a failure mode the industry hasn't yet built reflexes around — and the devices in question aren't passive sensors; they're capable of injecting power onto the grid, and capable of being disconnected remotely.

This is not a hypothetical concern manufactured for effect. Dragos CEO Robert M. Lee tied the finding directly to the report's broader visibility thesis: "If organizations cannot monitor their systems today, they'll find that future adoption of technologies like AI, battery storage, and distributed energy resources creates exponentially greater blind spots." And Dragos isn't speculating about whether distributed energy resources are already a live target category: in late December 2025, ELECTRUM conducted what Dragos assesses with moderate confidence was a coordinated cyberattack against Polish energy infrastructure — including combined heat and power facilities and renewable energy generation management systems — with deliberate attempts to directly affect operational assets, not merely reconnaissance. [FACT, High confidence on the event; ASSESSMENT, moderate confidence on ELECTRUM attribution — primary source] Polish authorities' defensive measures prevented disruption to national power delivery, and Dragos notes its attribution assessment remains preliminary. BESS sits in the same asset family as the systems ELECTRUM targeted. The exposure isn't theoretical; the targeting pattern against adjacent infrastructure already exists.

There is also a meta-point worth flagging up front, because it bears directly on how much weight to put on any single ICS vulnerability score going forward: Dragos found that 15 percent of CISA and NVD CVEs carried incorrect CVSS scores in 2025, the majority of those corrections moving severity up rather than down — and 25 percent of advisories shipped with no patch or mitigation at all. That's a sourcing-discipline reminder that applies to this story as much as any other.

The rest of this piece works through both findings in full — what Dragos observed, what's assessment versus speculation, and what each means operationally for defenders. But the framing holds: a nation-state group getting better at a known playbook, however newsworthy, follows a path defenders have instrumented for before. An entire hardware category — grid-injection-capable, exposed at meaningful scale, with no vendor in the ecosystem yet implementing adequate authentication — sitting unmonitored at the literal injection point of grid power is the thing that should be keeping OT defenders up at night in 2026.

Observed Facts

What follows is confined to what Dragos has stated directly in the full 91-page 2026 OT Cybersecurity Year in Review report. Anything inferential is held for later sections.

BESS / Nuvation findings. Following a U.S. Department of Energy whitepaper on battery energy storage systems, Dragos ran an internal research project evaluating Nuvation BMS battery management systems and Nuvation Multi-Stack Controllers (MSCs) — manufactured in the U.S. and Canada, distributed globally. Dragos found that the Nuvation BMS itself, as a field device, has no meaningful security: direct network access permits disconnecting batteries and changing battery chemistry, capacity, reserve capacity, shunt, and relay settings, which Dragos states can produce loss of control, loss of view, manipulation of control, and manipulation of view in a BESS. For this reason, the BMS is not intended to be exposed to higher-level networks. Separately, Dragos evaluated the MSC — which is intended for exposure to higher-level networks and provides cloud access for remote monitoring and reconfiguration — and identified authentication bypass and OS command injection vulnerabilities there.

Dragos's own published advisory for this disclosure (covering seven CVEs, 2025-64119 through -64125) gives a more granular patch picture than the Year in Review narrative's "since fixed by the vendor" summary, and the two documents are not fully consistent with each other. Two of the seven — OS command injection (CVE-2025-64120, CVSS 9.9) and authentication bypass (CVE-2025-64121, CVSS 9.8), both introduced in MSC firmware 2.3.8 — are fixed in version 2.5.1. Two more present in all prior MSC builds — a hardcoded private key on-device (CVE-2025-64122, CVSS 8.8) and a second, separate OS command injection (CVE-2025-64124, CVSS 8.5) — are also fixed in 2.5.1. The BMS-level client-side authentication flaw (CVE-2025-64119, CVSS 9.8) affects the BMS up through its current software release, with no fix stated. Most significantly, CVE-2025-64123 (CWE-441, "Unintended Proxy or Intermediary," CVSS 9.9) — the highest-severity vulnerability in the set — is explicitly listed in the advisory as still present and impacting the MSC including its current release. Only the nCloud/VPN-side flaw (CVE-2025-64125) is described as remediated automatically for all customers. The Year in Review report's characterization that the MSC issues were "since fixed" and the cloud issue "fixed... as of December 2025" is accurate for some of the seven CVEs but not for the most severe one, which remains unpatched as of the advisory's last update. Full technical detail is published under Dragos advisory VA-2025-06.

The SunSpec scan and the 1MW inverters. Separately from the Nuvation-specific findings, Dragos scanned the internet for devices implementing SunSpec — an industry-standard data-model overlay implementable on Modbus or DNP3 that provides a self-describing map of a device's data and control points, used across inverters and other distributed energy hardware industry-wide, not specific to Nuvation. That scan found just over 100 devices, including 1MW power inverters designed to supply grid power to electric utilities; these inverters carry remote control capability including the ability to disconnect, and several appeared to be in production, with readable output of 500–900kW during daylight hours. SunSpec Modbus, as a traditional control-systems protocol, permits manipulation without authentication; protection is consequently device-dependent rather than protocol-guaranteed. Dragos notes the SunSpec Alliance has published security specifications covering firmware-upgrade and authentication requirements, but Dragos has not yet identified any device implementing that security profile, and states it remains skeptical the specifications would offer adequate protection against modern threat groups even where implemented.

VOLTZITE's capability and access path. VOLTZITE's most impactful 2025 campaign involved compromising Sierra Wireless Airlink RV50 and RV55 cellular gateways via their exposed web interfaces (TCP/9191, TCP/9443) across Electric and Oil and Gas organizations. This activity primarily targeted U.S. midstream pipeline operations, with activity also extending into upstream and downstream environments. The Sierra Wireless devices served as entry points for lateral movement into OT networks; from there, VOLTZITE pivoted to engineering workstations, where it manipulated industrial software to dump configuration files and alarm data, explicitly to investigate what would trigger operational processes to stop. This capability — direct manipulation of engineering-workstation software, not merely data exfiltration — is what led Dragos to designate VOLTZITE a Stage 2 threat group. VOLTZITE separately leveraged the JDY botnet to conduct reconnaissance of VPN appliances (F5 Big-IP, Palo Alto GlobalProtect, Citrix) across Energy, Oil and Gas, and Defense sectors, assessed with moderate confidence as pre-staging rather than confirmed exploitation, and exploited a Trimble Cityworks GIS software vulnerability (CVE-2025-0994) with low-confidence operational overlap to VOLTZITE.

SYLVANITE's role. SYLVANITE is a Stage 1, initial-access threat group operating at scale by exploiting newly disclosed vulnerabilities in internet-facing products (F5, Ivanti, SAP, ConnectWise, among others) almost immediately after public proof-of-concept code appears. Dragos has directly observed SYLVANITE handing off initial access to VOLTZITE during intrusions, and in 2025 directly observed SYLVANITE activity within the U.S. electric and water utility sector during an incident response. One specific documented instance: in May 2025, Dragos responded to an incident in which SYLVANITE (tracked initially as TAT25-43) compromised a U.S. utility's Ivanti Endpoint Manager Mobile (EPMM) instance via CVE-2025-4427 and CVE-2025-4428, sited in the utility's DMZ; Dragos could not determine via network telemetry whether the adversary pivoted into adjacent OT networks from that foothold, due to a lack of monitoring coverage in those adjacent networks. SYLVANITE's general pattern — Stage 1 access handed to VOLTZITE — is distinct from the specific Sierra Wireless/pipeline campaign described above, which Dragos attributes directly to VOLTZITE rather than describing as a SYLVANITE-enabled handoff.

KAMACITE's separate reconnaissance campaign, and the Sierra Wireless overlap. Independent of VOLTZITE's pipeline campaign, KAMACITE — the access-development group that feeds ELECTRUM — conducted sustained reconnaissance of internet-exposed U.S. industrial devices between March and July 2025, targeting Schneider Electric Altivar variable-frequency drives, Smart HMIs, Accuenergy AXM modules, and Sierra Wireless Airlink gateways in sequence, which Dragos assesses reflects intent to map entire control loops rather than scan isolated devices. Dragos found no evidence of successful exploitation during this specific reconnaissance window. Dragos explicitly notes that Sierra Wireless Airlink devices have previously been compromised to enable lateral movement into ICS environments, including by VOLTZITE in 2025 — meaning the device family, not a single campaign, is the recurring point of exposure across multiple threat groups.

Adjacent distributed-energy targeting. In late December 2025, a coordinated cyberattack occurred against Polish energy infrastructure, including combined heat and power facilities and renewable energy generation management systems, with Polish authorities attributing the activity to actors linked to Russian state services and stating defensive measures prevented disruption to national power delivery. Dragos assesses with moderate confidence that the activity's tradecraft and objectives are consistent with ELECTRUM, explicitly flagging this attribution as preliminary and subject to refinement. [ASSESSMENT, Moderate confidence — primary source] This is a separate threat group and asset class from BESS specifically, but it confirms distributed energy resources broadly are an active, not merely theoretical, 2025 targeting category.

Assessment — Why BESS Is the Underappreciated Story

Layer 1 established what Dragos observed. This section moves to assessment: what that evidence suggests, and why it points toward BESS as the more analytically significant finding in the report, even though VOLTZITE will get the headlines.

The scrutiny gap is structural, not anecdotal. Dragos's own evaluation found that the Nuvation BMS — a field device — has no meaningful security at all, by design, and is explicitly not intended for exposure to higher-level networks. That's a vendor acknowledging the device was never built to survive direct network contact. The MSC, which is built for that exposure and offers cloud connectivity, still carried an authentication bypass and OS command injection. [ASSESSMENT, High confidence] The pattern across both products is consistent with an industry that has prioritized remote manageability and cloud integration ahead of the authentication discipline that legacy ICS vendors were forced into over the past fifteen years of public scrutiny, breach disclosure, and regulatory pressure. SCADA and PLC vendors didn't arrive at today's (still-imperfect) hardening posture voluntarily — they got there because Stuxnet, the Ukrainian grid attacks, and a decade of Dragos-style public reporting made insecure-by-default unacceptable. BESS vendors are, by Dragos's own account, earlier in that same forcing process.

SunSpec is the more important finding than any single CVE. The Nuvation vulnerabilities are now patched — a contained, vendor-specific story with a clean resolution. The SunSpec finding is not contained, and that's precisely why it matters more. SunSpec is an industry-standard overlay used across inverter and battery hardware broadly, not a Nuvation peculiarity, and Dragos states plainly that SunSpec Modbus permits manipulation without authentication as a property of the protocol itself. Dragos further reports that it has not identified a single device in the wild implementing the SunSpec Alliance's own published security specifications — and states it remains skeptical those specifications would meaningfully stop a modern threat group even where adopted. [ASSESSMENT, High confidence — Dragos's stated position] That combination — an unauthenticated-by-design protocol, an available but unadopted security standard, and demonstrated skepticism from the firm that wrote the assessment about whether the standard would help anyway — describes a structural exposure across an entire device class, not a bug waiting on a patch Tuesday. Fixing Nuvation's MSC closes one door. It does nothing about the other 99-plus devices Dragos found, or the ones it didn't scan for.

Scale and consequence class matter here. A handful of internet-exposed PLCs at small industrial sites is a known, if persistent, risk category defenders have instrumented detection around for years. What Dragos found instead were 1MW-class power inverters — several apparently live in production, with output Dragos could read directly from the exposed interface — carrying documented remote-disconnect capability. This is not a sensor or a telemetry endpoint; it's a device that injects power onto the grid and can be told to stop. The consequence class of an authentication-bypassed PLC controlling a single process line and an unauthenticated 1MW grid-tied inverter are not comparable, and the latter is the one with no vendor in the entire device family currently implementing adequate authentication.

The subcontracting layer compounds the exposure. Dragos's report flags something easy to miss in a vulnerability writeup: management of BESS and other SunSpec-compliant systems is frequently outsourced to firms specializing in battery or distributed-energy operations — firms that, per Dragos, often lack cybersecurity expertise themselves. That's a supply-chain observation, not a speculative one: it means the operational owner of a given grid-tied inverter may not be the entity actually managing its network exposure, and the entity that is managing it may not have the security posture to know the exposure exists. This is structurally similar to the OT-adjacent and supply-chain targeting pattern Dragos documents elsewhere in the report — ransomware affiliates increasingly going after engineering firms and ICS vendors specifically because compromising them yields leverage across an entire client base rather than a single site — except here the gap isn't being actively exploited by a tracked threat group yet. It's sitting open.

ELECTRUM's Poland campaign is the closest real-world analog, and it's already happened. Dragos assesses with moderate confidence — explicitly flagged as preliminary — that the actors behind the late-December 2025 attack on Polish energy infrastructure were operating with ELECTRUM-consistent tradecraft, targeting combined heat and power facilities and renewable energy generation management systems with deliberate attempts to affect operational assets rather than confining themselves to reconnaissance. [ASSESSMENT, Moderate confidence — primary source] We should be precise about what this analogy does and doesn't establish: ELECTRUM's target was CHP and renewable-management infrastructure, not battery storage specifically, and Dragos's own attribution here is preliminary rather than settled. What it does establish is that a top-tier, state-linked OT threat group capable of causing the 2015 and 2016 Ukrainian grid outages has already moved against the broader distributed-energy-resource category that BESS belongs to, with intent to affect operations rather than merely surveil them. [ASSESSMENT, Moderate confidence] If BESS hasn't yet drawn comparable attention from a Dragos-tracked Stage 2 group, that is current absence of evidence, not evidence of disinterest — particularly set against a device class this exposed.

Where this assessment could be wrong. A skeptical read should note: Dragos's BESS research is its own internal project, not an account of observed adversary activity against BESS specifically — nobody has yet been caught exploiting a SunSpec inverter in the wild, per anything in this report. The risk case here rests on exposure and capability, not on a documented intrusion, which is a meaningfully different evidentiary footing than the VOLTZITE or ELECTRUM findings in this same report. That distinction carries into how this story should be labeled for publication, and we address it directly in the next section.

VOLTZITE's Stage 2 Move, Properly Caveated

The BESS case rests on exposure and unexploited capability. VOLTZITE's case rests on something different: an observed escalation against a named target sector, with Dragos's own methodology specifying exactly what "Stage 2" does and doesn't mean. That precision is worth holding onto, because "Stage 2 adversary" is the kind of phrase that's easy to let drift toward something scarier than what Dragos actually documented.

What Stage 2 means, per Dragos's stated methodology. Dragos aligns its threat-group classifications to the SANS ICS Cyber Kill Chain. Its own methodology section is explicit on the threshold: targeting an organization that happens to have OT networks isn't sufficient for a Stage 1 designation — the targeting has to be because of the OT networks. Stage 2 is reached when "the adversary gains access to OT networks and the activity appears intentional." That's a deliberately narrow bar. It does not require manipulation of a physical process, does not require an attempt at disruption, and does not require ICS-specific malware. It requires demonstrated intent to operate inside OT, as distinct from incidentally touching a network that happens to contain OT assets.

What VOLTZITE actually did, measured against that bar. VOLTZITE compromised Sierra Wireless Airlink gateways at U.S. midstream pipeline operations, then pivoted to engineering workstations and manipulated software there to dump configuration files and alarm data — specifically to investigate what would trigger operational processes to stop. That is intentional, OT-directed activity: it clears the Stage 2 bar as Dragos defines it. But it's worth being precise about what it is not. It is not an attempt to issue a stop command. It is not malware purpose-built to manipulate a control process — by way of comparison, the report's own ICS Cyber Kill Chain diagrams for VOLTZITE show activity occupying Stage 2's "Develop" phase, not "Execute ICS Attack." Dragos's language throughout is reconnaissance-into-disruption framing: investigating triggers, not pulling them. The distinction matters because "Stage 2 threat group" and "threat group that has disrupted a process" are different claims, and conflating them overstates what's been observed.

Useful contrast: AZURITE, in the same report, at the same stage, with an explicit confidence caveat. Dragos introduces AZURITE this year as another Stage 2 adversary with a very similar profile to VOLTZITE — engineering-workstation access, exfiltration of alarm data and configuration files — and is unusually direct about the limits of that designation: Dragos assesses with moderate confidence that AZURITE does not possess a Stage 2 tool or malware capability specifically built to target OT processes, hardware, protocols, or software. AZURITE has demonstrated the capability to operate in OT environments — reconnaissance, lateral movement, actions on objective — but Dragos states plainly it has not been observed manipulating, stopping, or modifying OT-specific software; only identifying and exfiltrating information already present on target assets. Dragos's own read of AZURITE's intent is that this collection activity is "highly likely to support capability development... for the preparation of offensive operations in case of geopolitical conflict" — a forward-looking assessment, not a claim about present disruptive capability. The structural similarity to VOLTZITE is instructive: both groups are Stage 2 by Dragos's defined bar; neither has been observed actually disrupting a physical process. The "Stage 2" label is doing real classificatory work, but it is not synonymous with "has caused or attempted to cause operational impact."

What is genuinely new and significant about VOLTZITE specifically. None of the above should read as minimizing the finding. What distinguishes VOLTZITE's 2025 activity from a purely reconnaissance posture is the specificity of intent Dragos documents: investigating what triggers a process to stop is qualitatively different from generic configuration harvesting. It's targeted operational-impact research, even absent an attempt to execute on it. Dragos's broader framing in the report's introduction makes the same point at the portfolio level, not just for VOLTZITE: multiple threat groups in 2025, independently and across different geopolitical alignments, moved into "actively mapping control loops: identifying engineering workstations, exfiltrating configuration files and alarm data, and learning how physical processes operate well enough to disrupt them."

Dragos characterizes this collectively as "the removal of the last practical barrier between having access and being able to cause physical consequences," and assesses that it indicates these operator teams "are being told to prepare to act, not just to maintain options." [ASSESSMENT, High confidence — primary source, Dragos's stated interpretation] That's the real headline, and VOLTZITE is one instance of a pattern Dragos sees across several unrelated groups simultaneously — which is itself a higher-confidence, more significant claim than any single group's status change.

Where this leaves the comparison to BESS. VOLTZITE's escalation is observed, intentional, OT-directed activity against a named critical-infrastructure target, sourced to a specific campaign with specific technical detail — a stronger evidentiary position than the BESS finding, which remains exposure-and-capability without an observed intrusion. Where BESS wins the comparison is in scope and institutional readiness: VOLTZITE's playbook (engineering-workstation compromise via compromised edge infrastructure) is a pattern Dragos and the broader ICS-defense community have spent years building detection doctrine around, even if that doctrine isn't universally deployed. The SunSpec exposure has no comparable detection doctrine anywhere in the industry, by Dragos's own account, because no vendor has yet implemented the security profile that would make such doctrine meaningful. Both findings are real. They are not, however, equally well-defended against — and that gap, not the relative drama of either finding, is the actual argument for treating BESS as the sharper story for defenders to act on in 2026.

Explicit Flags: What We Don't Know

The full report and Dragos's own published advisory resolved nearly every factual gap identified earlier in this piece's development — vendor names, CVE IDs, patch status down to the individual flaw. What remains open at this point is not missing sourcing but genuine analytical uncertainty: places where the evidence runs out, where Dragos itself flags preliminary judgment, or where this piece's own framing makes a contestable call.

The central prioritization claim is an editorial judgment, not a Dragos finding. Dragos's report does not rank BESS exposure above VOLTZITE's Stage 2 escalation — that framing is this piece's analytical contribution, built in Section III and IV. It rests on an argument about scope and institutional readiness. That argument is defensible, but a skeptical reader could reasonably invert it: a documented intrusion into U.S. critical infrastructure with demonstrated intent to research process-stopping triggers is arguably a more urgent signal than an exposure nobody has yet been caught exploiting. We are not here presenting the BESS-over-VOLTZITE framing as Dragos's conclusion. It's ours.

No adversary has been observed exploiting the SunSpec exposure or the Nuvation vulnerabilities. This remains the load-bearing caveat for the BESS argument. Dragos's BESS and SunSpec findings come from its own internal research project, not from incident response or observed intrusion activity. Nothing in the report or the advisory ties any named threat group to actual exploitation. The risk case rests on demonstrated capability and exposure at scale, which is a different evidentiary class than the VOLTZITE or ELECTRUM findings in the same report.

The patch status of the Nuvation vulnerabilities is more granular — and partly more concerning — than the report's summary suggests. We followed up directly against Dragos's published advisory for CVE-2025-64119 (covering the full vulnerability set, CVE-2025-64119 through -64125), and the picture is meaningfully more specific than "since fixed by the vendor." There are seven distinct CVEs, not one. Two — CVE-2025-64120 (OS command injection, CVSS 9.9) and CVE-2025-64121 (authentication bypass, CVSS 9.8) — were introduced in MSC firmware version 2.3.8 and are fixed in 2.5.1. Two more — CVE-2025-64122 (hardcoded private key on device, CVSS 8.8) and CVE-2025-64124 (a second, separate OS command injection, CVSS 8.5) — were present in all prior MSC builds and are also fixed in 2.5.1. CVE-2025-64119 (client-side authentication, CVSS 9.8) affects the BMS itself up to and including its current software release; the advisory does not state this one as fixed. Most significantly: CVE-2025-64123 (CWE-441, "Unintended Proxy or Intermediary," CVSS 9.9) is explicitly listed as "still present and impacts the MSC including the current release" — meaning the highest-severity vulnerability in the set remains unpatched as of the advisory's last update. Only the nCloud/VPN-side flaw, CVE-2025-64125, is described as remediated automatically for all customers. This contradicts, or at minimum substantially complicates, the report narrative's framing that the MSC issues were "since fixed by the vendor" — that framing was accurate for some of the seven CVEs and not for the most severe one. Any digest version of this story needs to carry the unpatched CVE-2025-64123 status explicitly rather than repeating the report's more reassuring summary language.

We found no independent CISA ICS-CERT advisory corroborating or cross-publishing this disclosure. A search for a CISA-side advisory tied to CVE-2025-64119 or the broader Nuvation CVE set returned nothing matching in CISA's published ICS advisories. However, to be clear — absence of evidence is not evidence of absence; CISA publication lag or a decision not to co-publish are both plausible. This is consistent with Dragos's own reported finding elsewhere in the same report that a meaningful share of advisories take a long time to reach NVD/CISA publication, or never receive a patch/mitigation at all — but we can't confirm whether this specific disclosure is simply pending or was never escalated to CISA. Readers relying solely on CISA's KEV or ICS advisory feeds would not currently see this finding; Dragos's own advisory page is the only public source we've located.

The broader population of 100-plus internet-scanned SunSpec devices remains entirely unaddressed in available sourcing. This is distinct from the Nuvation-specific CVEs above. Dragos's internet scan for SunSpec-Modbus implementations generally — not limited to Nuvation hardware — found just over 100 exposed devices including the 1MW-class inverters. Neither the report nor the Nuvation advisory states whether Dragos notified the owners or operators of those specific devices, whether any disclosure or remediation process followed, or whether those devices remain exposed today. We have no basis for claiming those devices have been secured, and no basis for claiming they haven't. This is the cleanest remaining "unknown" in the piece, and it should be reported as exactly that rather than implied either way.

The ELECTRUM/Poland attribution is explicitly preliminary, per Dragos's own statement. Dragos assesses the late-December 2025 Polish energy attack as ELECTRUM-consistent tradecraft with moderate confidence, and states outright that the assessment "remains preliminary and subject to refinement as additional information becomes available." Dragos also notes it cannot disclose specific technical details due to source-handling constraints. We've treated this as the weakest-sourced attribution claim in the piece and labeled it accordingly throughout.

KAMACITE's scanning campaign found no successful exploitation. The March–July 2025 KAMACITE reconnaissance campaign against Schneider Electric Altivar drives, Smart HMIs, Accuenergy AXM modules, and Sierra Wireless Airlink gateways was reconnaissance only, per Dragos's explicit statement. We should not let "KAMACITE mapped U.S. industrial devices" read as "KAMACITE breached U.S. industrial devices."

SYLVANITE's specific OT-pivot status in the Ivanti EPMM case is unresolved because Dragos's own visibility didn't extend far enough to answer it. Dragos states it could not determine whether the adversary pivoted from the compromised Ivanti EPMM server into the utility's adjacent OT networks, due to a lack of telemetry there. This is a concrete instance of the report's broader visibility-crisis finding (fewer than 10 percent of OT networks worldwide have monitoring in place) actually preventing a specific incident from being fully understood, not a sourcing gap on our end.

Source-Discipline Sidebar: The CVSS Data Point

Everything in this piece up to now has leaned on specific severity numbers — CVSS 9.9 here, CVSS 8.5 there — as a shorthand for how seriously to take a given finding. Dragos's own report contains a finding that should make us, and any reader, treat that shorthand with more caution than usual, including within this piece.

What Dragos found. Dragos determined that 15 percent of CISA and NVD CVEs had incorrect CVSS scores in 2025. Of the corrections Dragos made, 64 percent moved severity higher than the original public score, 31 percent moved it lower, and the remaining 4 percent involved incorrect attributes that didn't change the numeric score itself. Dragos attributes the higher-severity corrections largely to vendors understating severity in their own disclosures. Separately, Dragos found that 25 percent of public advisories shipped with no patch or mitigation advice at all, leaving asset owners without a clear path to reduce risk even when a CVE number and a severity score exist. Dragos's analysts state they provided tailored mitigation advice for 52 percent of the advisories that were initially missing it.

Why this matters for everything else in this piece. We've cited CVSS scores throughout — 9.8 and 9.9 for several of the Nuvation MSC flaws, for instance — pulled directly from Dragos's own advisory. Those numbers came from the vendor most likely to catch a scoring error if one exists, which gives them more credibility than an average CISA/NVD entry. But Dragos's own statistic is a reminder that even a number from a careful source is a snapshot, not a guarantee: a 9.9 today could be revised in either direction as more analysis is done, and a missing mitigation note doesn't mean a mitigation doesn't exist, only that nobody has published one yet. We should not let the precision of a CVSS decimal create false confidence about how settled any of these assessments actually are.

Why this matters specifically for the BESS/SunSpec story. This is where the sourcing-discipline point bites hardest in this piece. The SunSpec finding — the protocol-level, no-authentication-by-design exposure across the broader device class — doesn't carry a CVSS score at all, because it isn't a single vulnerability; it's a property of an industry-standard data model implemented across many vendors' hardware. There is no scoring mechanism that would apply uniformly to "Dragos found 100-plus internet-exposed devices implementing a protocol that allows unauthenticated manipulation." That absence of a clean severity number is not evidence the finding is less serious than the Nuvation CVEs — if anything, the inability to score it with a single CVSS reflects exactly the kind of systemic, cross-vendor exposure that a per-product vulnerability database isn't built to capture. Readers should not unconsciously discount the SunSpec finding because it doesn't come dressed in a 9.9.

The standing rule going forward. Per BCG's source-weighting principles, this is a reminder we're applying to our own reporting, not just relaying as an interesting Dragos statistic: treat any single ICS CVSS score — including the ones in this piece, including Dragos's own — as provisional rather than authoritative, and treat the absence of a CVSS score as a gap in the scoring system before treating it as a gap in severity. We'll carry that standard through the rest of this piece and into the digest item drawn from it.

Operational Significance

Per BCG's standing framework, every major item gets evaluated against four questions before we draft defensive guidance. We apply that here to both findings — BESS/SunSpec and VOLTZITE — rather than collapsing them into one generic "patch and segment" conclusion.

BESS / SunSpec exposure

What actually happened (Layer 1). Dragos found authentication bypass and OS command injection vulnerabilities in Nuvation's Multi-Stack Controller, with one of seven associated CVEs (CVE-2025-64123, CVSS 9.9) still unpatched as of the advisory's last update. Separately, an internet-wide scan for devices implementing the SunSpec data-model overlay turned up just over 100 exposed devices, including 1MW-class grid-tied inverters with remote-disconnect capability, several apparently live in production.

Why it matters operationally. This is a new attack surface category entering the same exposure tier as any other internet-facing OT appliance, except without the decade of hardening pressure that's been applied to PLC and SCADA vendors. The relevant trust mechanism being abused is authentication itself — or its absence: SunSpec Modbus permits manipulation without authentication as a property of the protocol, not as a vendor-specific bug, and Dragos found no device anywhere implementing the SunSpec Alliance's own published security profile. The detection gap is correspondingly total: there is no documented industry baseline yet for what "normal" SunSpec traffic looks like at a given site, because the OT-security community hasn't had reason to build one until now.

What capability this gives an attacker. Using MITRE ATT&CK for ICS language where it applies: an attacker locating an exposed SunSpec-compliant inverter or an unpatched Nuvation MSC gains Initial Access via Internet Accessible Device (T0883) — MITRE's term for systems reachable directly from the internet without needing to defeat an exploit or authentication mechanism, which describes the SunSpec exposure precisely, since the protocol permits manipulation without authentication by design. Where the Nuvation MSC's specific OS command injection flaws are used rather than the unauthenticated SunSpec path itself, that's better described as Exploitation of Remote Services (T0866) — a vulnerability in the remote-management service enabling code execution, distinct from simply walking in through an open door. From either path, the attacker gains direct, unauthorized command of a physical process: the ability to disconnect a grid-tied inverter, alter reported battery state, or change relay and capacity settings. This maps most directly to Loss of Control and Manipulation of View in ICS impact terms — an operator's dashboard could show one state while the device does another, or a device could be disconnected from the grid without the controlling utility's input.

What defenders should do next. Patch the Nuvation MSC to nPlatform 2.5.1 immediately for the CVEs that have fixes, and treat CVE-2025-64123 as unmitigated until Dragos or the vendor states otherwise — restrict MSC and BMS network access in the meantime, particularly TCP/80, TCP/502, TCP/443, and TCP/3003, and consider blocking outbound UDP/1194 from the MSC as Dragos itself recommends. More importantly for the structural finding: any organization operating BESS, solar inverters, or other SunSpec-compliant distributed energy hardware should treat that hardware as a critical ICS asset requiring the same segmentation, monitoring, and remote-access discipline as a PLC or RTU — not as a peripheral or "smart grid" device living outside the OT security perimeter. Specifically: remove direct internet exposure for BMS and inverter management interfaces; if a vendor-managed cloud or VPN service is in use, evaluate it for cross-tenant access control failures (the exact failure mode Dragos found in Nuvation's cloud service); and build a detection baseline for SunSpec/Modbus traffic now, before an incident forces it. Asset owners should also push their BESS and inverter vendors on whether SunSpec security-profile implementation is on a roadmap, while bearing in mind Dragos's own skepticism that the published security specification would meaningfully stop a capable adversary even if adopted.

VOLTZITE's Stage 2 escalation

What actually happened (Layer 1). VOLTZITE compromised Sierra Wireless Airlink RV50/RV55 cellular gateways via exposed web management interfaces at U.S. midstream pipeline operations (with activity extending into upstream and downstream environments), then pivoted to engineering workstations and manipulated software there to dump configuration files and alarm data, specifically to investigate what would trigger operational processes to stop.

Why it matters operationally. The trust mechanism abused here is the assumption that a cellular gateway sitting at the OT network edge is a low-value target — Dragos's own report notes these devices frequently sit in unmonitored locations, create unauthorized pathways that bypass conventional perimeter controls, and are often unknown to IT security teams entirely. The detection gap VOLTZITE exploited is the same one Dragos flags across the report at the portfolio level: fewer than 10 percent of OT networks worldwide have adequate visibility, meaning a pivot from a compromised gateway to an engineering workstation can occur with no one watching the boundary in between.

What capability this gives an attacker. In MITRE ATT&CK for ICS terms: compromising the Sierra Wireless gateway via its exposed web interface is Exploitation of Remote Services (T0866) for Initial Access — the management interface had a software vulnerability enabling remote service abuse, distinct from simply reaching an unprotected device. The pivot to engineering workstations and the dumping of configuration and alarm data sits in the Collection tactic, most likely corresponding to Data from Information Repositories (T0811) given the nature of the files taken, paired with discovery-style enumeration of what would trigger a process to stop. This is reconnaissance with operational-disruption intent, not disruption itself — Dragos's own kill-chain placement for this activity sits at Stage 2 "Develop," not "Execute ICS Attack." The capability gained is the information needed to cause Loss of Control or Loss of View in a future operation, not those impacts themselves.

What defenders should do next. Sierra Wireless Airlink devices and comparable industrial cellular gateways should be inventoried explicitly — Dragos notes IT security teams frequently don't know these devices exist in their own OT environments — and their web management interfaces (the specific ports VOLTZITE used: TCP/9191, TCP/9443) should not be internet-facing. Engineering workstations should be treated as high-value targets requiring their own monitoring baseline distinct from general IT endpoint protection: detect anomalous access patterns, unexpected software manipulation, and unusual outbound data transfers from these systems specifically. Organizations in midstream pipeline operations, and more broadly Electric and Oil & Gas sectors generally, should hunt specifically for the SYLVANITE/VOLTZITE handoff pattern Dragos documents elsewhere in the report — VPN and remote-access compromise followed by lateral movement toward GIS servers and engineering workstations — even where VOLTZITE itself hasn't been the directly attributed actor in a given environment.

Close

Start where this piece started: Dragos's ninth annual Year in Review will be read, correctly, for VOLTZITE's move into Stage 2 of the ICS Cyber Kill Chain. That's a real escalation, attributed to a specific group, against a specific sector, with a documented access chain — Sierra Wireless Airlink compromise at U.S. midstream pipeline operations, a pivot to engineering workstations, and deliberate research into what would make an operational process stop. It is the kind of finding the OT-defense community has spent the better part of a decade building doctrine to detect, even where that doctrine remains unevenly deployed. Nation-state escalation against critical infrastructure is news, and it should be treated as such.

It is not, by itself, the most consequential finding in this report.

The quieter story — Dragos's own BESS and SunSpec research, tucked into a vulnerabilities section that most outlets will skip past on the way to the threat-group profiles — describes something with no comparable detection doctrine anywhere in the industry, because the industry hasn't needed one until now. An entire hardware category, exposed at meaningful scale, where the relevant security standard exists on paper and has been implemented nowhere; where the vendor's own most severe disclosed vulnerability remains unpatched as of this writing; where management is frequently outsourced to firms that, per Dragos's own account, often lack the expertise to know any of this is a problem. Nobody has been caught exploiting it yet. That is exactly why it deserves attention now, while "yet" is still true.

We've tried to hold both findings to the same standard throughout this piece: separating what Dragos observed from what Dragos assessed, separating what Dragos assessed from what we ourselves are arguing, and flagging plainly where the evidence runs out rather than letting confident-sounding prose paper over a gap. The BESS argument is ours, not Dragos's — built on Dragos's facts, but a layer of analysis Dragos itself didn't make explicit. A skeptical reader is entitled to weigh a documented intrusion into U.S. pipeline infrastructure more heavily than an unexploited exposure, however structurally significant that exposure may be. We've made the case for why we don't, but the case rests on an argument about scope and institutional readiness, not on the relative drama of either finding — and that argument should be read as exactly that: an argument, open to the same challenge we've applied to everything else in this piece.

What shouldn't be in dispute is the practical takeaway for defenders. If your organization touches battery storage, grid-tied inverters, or any other SunSpec-compliant distributed energy hardware, that hardware is not a peripheral IT-adjacent convenience. It is OT, it belongs inside your segmentation boundary, and the absence of a CVE number attached to its core exposure is a gap in how vulnerability databases score systemic risk — not a signal that the risk is small.

— Jonathan Brown, Border Cyber Group | bordercybergroup.com Support independent security journalism!