The Software That Runs the Grid — and the Vulnerabilities No One Is Watching

On July 7, CISA published seven ICS advisories. Two of them came from the same vendor — Hitachi Energy — and neither was about a PLC, a switch, or a serial gateway. One covered e-mesh EMS, the energy management system that grid operators use to monitor, dispatch, and control distributed energy assets. The other covered PROMOD V, the forecasting application utilities rely on to predict load and plan generation.

An energy management system. A forecasting tool. These are the applications that sit at the desk of every control room operator, every grid planner, and every asset manager at a modern utility. They’re not field devices. They’re not OT in the traditional sense. But they touch everything that is.

Applications don’t look like OT — but they control it

Here’s the architecture reality that makes this batch worth paying attention to. An energy management system like e-mesh EMS ingests real-time data from RTUs, substation gateways, and SCADA masters. It issues control commands — open this breaker, shed that load, curtail this solar array. It lives on a server that sits on a network segment that connects, directly or indirectly, to both the corporate LAN and the control system network.

A forecasting tool like PROMOD V pulls historical operational data, weather feeds, and market pricing. Its outputs determine what gets dispatched and when. It may not send control commands directly — but it shapes every operational decision made in the control room that day.

Both applications run on general-purpose operating systems. Both have web interfaces. Both communicate over standard TCP/IP. And both are, for all practical purposes, IT applications with OT consequences.

When the e-mesh advisory landed — CVE-2026-42945, CVSS 8.1, with full confidentiality, integrity, and availability impact — the vulnerability wasn’t in some exotic OT protocol stack. It was in NGINX. The web server. A heap buffer overflow in the ngx_http_rewrite_module, exploitable under the right conditions for remote code execution. The sort of vulnerability that IT security teams patch in their web applications every week. Except this web server sits inside the utility’s operational boundary, and patching it means taking the energy management system offline.

The patch-or-operate dilemma is real

The PROMOD V advisory — CVE-2026-10763 — tells a different but equally instructive story. The application communicates over plain HTTP — no TLS, no encryption. Not because someone forgot to tick a box. Because a third-party component, the Digipede server that PROMOD depends on, doesn’t support HTTPS. The fix isn’t a configuration change. It’s an architectural dependency that requires a vendor-level rework.

Both advisories point to the same structural problem: the software layer that bridges IT planning and OT operations is built, maintained, and secured like IT software — but it sits in a position where a compromise cascades directly into the physical grid.

And here’s the uncomfortable part: neither the IT security team nor the OT security team owns this layer cleanly.

The IT team sees a web application running on a Linux server. They’d love to vulnerability-scan it, push a patch, and move on. But they can’t — scanning an EMS server risks disrupting live grid operations, and the OT team has a change-management window measured in quarters, not days. The OT team sees a system that touches SCADA. They’d love to segment it, monitor its traffic, and treat it like any other Level 2 device on the Purdue model. But it talks HTTP to the weather service API, pulls data from the market pricing platform, and needs access to the corporate identity provider for user authentication. It’s too connected to fully isolate.

So the EMS sits in a grey zone. IT can’t patch it. OT can’t air-gap it. And the attacker — once they’re in — has a beachhead that’s one hop from the SCADA network.

What actual exploitation looks like

Let’s walk through what happens when an attacker exploits the NGINX vulnerability in e-mesh EMS. They gain code execution on the EMS server — not root necessarily, but a process running as the web server user. From there, they have:

Network adjacency to every substation RTU the EMS polls. The EMS server sits on a network segment with routes to field devices. It was designed that way — it needs to reach them.
Valid application-layer credentials. The EMS authenticates to SCADA masters and RTUs. Those credentials — or the session tokens derived from them — are accessible to a process running on the EMS host.
Legitimate traffic patterns to hide behind. The EMS makes regular Modbus and DNP3 reads to field devices. An attacker who adds a few extra reads — or a write — blends into traffic that already looks normal at the protocol level. A signature-based detector sees valid Modbus function codes, valid unit IDs, valid register addresses. Nothing fires.

From the EMS server, the attacker doesn’t need to exploit a PLC directly. They issue commands through the same API the EMS uses — commands that the SCADA master and the RTU have been configured to accept from this source. Every log entry reads “authorised.”

Why signatures can’t cover this

This is the structural limit of signature-based detection, and it’s worth stating clearly. Signatures catch what’s been seen before — a known exploit against a known CVE, a specific byte pattern, a particular command sequence. They’re excellent at that job. But when an attacker compromises an authorised application and issues commands through its legitimate API, there is no exploit signature to match. There is no malware hash. There is no known-bad IP. There is only an EMS server doing what EMS servers do — except at a time it doesn’t normally do it, or at a frequency that doesn’t match the baseline, or to a device it’s never communicated with before.

Detecting that requires knowing what normal looks like — per device, per protocol, per time of day, per operational context. That’s not a signature problem. It’s a behavioural one.

A passive, behavioural NDR platform that learns the network’s normal communication patterns would flag several things in this scenario: the EMS server initiating a connection to a substation RTU it’s never polled before, a Modbus write function code appearing at 3 AM from a device that has only ever issued reads, a DNP3 session originating from a process whose parent process wasn’t the normal EMS service binary. None of these require knowing the attacker’s exploit. None require a CVE to be published first. They require knowing the network well enough to recognise when something has changed.

The operator isn’t the weak link — but they can’t be the only link

Grid operators are trained to spot anomalies — a voltage that doesn’t make sense, a breaker status that contradicts the SCADA display, a load curve that doesn’t match the forecast. But the operator’s screen shows what the EMS shows it. If the attacker is issuing commands through the EMS API, the HMI displays those commands as operator-initiated actions. The alarms that should fire — “unauthorised write to RTU-14” — don’t, because the EMS authenticated the request. From the operator’s perspective, nothing is wrong.

This isn’t a failure of the operator. It’s a failure of the detection architecture to cover the layer where the compromise actually happened. The operator watches the process. The firewall watches the perimeter. The EMS watches the grid. Nobody is watching the EMS itself — at the network level, in real time, against a learned behavioural baseline.

A different way to see the grid

The July 7 advisories aren’t remarkable because a web server had a buffer overflow or because an application used HTTP. Those things happen every day. They’re remarkable because of where they happened — in the software that utilities trust to manage the physical grid, sitting at the precise boundary where IT security’s tools lose visibility and OT security’s tools weren’t designed to look.

Maigadi — the OT/ICS network detection & response (NDR) platform that passively learns your network’s normal and detects the novel, signature-less attacks others miss. On-premise. Explainable. Sovereign by design.

The grid is only as secure as the software that runs it. The question isn’t whether energy management applications have vulnerabilities — every application does. The question is whether your detection stack can see the moment an attacker turns a compromised application into a launching pad for the control network — without waiting for a signature, without scanning a live system, and without asking the operator to spot something their own HMI is hiding from them.