The short version.
On October 8, 2026, CISA published ICSA-26-281-02 for Grid Protection Alliance openPDC, the openPDC Docker image and openHistorian. It covers six CVEs. The two worst score CVSS v3.1 9.8: unsafe deserialization in the service console, which can give an attacker with no login remote code execution, and a hard-coded admin credential in the Docker image.
The fix is openPDC 2.9.482 and openHistorian 2.8.585. Two things make patching incomplete. An upgraded install keeps its old network bindings, so two unauthenticated data publishers stay open until someone changes them. And the Docker image gets no fix: the vendor says it does not recommend the image for production at all.
A phasor data concentrator and its historian sit where the OT network meets the analysts and applications that use the data. Upgrade, rebind, then control who can reach the server. CISA reports no known exploitation.
What openPDC and openHistorian do.
openPDC is a phasor data concentrator. Per its GitHub project, it receives synchrophasor data from phasor measurement units (PMUs), aligns it by GPS time tag, and speaks protocols including IEEE C37.118 and IEC 61850-90-5. openHistorian is a back-office system that archives process data, such as SCADA and synchrophasor measurements, at sub-second resolution. Both are open source, from the Grid Protection Alliance, and openPDC ships with openHistorian built in.
In practice, a utility uses them to collect fast grid measurements from substations and keep them for operators, engineers and analysis tools. That puts the server on both sides: PMUs feed it from the OT side, and people and applications read from it on the business side.
What the advisory says.
- Products: openPDC before 2.9.477 and 2.9.482, the openPDC Docker image before the same versions, and openHistorian before 2.8.580 and 2.8.585. The two thresholds apply to different CVEs.
- Impact, per CISA: administrative control of the system, arbitrary code execution, access to sensitive operational data, or mapping of the internal network.
- Sector: Energy, deployed worldwide. Vendor headquartered in the United States.
- Reported by: Shubham Raj (Cipher) of Causal Security.
- Known exploitation: none reported to CISA.
| CVE | CWE | CVSS v3.1 | What it allows, per the advisory | Fixed in |
|---|---|---|---|---|
| CVE-2026-100730 | Deserialization of untrusted data (CWE-502) | 9.8 | Service console deserializes client data: remote code execution as the service account. No login needed unless Windows Authentication is on | openPDC 2.9.482, openHistorian 2.8.585 |
| CVE-2026-105278 | Hard-coded credentials (CWE-798) | 9.8 | Docker image ships a fixed admin credential with no forced change: full admin control | No fix. Docker image only |
| CVE-2026-104629 | Unsafe reflection (CWE-470) | 8.8 | Component loader runs any specified type: code execution for an authenticated user who can place a file on the host | openPDC 2.9.477, openHistorian 2.8.580 |
| CVE-2026-105281 | Missing authentication (CWE-306) | 7.5 | Internal data publisher accepts unauthenticated connections and returns the full device and measurement topology | New default binds to loopback. Upgrades must change it by hand |
| CVE-2026-85479 | Missing authentication (CWE-306) | 5.3 | STTP data publisher accepts unauthenticated connections and exchanges data | Same as above |
| CVE-2026-101022 | Server-side request forgery (CWE-918) | 4.3 | Modbus feature connects to any address an authenticated user gives it, which can map the internal network | No code fix. Firewall it, block loopback and RFC 1918 ranges unless needed |
The CVE descriptions for the two publishers and the SSRF name openPDC. CISA's product list also includes openHistorian for those three, so check both. For the Docker image, every applicable row reads the same: the fix has not been published to the Docker image.
How an attack would work.
The advisory describes flaws, not an observed attack. Read together, they give three paths.
No login at all. On an install without Windows Authentication, CVE-2026-100730 lets anyone who reaches the service console send a crafted object and run code as the service account. On the Docker image, CVE-2026-105278 lets them log in as admin with a credential that is the same everywhere.
Reconnaissance for free. The internal publisher, CVE-2026-105281, hands out the complete device and measurement topology: which PMUs exist and what they measure. That is a map of the grid instrumentation, given to anyone who connects.
Moving inward. With a low-privilege account, the Modbus SSRF turns the server into a probe for the internal network. The reflection flaw turns a file on disk into code execution.
Two MITRE ATT&CK for ICS techniques describe the core of it. Exploitation of Remote Services (T0866) covers the service console deserialization. Insecure Credentials: Hardcoded Credentials (T1694.002) covers the Docker admin credential. Both depend on one condition: network reach to the server.
Why the historian is the hard part.
A PDC or historian is not a field device. It runs on a server, and it exists to share data. Analysts want trends, engineering tools want event data, and other applications subscribe to streams. Every one of those consumers is a path to the service console and the publishers.
Patching has two traps here. The first is the binding change that only applies to new installs. A team that upgrades and closes the ticket still has both publishers listening on every interface. The second is Docker. A lab or pilot that went into production on the published image has no patch to apply and a shared admin credential. The vendor's answer is to stop running it in production, which means a migration, not an update.
Until both are done, reachability is the control you have.
What to do before every server is fixed.
Start with the vendor's and CISA's steps. Upgrade to openPDC 2.9.482 or openHistorian 2.8.585. Check the binding of the internal and STTP publishers and set them to loopback unless a remote subscriber needs them. Firewall the Modbus feature and block loopback and RFC 1918 destinations unless they are required. CISA adds the usual baseline: keep the server off the internet, behind firewalls, and isolated from business networks.
Then limit who reaches the server. Write down who needs the service console, who needs the data publishers, and who only needs trends. Very few people need the console. Allow each group only the service it needs, from the machines it uses.
Tie access to a person. Shared accounts and IP-based trust make a historian easy to reach and hard to audit. Every analyst and engineer should sign in as themselves before reaching it.
How Access Gate helps, and its limits.
Access Gate is an appliance installed at the site. It connects beside the existing network, and you then steer traffic for the servers you want protected through it, one at a time. Nothing is installed on the PDC or historian server. It is installed in a day per site.
Once traffic flows through the gate, the server sits in an enclave:
- Named sign-in. Analysts open an access screen, accept the policy and sign in with your identity provider. Access expires after a preset timeout and every login is logged.
- Per-machine rules. Access control lists are default deny. You allow a named user, a directory group or a specific system to reach the server on a specific protocol. The service console and the publishers stop answering everyone else.
- Recorded admin sessions. Engineers who administer the server go through privileged access management: browser-based RDP, SSH or HTTPS sessions tied to a named person, time-limited and recorded.
- TLS. The gate can require TLS on flows to the server, including web interfaces that lack it.
For utilities under NERC CIP, if the server belongs to a BES Cyber System, this is the kind of electronic access control and logging that CIP-005 and CIP-007 ask for. Our NERC CIP compliance guide covers the evidence by standard. See also OT identity and power grid security.
The limits are real. Access Gate does not fix the code. A user you allow still reaches a vulnerable console, and a host already on the server's own segment, behind the gate, is outside its control. It does not replace the upgrade, the binding change, or the move off the Docker image. It narrows who can reach the server until those are done, and it records who did.
What to do this week.
- List every openPDC and openHistorian install, its version, and whether it runs on the Docker image.
- Upgrade to openPDC 2.9.482 or openHistorian 2.8.585.
- Check the publisher bindings after the upgrade, and set them to loopback unless a remote subscriber needs them.
- Plan the move off the Docker image for anything in production, and change the admin credential now.
- Turn on Windows Authentication where it is not already used, so the console needs a login.
- Firewall the Modbus feature and block loopback and private ranges unless required.
- Write down who reaches the server, and cut it to the people and systems that need it.
Want to see where a gate would sit at your site? Build your network in a few minutes. Every other advisory we have covered is in the ICS security advisories archive.
Sources: CISA ICS Advisory ICSA-26-281-02 (October 8, 2026) and its CSAF record; the Grid Protection Alliance openPDC and openHistorian project pages; the CISA Known Exploited Vulnerabilities catalog, checked October 9, 2026; and MITRE ATT&CK for ICS. Confirm fixed versions and configuration steps against the Grid Protection Alliance release notes before changing a production server.