Back to Intelligence

CVE-2026-34197: Unauthenticated Code Execution in Hitachi Energy SOI (Apache ActiveMQ) — Detection and Remediation Guide

SA
Security Arsenal Team
October 6, 2026
12 min read

CISA has published ICS advisory ICSA-26-279-04 covering CVE-2026-34197, an unauthenticated code execution vulnerability in the Apache ActiveMQ messaging component bundled with Hitachi Energy SOI versions 2.0.0 through 2.2.0. The flaw carries a CVSS v3 base score of 8.8 and is classified as CWE-94 (Improper Control of Generation of Code — Code Injection). Hitachi Energy confirms the weakness can be abused to compromise confidentiality, integrity, and availability of the product — which, in plain terms for an OT environment, means full remote takeover of a system sitting in the Energy sector's critical infrastructure, deployed worldwide.

Two things should get every defender's attention immediately. First, the vulnerability requires no authentication — any attacker with network reachability to the broker can attempt exploitation. Second, ActiveMQ has a long and ugly history of rapid weaponization: broker-side code execution flaws have historically been folded into botnet and ransomware tooling within days of disclosure, because message brokers are internet-adjacent middleware that defenders frequently forget to inventory. In an energy-sector context, where SOI supports operational workflows, the blast radius extends beyond IT into grid operations. Treat this as a patch-and-segment emergency, not a routine advisory.

Technical Analysis

Affected Products and Versions

AttributeDetail
VendorHitachi Energy
ProductSOI
Affected versionsSOI >= 2.0.0 and <= 2.2.0
Vulnerable componentApache ActiveMQ (bundled)
CVECVE-2026-34197
CVSS v38.8 (High) — described by the vendor as a critical code execution flaw
CWECWE-94: Improper Control of Generation of Code (Code Injection)
SectorEnergy
DeploymentWorldwide

How the Vulnerability Works

The defect lives in the Apache ActiveMQ message broker that ships as a component of SOI, not in SOI's own application code. ActiveMQ brokers accept connections over several transport connectors — most commonly OpenWire on TCP/61616, with the web administration console (and Jolokia JMX-over-HTTP interface) typically on TCP/8161, plus optional AMQP (5672), STOMP (61613), and MQTT (1883) listeners.

A code injection flaw (CWE-94) in this context means an attacker can supply crafted input to the broker that causes it to dynamically generate and execute attacker-controlled code in the security context of the broker service. Because no credentials are required, the exploitation prerequisites reduce to one thing: network reachability to an exposed ActiveMQ listener. The attack chain defenders should model is:

  1. Reconnaissance — scanning for open 61616/8161 (and sibling ActiveMQ ports) on SOI hosts.
  2. Delivery — a malicious request/message to the broker endpoint triggering the code injection.
  3. Execution — the broker's JVM process spawns a child process or loads attacker-supplied code, running with the service account's privileges.
  4. Post-exploitation — payload staging, credential access, and lateral movement from the SOI host into adjacent OT/IT segments.

The most reliable post-exploitation observable is consistent across broker RCEs: the Java process hosting ActiveMQ spawns an operating-system shell or interpreter (cmd.exe, powershell.exe, /bin/sh, /bin/bash, Python, etc.). A message broker JVM has essentially no legitimate reason to do this, which gives defenders a high-fidelity detection anchor.

Exploitation Status

As of the advisory's publication, there is no confirmed in-the-wild exploitation publicly attributed to CVE-2026-34197, and no public proof-of-concept has been referenced in the CSAF document. Do not read that as breathing room. Unauthenticated RCE in a widely embedded component is exactly the class of vulnerability that moves from advisory to mass scanning in hours, and the historical pattern with ActiveMQ broker flaws is aggressive, automated exploitation. Assume scanning is already underway and prioritize accordingly.

Detection & Response

The detection strategy below is built around two high-signal observables: abnormal child processes of the ActiveMQ JVM (post-exploitation) and unexpected network reachability to ActiveMQ listener ports (pre- and during-exploitation). Both are low-noise in a properly baselined environment — a broker JVM spawning shells is not normal in any environment I've ever operated in.

Sigma Rules

YAML
---
title: Apache ActiveMQ Broker JVM Spawning Shell - Windows
id: 4e8b1c2a-7f3d-4a91-b6e5-9c2d8f4a1b07
status: experimental
description: Detects the Java process hosting Apache ActiveMQ spawning command shells or script interpreters, a strong post-exploitation indicator for unauthenticated code execution flaws such as CVE-2026-34197 in Hitachi Energy SOI.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-279-04
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\java.exe'
      - '\javaw.exe'
    ParentCommandLine|contains:
      - 'activemq'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\curl.exe'
      - '\wget.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Custom broker administrative scripts legitimately invoked via the JVM (rare; baseline and exclude by full command line)
level: critical
---
title: Apache ActiveMQ Broker JVM Spawning Shell - Linux
id: 8c2f6d19-3b47-4e58-a1c2-6d9e5b7f3a04
status: experimental
description: Detects the ActiveMQ Java broker process spawning shells, interpreters, or download utilities on Linux SOI hosts, consistent with exploitation of unauthenticated code execution vulnerabilities such as CVE-2026-34197.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-279-04
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/10/06
tags:
  - attack.execution
  - attack.t1059
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|endswith: '/java'
    ParentCommandLine|contains: 'activemq'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/zsh'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/base64'
  condition: selection_parent and selection_child
falsepositives:
  - Vendor maintenance scripts executed by the broker service account (baseline and exclude by full command line)
level: critical
---
title: Network Connection to ActiveMQ Listener Ports from Unexpected Host
id: 2b7e4f81-9d36-4c12-a8e9-5f1c3a6b8d02
status: experimental
description: Identifies inbound network connections to Apache ActiveMQ listener ports (OpenWire 61616, web console/Jolokia 8161, AMQP 5672, STOMP 61613, MQTT 1883) on SOI hosts. After baselining authorized broker clients and management systems, residual hits indicate potential reconnaissance or exploitation attempts against CVE-2026-34197.
references:
  - https://www.cisa.gov/news-events/ics-advisories/icsa-26-279-04
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/10/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: network_connection
  product: windows
detection:
  selection:
    DestinationPort:
      - 61616
      - 8161
      - 5672
      - 61613
      - 1883
    Initiated: 'false'
  condition: selection
falsepositives:
  - Legitimate JMS clients, SOI application components, and broker administration from authorized management hosts (baseline known-good source IPs and exclude)
level: medium

The first two rules are the ones to ship to production immediately at critical — they have a near-zero legitimate firing rate. The third rule is a hunting control, not a fire alarm: it is only useful after you baseline authorized sources. Deploy it, collect 72 hours of data, exclude known clients, and then alert on the remainder. That remainder is where the scanners live.

KQL — Microsoft Sentinel / Defender

KQL — Microsoft Sentinel / Defender
// Hunt 1: Post-exploitation - ActiveMQ broker JVM spawning shells/interpreters (CVE-2026-34197)
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("java.exe", "java", "javaw.exe")
| where InitiatingProcessCommandLine has "activemq"
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "mshta.exe", "rundll32.exe", "certutil.exe", "curl.exe", "wget.exe", "sh", "bash", "python", "python3", "perl", "nc", "ncat")
| project Timestamp, DeviceName, AccountName, InitiatingProcessCommandLine, FileName, ProcessCommandLine, SHA256, ReportId
| order by Timestamp desc;

// Hunt 2: New/uncommon external sources talking to ActiveMQ listener ports on SOI hosts
// Requires your SOI host list - populate the dynamic array accordingly
let SoiHosts = dynamic(["SOI-SERVER-01", "SOI-SERVER-02"]);
let Lookback = 30d;
let Recent = 1d;
let KnownClients = DeviceNetworkEvents
| where Timestamp > ago(Lookback) and Timestamp < ago(Recent)
| where DeviceName in~ (SoiHosts)
| where LocalPort in (61616, 8161, 5672, 61613, 1883)
| summarize by RemoteIP;
DeviceNetworkEvents
| where Timestamp > ago(Recent)
| where DeviceName in~ (SoiHosts)
| where LocalPort in (61616, 8161, 5672, 61613, 1883)
| where RemoteIP !in (KnownClients)
| where not(ipv4_is_private(RemoteIP)) // flag external reachability first; remove line to include internal outliers
| summarize FirstSeen = min(Timestamp), Connections = count(), Ports = make_set(LocalPort), Actions = make_set(ActionType) by DeviceName, RemoteIP
| order by FirstSeen desc;

// Hunt 3: Syslog/CEF-ingested firewall or sensor data showing inbound attempts to ActiveMQ ports (for network devices forwarding to Sentinel)
CommonSecurityLog
| where DestinationPort in (61616, 8161, 5672, 61613, 1883)
| where DeviceAction !in ("Allow", "allow") == false or DeviceAction in ("Allow", "allow")
| summarize Attempts = count(), UniqueSources = dcount(SourceIP), Actions = make_set(DeviceAction) by DestinationIP, DestinationPort, bin(TimeGenerated, 1h)
| where Attempts > 20 or UniqueSources > 10
| order by Attempts desc;

Velociraptor VQL

VQL — Velociraptor
-- Hunt: Identify ActiveMQ broker processes, their listening ports, and any child processes
-- Relevant to CVE-2026-34197 post-exploitation triage on Hitachi Energy SOI hosts

LET brokers = SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ 'activemq'

SELECT brokers.Pid AS BrokerPid,
       brokers.Username AS BrokerUser,
       brokers.CommandLine AS BrokerCmdline,
       child.Name AS ChildName,
       child.CommandLine AS ChildCmdline,
       child.CreateTime AS ChildStartTime
FROM pslist() AS child
JOIN brokers ON child.Ppid = brokers.Pid

// Also enumerate listening sockets for ActiveMQ transport connectors
SELECT Pid, Name, Address, Port, Status
FROM netstat()
WHERE Port IN (61616, 8161, 5672, 61613, 1883)
  AND Status =~ 'LISTEN'

Run this across your SOI fleet. Any child process rows returned are an immediate escalation to IR — capture the broker's JVM command line, the child process binary and hash, and preserve the ActiveMQ data/ directory and logs before remediation wipes evidence.

Remediation / Hardening Script

The following Bash script inventories the ActiveMQ instance on a Linux SOI host, confirms exposure, and applies host-level firewall restrictions so only an authorized management/JMS subnet can reach the broker ports. It is an interim compensating control — it does not replace the vendor patch. Adjust ALLOWED_SUBNET to your authorized client range.

Bash / Shell
#!/bin/bash
# CVE-2026-34197 interim hardening - restrict Apache ActiveMQ listener exposure on Hitachi Energy SOI hosts
# Test in a staging environment before production OT deployment. Coordinate with operations before blocking ports.
set -euo pipefail

ALLOWED_SUBNET="10.10.50.0/24"   # Authorized JMS clients / management subnet - CHANGE THIS
ACTIVEMQ_PORTS="61616 8161 5672 61613 1883"

echo "=== [1] Identify running ActiveMQ broker processes ==="
ps -eo pid,user,args | grep -i '[a]ctivemq' || echo "No ActiveMQ process found - verify SOI installation state."

echo ""
echo "=== [2] Identify ActiveMQ version from installation jars ==="
BROKER_PID=$(pgrep -f 'activemq' | head -n1 || true)
if [ -n "${BROKER_PID}" ]; then
  BROKER_CWD=$(readlink -f "/proc/${BROKER_PID}/cwd" || echo "unknown")
  echo "Broker PID: ${BROKER_PID} | CWD: ${BROKER_CWD}"
  find / -name 'activemq-broker-*.jar' 2>/dev/null | head -n 5
else
  echo "Broker not running; search filesystem for ActiveMQ jars to confirm component presence."
fi

echo ""
echo "=== [3] Current listening sockets on ActiveMQ ports ==="
ss -tlnp 2>/dev/null | grep -E ':(61616|8161|5672|61613|1883)\b' || echo "No ActiveMQ listeners detected."

echo ""
echo "=== [4] Apply host firewall restrictions (allow only ${ALLOWED_SUBNET}) ==="
for PORT in ${ACTIVEMQ_PORTS}; do
  iptables -C INPUT -p tcp --dport "${PORT}" -s "${ALLOWED_SUBNET}" -j ACCEPT 2>/dev/null \
    || iptables -I INPUT -p tcp --dport "${PORT}" -s "${ALLOWED_SUBNET}" -j ACCEPT
  iptables -C INPUT -p tcp --dport "${PORT}" -j DROP 2>/dev/null \
    || iptables -A INPUT -p tcp --dport "${PORT}" -j DROP
  echo "Restricted tcp/${PORT} to ${ALLOWED_SUBNET}"
done

echo ""
echo "=== [5] Verify rules ==="
iptables -L INPUT -n --line-numbers | grep -E '61616|8161|5672|61613|1883' || echo "Verification failed - review iptables state manually."

echo ""
echo "=== NEXT STEPS ==="
echo "1. Persist firewall rules per your distro (iptables-save / netfilter-persistent / firewalld)."
echo "2. Apply the Hitachi Energy fixed release per CSAF advisory ICSA-26-279-04 - firewall rules are compensating controls only."
echo "3. Review ActiveMQ logs (data/activemq.log, data/audit.log if enabled) for suspicious connections predating this restriction."

Remediation

Work these in priority order. Items 1–2 are the actual fix; items 3–6 are defense-in-depth that remains valuable even after patching.

  1. Inventory immediately. Identify every Hitachi Energy SOI installation in your environment and flag any instance running version 2.0.0 through 2.2.0. Do not forget DR sites, test/training environments, and vendor-managed jump hosts — bundled middleware like ActiveMQ is precisely the component asset inventories miss.

  2. Apply the vendor fix. Follow the Recommended Immediate Actions in Hitachi Energy's CSAF advisory referenced by CISA ICSA-26-279-04 (https://www.cisa.gov/news-events/ics-advisories/icsa-26-279-04) and upgrade SOI to the fixed release specified by the vendor. Because the flaw is unauthenticated code execution, this is not a candidate for deferral through the normal OT patch cycle — escalate for an emergency change window.

  3. Segment the broker now. Until patched (and permanently, as hygiene), restrict TCP 61616 and 8161 — plus 5672, 61613, and 1883 if those connectors are enabled — to the minimum set of authorized JMS clients and management systems. SOI hosts should never be reachable from the internet on these ports; verify with an external scan, not an assumption.

  4. Reduce the ActiveMQ attack surface. Disable any transport connectors SOI does not require, enforce strong non-default credentials on the web console and broker, and confirm the broker service runs with least privilege. A broker running as root/SYSTEM converts this CVE directly into full host compromise.

  5. Hunt for pre-patch exposure. Before and after patching, run the detection content above against historical telemetry covering at least the period since the advisory date. Look specifically for broker JVM child processes, unexpected sources on broker ports, and file drops in the ActiveMQ installation and data/ directories.

  6. Apply CISA's standing ICS guidance. Per CISA's recommended practices: minimize network exposure for all control system devices, place OT behind firewalls isolated from business networks, and use secure remote access ( hardened VPN / jump host ) where remote connectivity is unavoidable. See CISA's ICS cybersecurity best practices at https://www.cisa.gov/resources-tools/resources/ics-cybersecurity-best-practices.

If you operate in the Energy sector and cannot confirm your SOI fleet's patch posture within the next 24 hours, that gap itself is your incident to manage. An unauthenticated code injection flaw in internet-scannable middleware does not wait for your next maintenance window.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub

Is your security operations ready?

Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.