CISA published advisory ICSA-26-300-01 on October 27, 2026, listing four vulnerabilities in EPICS Base, open-source control-system software, and crediting them to Shubham Raj of Cipher and Causal Security. Cipher is an AI agent. According to The Register, it investigated unfamiliar software and validated four exploits in 3 hours and 49 minutes. The CVEs and the fix are confirmed by CISA. The timing and the degree of autonomy are the vendor's account. If you run EPICS, update to 7.0.11.
| Question | Short answer |
|---|---|
| Am I affected? | Only if you run EPICS Base 7.0.10 or earlier |
| Is there a fix? | Yes: EPICS Base 7.0.11 |
| Is it exploited? | CISA reports no known public exploitation |
| Is the "under four hours, mostly autonomous" claim verified? | Not independently; it is Causal Security's account via The Register |
| Does data leave my machine? | Not relevant to the bugs; they are network-reachable memory flaws in a control-system service |
What does CISA confirm?
The CISA advisory states the following, and we take these as verified:
| CVE | Weakness | CVSS v3.1 | What it can do |
|---|---|---|---|
| CVE-2026-114595 | CWE-190, integer overflow | 9.8 (Critical) | Overflow in network request processing leads to wrong allocation, memory corruption, denial of service or potential remote code execution |
| CVE-2026-114596 | CWE-190, integer overflow | 8.2 (High) | Improper message length validation causes an out-of-bounds write and process instability |
| CVE-2026-114597 | CWE-130, length parameter inconsistency | 7.5 (High) | Reads beyond a buffer: denial of service, possible exposure of adjacent memory |
| CVE-2026-114598 | CWE-843, type confusion | 7.5 (High) | Reads beyond a buffer: denial of service, possible exposure of adjacent memory |
Affected: EPICS Base release 7.0.10 and earlier. Fixed: 7.0.11, with the changes in epics-base pull requests 934 and 937 and pvDataCPP pull request 109. CISA credits Shubham Raj of Cipher and Causal Security with reporting the flaws and says it knows of no public exploitation. Its general advice is to minimise network exposure, keep control networks behind firewalls and separate from business networks, and use VPNs with updated software for remote access.
The two lower-scored entries share a description in the advisory, so read the individual CVE records (NVD record for CVE-2026-114595 and the others) if you need to triage by exact condition.
What is only claimed?
Claims that rest on Causal Security and The Register, not on CISA:
| Claim | Source | Status |
|---|---|---|
| Cipher found and validated four exploits in 3 hours 49 minutes | Causal Security via The Register | Vendor claim; not independently confirmed |
| The initial investigation ran without human intervention | Causal Security via The Register | Vendor claim |
| A human gave one instruction to pursue deeper exploitability testing in a secure environment | Causal Security via The Register | Vendor claim; this is the only human step described |
| Cipher "can reason across the technology stack" | Co-founder Shubham Raj, quoted by The Register | Marketing description |
| Cipher earlier found attack paths in North American and European power-grid systems | The Register; CISA ICSA-26-281-02 credits the same researcher | Advisory confirmed; the agent's role is the vendor's account |
We did not run Cipher, review its logs or reproduce the exploits, and we have not seen a technical write-up with transcripts. The honest reading is that a real researcher found real, CISA-confirmed bugs using an agent-led workflow, and that the stopwatch figure is plausible but unverified. It also does not say how much prior knowledge of the code, which models, or how many failed attempts sit behind four successes.
How does this relate to the earlier grid advisory?
On October 8, 2026, CISA published ICSA-26-281-02 for Grid Protection Alliance's openPDC and openHistorian, also crediting Shubham Raj of Cipher at Causal Security. That advisory lists six CVEs, among them a CVSS 9.8 deserialization flaw (CVE-2026-100730) and a CVSS 9.8 hard-coded credential in the Docker image (CVE-2026-105278). It notes that no fix is planned for the Docker image issues, and that the loopback-only default applies only to new installs, so upgraded systems may still listen on all interfaces.
Two advisories in three weeks from the same researcher is a pattern worth noting, not proof of anything about the agent. It does show that the output of this workflow is being accepted into the normal coordinated-disclosure pipeline.
Why do the bugs look the way they do?
The EPICS weaknesses are classic memory-safety defects in a network protocol parser: integer overflows, length fields that disagree with the data, and a type confusion. Parsers written in C and C++ for protocols that were designed for trusted lab networks are a long-standing source of such bugs. They are also the kind of bug a tireless tool does well on, because the work is repetitive and has a clear signal: a crash, an out-of-bounds access or a sanitiser report is feedback an agent can loop on.
We would not generalise further. A bug class with a crisp automatic oracle says little about whether agents find logic flaws, authorisation gaps or business-logic bugs at the same speed. Our write-up of AI-found bugs and AI-led attacks in October tracks those claims month by month, and the Wiz anatomy of an AI-driven cloud attack shows what attacker-side agents look like when they run end to end.
What would it take to verify the speed claim?
A reader cannot check "3 hours 49 minutes" from CISA's page, so here is what would turn the claim into evidence. None of this has been published as far as we found:
- A run log. Timestamps for the first prompt, the first crash, and each validated exploit, so the total can be recomputed.
- Scope of the human input. The Register describes one human instruction after the initial investigation. A transcript would show whether that instruction was a nudge or the key insight.
- Prior knowledge. EPICS Base is open source with public history, and earlier EPICS vulnerabilities are documented. Whether the agent had that context, and whether similar bugs were already known in sibling code, changes how impressive four findings are.
- Cost and attempts. Tokens or compute spent, and how many candidate leads were discarded.
- Independent reproduction. The EPICS maintainers fixed the code in the pull requests CISA lists, which is meaningful: maintainers accepted the reports as real. That supports the bugs, not the stopwatch.
Timeline
- October 8, 2026: CISA publishes ICSA-26-281-02 on openPDC and openHistorian, crediting Shubham Raj of Cipher at Causal Security.
- October 27, 2026: CISA publishes ICSA-26-300-01 for EPICS Base 7.0.10 and earlier, fixed in 7.0.11. The Register publishes the same day with Causal Security's account of the 3 hour 49 minute run.
How should defenders read agent-found disclosures?
Disclosures credited to agents will keep arriving, and the useful response is boring. Read the advisory for affected versions and the fix, not the press framing. Check whether the bug needs network reachability, authentication or a particular configuration. Decide on exposure first and severity second: a 9.8 on a service no attacker can reach is a lower priority than a 7.5 on one that faces the internet.
It is also worth remembering that the same capability is available on the other side. A defender who can point an agent at their own parsers and dependencies before release gets the same speed advantage, and running such an agent safely, with logged tool calls and no standing access to production secrets, is the same discipline as running any coding agent.
What this means if you run AI coding agents
Most readers of this blog do not operate EPICS. The practical lessons are different.
- Patch windows are compressing. If working exploits can be produced in hours, the gap between a bug existing and someone holding an exploit matters less than how quickly you can ship a fix once it is public. Know how you would update each long-lived dependency, especially ones you exposed on a network.
- Network exposure is the control you still own. Every EPICS bug here needs reachability to the vulnerable service. CISA's advice, segmentation and VPN-only access, is the same advice that applies to any internal service a coding agent can reach.
- Offensive agents are agents too. If you or your team run an agentic pentest tool, it holds shell access, network access and often credentials. It deserves the same watching as a coding agent. See how an agent-run campaign looked from the defender side in Unit 42's Bugster write-up and the Symantec LLMjacking report.
- Treat speed claims as claims. A single vendor-supplied time figure is a data point, not a benchmark. Ask for the scope, the target's prior documentation, and how many runs it took.
If you run EPICS
- Identify every EPICS Base instance and its version; 7.0.10 and earlier are affected.
- Update to 7.0.11 from the epics-base repositories, and test first, because CISA also advises an impact analysis before changing control systems.
- Confirm which EPICS services are reachable from outside the control network, and close what does not need to be reachable.
- Watch for crashes or restarts of EPICS processes: three of the four bugs primarily cause out-of-bounds access, and a repeated crash is the most visible symptom.
What Beam can and cannot do here
Beam does not scan EPICS, industrial networks or network services. Its hooks cover what Claude Code and Codex do on a developer machine, its scan reads skills and MCP configs, and beam cve check [DIR] matches lockfiles against the AgentBeam CVE database (exit 0 clean, 2 found, 1 error); EPICS is a C/C++ control-system toolkit and is not something that command is aimed at. Where Beam is relevant is the agent side: if your team runs an offensive or research agent on a workstation, local hook-based monitoring can flag credential reads and destructive commands. That deny is hook-based, not a kernel sandbox. See the Beam landing page for what it watches.
Frequently asked questions
Which EPICS Base versions are affected and what is the fix?
CISA lists EPICS Base 7.0.10 and earlier as affected. The fix is EPICS Base 7.0.11, available through the epics-base GitHub repositories. CISA also points to epics-base pull requests 934 and 937 and pvDataCPP pull request 109.
What are the four CVEs?
CVE-2026-114595 (integer overflow, CVSS v3.1 9.8, possible remote code execution), CVE-2026-114596 (improper message length validation, 8.2), CVE-2026-114597 (length parameter inconsistency, 7.5) and CVE-2026-114598 (type confusion, 7.5), per CISA advisory ICSA-26-300-01.
Is the 3 hours 49 minutes figure confirmed?
Not independently. It comes from Causal Security as reported by The Register. CISA confirms the vulnerabilities and credits the researcher, but its advisory does not describe how long discovery took or how autonomous the agent was.
Are these bugs being exploited?
CISA reports no known public exploitation at this time. Exploitation needs network access to the vulnerable EPICS services, which is a risk where control networks are poorly segmented.
Does this affect people who run AI coding agents?
Not directly, unless you operate EPICS. The consequence is indirect: agents can shorten the time from target to working exploit, so patch windows and network exposure matter more.
Can Beam help with this?
Beam does not scan EPICS or industrial networks. Its hooks watch what coding agents on your machine do, and its beam cve check command reads lockfiles. It is relevant only if you run offensive agents yourself and want their actions logged.
Related reading
- AI-led attacks in October 2026
- Wiz: anatomy of an AI-driven cloud attack
- Unit 42 on Bugster and Hermes Agent
- Symantec on LLMjacking
- Sources: CISA ICSA-26-300-01, CISA ICSA-26-281-02, The Register
Advisory details are accurate as of October 27, 2026. The speed and autonomy claims are unverified and may change if Causal Security publishes a technical write-up; we will update this post if it does.