Four network-reachable flaws in EPICS Base, the open-source toolkit behind the control systems of particle accelerators and fusion experiments, have been fixed in version 7.0.11, with the worst rated 9.8 for possible remote code execution. The firm behind the autonomous AI agent that found all four says it took under four hours, and research and industrial operators in the UK should treat that speed as part of the story.
What happened
On 27 October 2026 CISA published industrial control systems advisory ICSA-26-300-01, covering four vulnerabilities that affect every EPICS Base version up to and including 7.0.10. Matching National Vulnerability Database entries appeared later the same day. The fix is EPICS Base 7.0.11, and the code changes were made in the epics-base and pvDataCPP repositories on GitHub.
The four identifiers are CVE-2026-114595, CVE-2026-114596, CVE-2026-114597 and CVE-2026-114598. The critical one, CVE-2026-114595, scores 9.8 under CVSS v3.1 and 9.3 under CVSS v4. All four can be triggered over the network with no credentials and no user interaction. No exploitation has been reported, though NVD’s SSVC data marks the critical flaw as automatable.
Shubham Raj of Causal Security reported the flaws. He told The Register that his company’s autonomous agent, Cipher, found and validated all four in three hours and 49 minutes, and that the first stage of the investigation needed no human input. A person stepped in only to authorise deeper exploitability testing.
The technical picture
EPICS, the Experimental Physics and Industrial Control System, started at Los Alamos and Argonne national laboratories. It is used to build distributed supervisory control and data acquisition systems that sit between operators and physical equipment, carrying measurements, set-points and commands. The Register puts its footprint at roughly 90 large research, academic and industrial installations, among them Argonne’s Advanced Photon Source and the control system for ITER’s fusion reactor.
All four bugs are in how EPICS Base parses messages that arrive over the network:
- CVE-2026-114595 (CVSS 9.8): an integer overflow in request processing means memory is allocated at the wrong size. When the attacker’s data is then handled, the result can be heap corruption, a crash or possibly remote code execution.
- CVE-2026-114596 (CVSS 8.2): length fields in protocol messages are not validated properly. That can overflow an integer and cause an out-of-bounds write, which makes the controller process unstable or brings it down.
- CVE-2026-114597 (CVSS 7.5): weak checks on element or length values let the software read past the end of a buffer. That can crash the process and expose nearby memory.
- CVE-2026-114598 (CVSS 7.5): the official CVE record classes it as type confusion (CWE-843), though its text description repeats the previous flaw’s wording about out-of-bounds reads from poorly validated length values. Either way, the risk is denial of service and possible memory disclosure.
The attacker needs to reach the EPICS services on the control network. Raj points out that this does not require knowing how an accelerator or reactor works. Ordinary memory-corruption skills are enough to crash or take over the software, though doing something targeted to the physical process would need more domain knowledge. Mid-experiment, even one crash can cost beam time and data.
Why it matters for UK organisations
EPICS is not a niche American product. It is a shared community toolkit used across the international research world, and the UK is part of that community. The team designing the Diamond synchrotron chose EPICS for its control system, according to the project’s published outline design paper. The design covers the accelerators, beamlines and conventional plant. Other UK labs, university physics departments and the engineering firms that support them often build on the same base, either directly or inside systems delivered by integrators.
That last point matters. Some organisations run EPICS without knowing it, because it arrived inside a beamline, a vacuum system or a cryogenics package from a supplier. CISO Brief, summarising the advisory, specifically mentions EPICS present through a third-party integrator. In my view that is a real blind spot, and research networks are built for collaboration first: visiting scientists and partner remote access widen who can reach a control network.
There is also the wider signal. Industrial and scientific protocols have long been protected in practice by obscurity: few attackers bothered to learn them. An agent that can pick up an unfamiliar codebase and produce four validated memory-safety bugs in an afternoon removes that barrier. UK operators of essential services under the NIS Regulations, and anyone preparing for the Cyber Security and Resilience Bill, should assume that the time between disclosure and a working exploit for OT software is getting shorter.
Expert view
When we test OT and laboratory environments, the controllers themselves are rarely the first thing to fall. The route in is usually a dual-homed engineering workstation, a forgotten jump host or a flat VLAN shared by a beamline and the office network. These EPICS flaws do not change that pattern. What they change is what happens once an attacker reaches the control network: one crafted, unauthenticated message can now crash or potentially take over a controller.
In my experience research facilities patch control software cautiously, and for good reason. An upgrade during a run cycle can cost weeks of science. That makes compensating controls the realistic first step for many sites, with the 7.0.11 upgrade planned into the next maintenance shutdown rather than rushed. It also means the inventory has to be honest. If you cannot say which input/output controllers run which EPICS Base version, you cannot prioritise.
The AI angle deserves a measured reaction. Automated bug-finding helps defenders as much as attackers, and in this case the flaws went through coordinated disclosure with a fix before publication. The lesson is that “nobody will reverse-engineer our protocol” is no longer a defensible assumption.
What to do now
- Inventory. Find every EPICS Base instance, including those embedded in supplier systems, and record its version. Treat 7.0.10 and earlier as vulnerable. Ask integrators directly in writing.
- Restrict reachability. Make sure EPICS services cannot be reached from the internet, the corporate network or guest and visitor networks. This maps to the Cyber Essentials firewalls control, and the same principle applies inside the OT boundary.
- Review remote access. Route any external access to EPICS-connected networks through a maintained VPN or jump host with multi-factor authentication, never directly. Remove dormant accounts for partners and past collaborators (Cyber Essentials user access control).
- Plan the upgrade. Schedule EPICS Base 7.0.11 for the earliest safe maintenance window, test it on a non-production instance first, and rebuild any applications linked against the old libraries (Cyber Essentials security update management).
- Watch for crashes. Unexplained restarts of controller processes, or malformed traffic on the control network, should be investigated as potential exploitation attempts, not dismissed as instability.
- Get help if needed. The EPICS Controls community offers deployment-specific support, and suspected malicious activity should be reported to the NCSC.
Bottom line
These are serious but manageable flaws: there is a fix, no reported exploitation and a clear precondition in network access. UK labs and industrial users that already segment their control networks properly have time to upgrade in an orderly way. Those that do not should treat this advisory as the prompt to fix the network first and the software second.
Sources
- The Register: AI ‘hacker’ finds 4 severe bugs in popular industrial control software in under 4 hours
- CISA: ICS advisory ICSA-26-300-01, EPICS Base
- NVD: CVE-2026-114595 (and CVE-2026-114596, CVE-2026-114597, CVE-2026-114598)
- CISO Brief: EPICS Base vulnerabilities expose critical manufacturing infrastructure to remote code execution
- arXiv: DIAMOND control system outline design (Heron et al.)
