CVE-2026-114595 · EPICS Base Channel Access RSRV pre-auth integer overflow in network…

01 · The Real Story

Someone left the control room door unlocked, and the door leads straight to the particle beam

CVE-2026-114595 is an integer overflow in the Channel Access RSRV server component of EPICS Base, the open-source toolkit that runs distributed control systems at particle accelerators, fusion reactors, research facilities, and some critical manufacturing environments. An attacker who can reach the Channel Access service (default TCP port 5064) can send a crafted network message whose interrelated msgsize, dtype, and count header fields trigger an integer overflow during memory allocation. The resulting undersized heap buffer is then filled with attacker-controlled data, producing a classic heap-based buffer overflow. All versions of EPICS Base through 7.0.10 are affected. The fix shipped in 7.0.11, with the core patch in GitHub PR #934 and a companion pvDataCPP deserialization hardening in PR #109.

The vendor CVSS of 9.8 CRITICAL is technically accurate for the bug *in isolation* — it is unauthenticated, network-reachable, low-complexity, and leads to RCE. However, the 9.8 does not account for the real-world deployment posture: EPICS systems are designed exclusively for isolated OT networks, Channel Access was never intended for hostile environments (maintainers have publicly acknowledged it is 'completely insecure' by design on untrusted networks), and the installed base is small and specialized. That said, EPICS is *canonically* an ICS/SCADA controller — 100% of its installs control physical infrastructure — so the blast radius when the chain lands is safety-class. We agree this is CRITICAL for any organization that runs EPICS, but we adjust the score to 9.0 to reflect the expected network segmentation that should be in place at every compliant facility.

"Pre-auth RCE in ICS/SCADA controller software — if you run EPICS, this is an emergency patch."

02 · The Attack Path

5 steps from start to impact.

STEP 01

Gain network access to the OT/control segment

The attacker must reach the subnet where EPICS IOCs run. In a properly segmented facility, this requires either physical access to the control network, compromise of a jump host or engineering workstation on the OT VLAN, or exploitation of a VPN/firewall misconfiguration. In rare cases of misconfiguration, Channel Access port 5064 may be directly reachable from a corporate network or — worst case — the internet.

Conditions required:

Network path to TCP port 5064 on the target IOC host

Where this breaks in practice:

CISA ICS guidance and EPICS documentation both mandate network isolation from business and internet networks
Most national labs and research facilities enforce VLAN segmentation for control systems
No Shodan/Censys evidence of widespread internet exposure of Channel Access services

Detection/coverage: Network IDS monitoring for Channel Access traffic crossing segmentation boundaries; firewall deny-log alerts on port 5064/5065 from non-OT source addresses

STEP 02

Identify EPICS IOCs on the network

Channel Access uses UDP broadcast beacons on port 5065 by default. An attacker on the OT subnet can passively listen for beacon packets to enumerate all running IOCs and their IP addresses without sending a single packet. Active scanning of TCP 5064 also works. No authentication is required at any point — Channel Access has no credential exchange.

Conditions required:

Presence on the OT subnet from step 1

Where this breaks in practice:

Beacon traffic is confined to the broadcast domain; proper micro-segmentation limits visibility

Detection/coverage: Anomalous ARP or beacon listener activity on OT VLANs; NIDS signature for CA search requests from unexpected source IPs

STEP 03

Send crafted CA message with overflowing size fields

The attacker constructs a Channel Access protocol message where the msgsize, dtype, and count fields are set to values that, when multiplied or added during the server's allocation-size calculation, produce an integer overflow. The RSRV server allocates a heap buffer that is far smaller than the actual payload data. No tooling is publicly available yet, but the protocol is well-documented in the CA Reference Manual and crafting a malicious message requires only basic socket programming.

Conditions required:

TCP connection to port 5064 on the target IOC
Knowledge of CA wire protocol (publicly documented)

Where this breaks in practice:

No public PoC or exploit code exists as of 2026-10-28
The protocol is niche; exploit development requires reading EPICS-specific documentation

Detection/coverage: Deep packet inspection for CA messages with anomalous size/count field combinations; the fix in PR #934 also logs and disconnects on overflow detection

STEP 04

Trigger heap corruption and achieve code execution

The undersized buffer receives the full attacker-controlled payload via caNetConvert() and the subsequent write path, overwriting adjacent heap metadata and objects. Depending on the heap layout and the IOC's runtime (typically a Linux or RTEMS process), the attacker can redirect execution to shellcode or a ROP chain. The IOC process typically runs as a dedicated service account but often has direct hardware I/O access to the controlled equipment.

Conditions required:

Successful delivery of the oversized payload from step 3
Target IOC running EPICS Base <= 7.0.10

Where this breaks in practice:

Modern Linux deployments may have ASLR and stack canaries, though many IOC hosts run minimal/embedded OS configurations with weaker hardening
RTEMS and VxWorks targets (common for hardware IOCs) have limited or no ASLR

Detection/coverage: Host-based crash monitoring; unexpected IOC process restarts; memory corruption signatures if an EDR agent is present (unlikely on OT hosts)

STEP 05

Control physical equipment via compromised IOC

With code execution on the IOC host, the attacker has direct access to the process variables that control physical equipment — magnets, vacuum systems, RF cavities, radiation shutters, coolant pumps, or manufacturing actuators. The attacker can read sensor data, modify setpoints, disable interlocks, or brick the IOC. In safety-critical facilities, this could cause equipment damage, radiation exposure, or operational shutdown.

Conditions required:

Code execution on the IOC from step 4
IOC has I/O connections to controlled equipment (this is its purpose)

Where this breaks in practice:

Safety-critical facilities typically have independent hardware interlock systems that cannot be overridden by software
Physics interlocks and machine protection systems provide a separate safety layer

Detection/coverage: Out-of-range setpoint alarms on the machine protection system; unexpected process variable changes in the archiver; control room operator observation

03 · Compensating Control

CRITICAL 9.0→HIGH 7.0

SEVERITY REDUCED

Verify and enforce network segmentation for all EPICS IOC subnets — Ensure all Channel Access traffic (TCP 5064, UDP 5065) is confined to dedicated OT VLANs with explicit firewall deny rules blocking access from corporate, guest, and internet zones. This is the single most effective control because it eliminates the attacker's ability to reach the vulnerable service. Per the noisgate mitigation SLA for CRITICAL findings, verify segmentation within 3 days. Audit firewall rules and run port scans from corporate VLANs to confirm 5064/5065 are unreachable.

CRITICAL 9.0→IGNORE 0.0

SEVERITY REDUCED

Apply EPICS Base 7.0.11 patch — Upgrade all IOC hosts to EPICS Base 7.0.11, which includes the RSRV message validation fixes from PR #934 and the pvDataCPP deserialization hardening from PR #109. For pre-2017 installations, also cherry-pick commit e430d09. Per the noisgate remediation SLA for CRITICAL findings, complete patching within 90 days. Schedule IOC maintenance windows to minimize beamtime or production impact. Test on a staging IOC first — the patch changes protocol parsing behavior and could affect edge-case client interactions.

CRITICAL 9.0→HIGH 6.5

SEVERITY REDUCED

Deploy host-based firewall rules on IOC hosts restricting port 5064 to known OPI and gateway IPs — Even within the OT VLAN, apply iptables/nftables rules on each IOC host to accept CA connections only from enumerated operator interface stations and CA gateway servers. This limits lateral movement within the OT segment. Deploy within 3 days alongside the segmentation verification.

CRITICAL 9.0→HIGH 7.5

SEVERITY REDUCED

Deploy a Channel Access Gateway as a protocol-level choke point — The EPICS CA Gateway can proxy and filter Channel Access requests between network segments. Configure it to restrict which process variables are writable and from which source addresses. While it does not inspect for integer overflow payloads, it reduces the exposed attack surface by centralizing access. This is a medium-term control to deploy within 30 days.

CRITICAL 9.0→CRITICAL 9.0

Enable IOC process crash monitoring and automatic restart alerting — Configure systemd watchdog or equivalent process supervision for all IOC services. Alert on unexpected restarts, which may indicate exploitation attempts (failed heap corruption often causes a crash before achieving code execution). This does not prevent exploitation but ensures rapid detection. Deploy within 3 days.

What doesn't work

Web Application Firewall (WAF) — Channel Access is a custom binary protocol on TCP 5064, not HTTP. No WAF can inspect or filter it.
EDR/AV on IOC hosts — Most EPICS IOCs run on minimal Linux, RTEMS, or VxWorks without EDR agents. Even where Linux EDR exists, it is unlikely to have signatures for CA protocol exploitation.
Channel Access Access Security (AS) — EPICS has a built-in access security mechanism, but it controls read/write permissions on process variables, not network-level message parsing. The integer overflow occurs *before* access security checks are applied, so AS does not mitigate this CVE.
TLS/encryption — Channel Access does not support TLS. The pvAccess protocol has optional TLS, but the Channel Access RSRV path that contains this vulnerability is unencrypted by design.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	None observed. CISA states no known public exploitation as of 2026-10-27. OffSeq Mirage reports no attack traffic. Not listed on CISA KEV.
Proof-of-concept availability	No public PoC exists. No GitHub repos, Exploit-DB entries, Metasploit modules, or Nuclei templates found. The CA wire protocol is publicly documented, which lowers the barrier for a skilled researcher, but no weaponized code has surfaced.
EPSS score	Not yet scored. FIRST EPSS API returns no data for this CVE (disclosed <48 hours ago). Expect an initial score within 1–2 weeks.
CISA KEV status	Not listed. No known exploitation to trigger KEV inclusion.
CVSS vector interpretation	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (9.8) — Network-reachable, no authentication, no user interaction, low complexity. All three impact dimensions maxed. CVSS 4.0 scored at 9.3. The vector accurately describes the technical bug but does not model network segmentation.
Affected versions	EPICS Base ≤ 7.0.10 (all 7.0.x releases and the legacy 3.x series). The vulnerability is in the RSRV Channel Access server (`src/rsrv`). The pvDataCPP deserialization path (pvAccess) is also affected.
Fixed version	EPICS Base 7.0.11 — patches: epics-base PR #934 (CA RSRV validation), pvDataCPP PR #109 (deserialization bounds). Backporting to pre-2017 releases also requires commit `e430d09`.
Discovery	Reported by Shubham Raj of Cipher / Causal Security via AI-assisted vulnerability research. Part of a batch of four CVEs (CVE-2026-114595 through -114598) found in under 4 hours. CISA ICS is the CNA.
Scanning / exposure data	No internet-facing EPICS instances found in public Shodan/Censys/GreyNoise data. Channel Access uses IANA-registered ports 5064/tcp (server) and 5065/udp (beacons). The protocol was designed for trusted LANs and is not expected to be internet-exposed.
Related CVEs	CVE-2026-114596 (CVSS 8.2, integer overflow → OOB write), CVE-2026-114597 (CVSS 7.5, length validation → OOB read), CVE-2026-114598 (CVSS 7.5, type confusion → OOB read). All four share the same advisory ICSA-26-300-01 and the same fix.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.0/10)

Why this verdict

Canonical ICS/SCADA component with safety-class blast radius. EPICS Base is not a general-purpose library that *sometimes* runs in OT — it IS the control system. 100% of its installed base consists of IOCs that directly command physical equipment at particle accelerators, fusion reactors, synchrotrons, telescopes, and critical manufacturing lines. A successful exploit gives the attacker write access to process variables controlling magnets, vacuum, RF, radiation shutters, and coolant systems. The high-value role floor is CRITICAL, and we cannot break it without evidence that <1% of installs occupy this role — which is impossible because controlling equipment is the product's sole purpose.
Unauthenticated, low-complexity chain once on-network. Channel Access has no authentication mechanism whatsoever. The EPICS maintainers have publicly acknowledged the protocol is 'completely insecure' on untrusted networks. Once an attacker has a TCP connection to port 5064, the remaining steps (craft overflow, trigger heap corruption) require only knowledge of a publicly documented wire protocol. The attack complexity is genuinely low.
Network segmentation is the primary (and expected) friction. EPICS systems should be on isolated OT VLANs per CISA ICS guidance and the EPICS project's own documentation. This is the main reason we reduce the score from 9.8 to 9.0 rather than leaving it at the vendor rating. However, network segmentation is a *compensating control*, not an inherent property of the vulnerability — it can be misconfigured, bypassed via compromised jump hosts, or absent in legacy installations.
No PoC, no exploitation, fresh disclosure — but the protocol documentation is a roadmap. The CA Reference Manual fully documents the wire protocol, message headers, and field semantics. A skilled researcher could develop a working exploit without reverse engineering. The absence of public weaponization is a timing factor, not a structural barrier.
Role multiplier: OT/ICS controllers (100% of installed base). On an EPICS IOC controlling a particle accelerator beamline, successful exploitation yields direct control of safety-critical equipment. The blast radius is operational (facility shutdown, multi-million-dollar equipment damage) and potentially safety-related (radiation exposure, vacuum breach). Hardware interlock systems provide an independent safety layer, but interlocks are designed as last-resort protection, not as a substitute for software integrity. The chain succeeds in this role, and this role IS the product.

Why not higher?

The vendor already rates this 9.8, which is the near-maximum. We cannot justify 10.0 because Scope is Unchanged (the IOC process does not inherently escalate to other hosts), and the CVSS 4.0 score of 9.3 also reflects this. The 9.0 we assign is already at the top of CRITICAL, and going higher would require demonstrated wormable or self-propagating behavior, which this vulnerability does not exhibit.

Why not lower?

Network segmentation alone cannot justify dropping below CRITICAL. The segmentation argument proves that the *typical attacker path is indirect* (requires prior OT network access), but it does not reduce the *impact* when the chain completes. EPICS is a canonical ICS/SCADA component — the floor rule mandates CRITICAL when ≥10% of installs occupy the high-value role and the chain yields safety/operational impact. Lowering to HIGH would require evidence that fewer than 1% of EPICS deployments control safety-relevant equipment, which contradicts the product's design purpose. The absence of a PoC is a temporary condition, not a structural mitigant.

06 · Verification

Crowdsourced verification payload.

Run this script on each host where EPICS Base IOC software is installed (typically Linux servers on the OT network). Invoke as bash check_cve_2026_114595.sh or bash check_cve_2026_114595.sh /path/to/epics/base. Requires read access to the EPICS Base source/installation directory. Set EPICS_BASE environment variable if your installation is in a non-standard location.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# noisgate CVE-2026-114595 verification script
# Checks EPICS Base version for integer overflow in CA RSRV
# Usage: bash check_cve_2026_114595.sh [/path/to/epics-base]
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN
set -uo pipefail

VULN_VER="7.0.10"  # Last affected version

version_lte() {
  # Returns 0 if $1 <= $2 using sort -V
  [ "$1" = "$(printf '%s\n%s' "$1" "$2" | sort -V | head -n1)" ]
}

check_version_file() {
  local base_dir="$1"
  local vfile="$base_dir/configure/CONFIG_BASE_VERSION"
  [ -f "$vfile" ] || vfile="$base_dir/CONFIG_BASE_VERSION"
  [ -f "$vfile" ] || return 1
  local maj min pat
  maj=$(grep -E '^EPICS_VERSION[[:space:]]*=' "$vfile" | sed 's/.*=[[:space:]]*//' | tr -d '[:space:]')
  min=$(grep -E '^EPICS_REVISION[[:space:]]*=' "$vfile" | sed 's/.*=[[:space:]]*//' | tr -d '[:space:]')
  pat=$(grep -E '^EPICS_MODIFICATION[[:space:]]*=' "$vfile" | sed 's/.*=[[:space:]]*//' | tr -d '[:space:]')
  [ -n "$maj" ] && [ -n "$min" ] && [ -n "$pat" ] || return 1
  local ver="$maj.$min.$pat"
  echo "[*] EPICS Base version at $base_dir: $ver"
  if version_lte "$ver" "$VULN_VER"; then
    echo "VULNERABLE - EPICS Base $ver <= $VULN_VER (CVE-2026-114595)"
    return 0
  else
    echo "PATCHED - EPICS Base $ver > $VULN_VER"
    return 2  # Signal patched
  fi
}

# Build candidate list
candidates=()
[ -n "${1:-}" ] && candidates+=("$1")
[ -n "${EPICS_BASE:-}" ] && candidates+=("$EPICS_BASE")
for d in /opt/epics/base /usr/local/epics/base /opt/epics-base \
         /usr/local/epics-base /home/*/epics/base /ics/*/base; do
  [ -d "$d" ] && candidates+=("$d")
done

if [ ${#candidates[@]} -eq 0 ]; then
  # Fallback: try softIoc
  if command -v softIoc &>/dev/null; then
    ver_line=$(softIoc -V 2>&1 | head -1 || true)
    if [[ "$ver_line" =~ ([0-9]+\.[0-9]+\.[0-9]+) ]]; then
      ver="${BASH_REMATCH[1]}"
      echo "[*] EPICS Base version via softIoc: $ver"
      if version_lte "$ver" "$VULN_VER"; then
        echo "VULNERABLE - EPICS Base $ver <= $VULN_VER (CVE-2026-114595)"
        exit 0
      else
        echo "PATCHED - EPICS Base $ver > $VULN_VER"
        exit 1
      fi
    fi
  fi
  echo "UNKNOWN - No EPICS Base installation found. Set EPICS_BASE or pass path as argument."
  exit 2
fi

for dir in "${candidates[@]}"; do
  check_version_file "$dir"
  rc=$?
  if [ $rc -eq 0 ]; then
    exit 0  # VULNERABLE
  elif [ $rc -eq 2 ]; then
    exit 1  # PATCHED
  fi
  # rc=1 means file not found, try next candidate
done

echo "UNKNOWN - Could not determine EPICS Base version from: ${candidates[*]}"
exit 2