CVE-2026-59310: VMware vCenter Syslog Server RCE Actively Exploited for Reverse SSH Persistence — Detection and Remediation Guide

A critical remote code execution vulnerability in the VMware vCenter Syslog Server — tracked as CVE-2026-59310 — has moved from patched to weaponized. According to reporting on the active campaign, threat actors are exploiting the flaw against internet-reachable or network-accessible vCenter appliances and using that initial foothold to deploy a reverse SSH tool, giving them persistent, outbound-initiated remote access that blends into legitimate encrypted traffic and sidesteps many perimeter controls.

If you operate vCenter — and most enterprise virtualization environments do — this is a drop-everything event. vCenter is the crown jewel of your virtual infrastructure: it holds credentials for ESXi hosts, controls VM lifecycle operations, and is frequently granted broad reach into management networks. A compromised vCenter appliance is effectively a compromised data center. The fact that attackers are immediately converting exploitation into persistent reverse SSH access tells us this campaign is operationally mature, not opportunistic scanning.

This post breaks down the vulnerability, what the exploitation chain looks like from a defender's perspective, and — most importantly — how to hunt for compromise and remediate right now.

Technical Analysis

Affected Component

• Product: VMware vCenter Server (vCenter Server Appliance, VCSA — the Photon OS-based Linux appliance)
• Vulnerable component: The vCenter Syslog Server service, which receives and processes syslog messages forwarded from ESXi hosts and other infrastructure components
• CVE: CVE-2026-59310
• Severity: Critical (remote code execution; treat as CVSS 9.x-class until you have vendor confirmation of the exact score in your environment's advisory)

The Syslog Server component is a tempting target because of its exposure model: by design it listens for inbound log traffic from across the infrastructure, which means it is often reachable from broad segments of the network — and in misconfigured environments, from the internet. A pre-authentication code execution flaw in a log ingestion service is about as bad as it gets: no credentials needed, high-trust network position, and a service that many teams never thought to firewall aggressively.

Attack Chain (Defender's View)

Based on the observed campaign, the intrusion flow looks like this:

1. Initial access: The attacker sends a crafted payload to the vCenter Syslog Server listener, triggering the RCE and gaining code execution in the context of the syslog service on the VCSA.
2. Tool deployment: The attacker drops and executes a reverse SSH utility on the appliance.
3. Persistence and C2: The reverse SSH client initiates an outbound connection to attacker-controlled infrastructure and exposes a shell or tunnel back through that connection. Because the session is outbound and encrypted, it typically sails through egress filtering and looks like ordinary SSH traffic.

The tradecraft choice here matters. Reverse SSH on a Linux appliance gives the actor:

• Firewall traversal — outbound connections are rarely blocked from management networks
• Encrypted command channel — no payload visibility for network IDS
• Resilience — the implant can auto-reconnect, surviving reboots if paired with a systemd unit, cron entry, or rc script

Exploitation Status

This is not theoretical. The vulnerability is being exploited in an active, confirmed campaign in the wild. Patch status alone does not clear you — if your appliance was reachable and unpatched during the exposure window, you must assume possible compromise and hunt before you consider the incident closed. Patching closes the door; it does not evict anyone already inside.

Detection & Response

The highest-fidelity detection surface for this threat is the VCSA itself: unexpected processes spawned by the syslog service, unauthorized SSH client processes initiating outbound connections, new persistence artifacts (systemd units, cron jobs), and outbound SSH to untrusted destinations. The detections below are built for exactly those observables.

Sigma Rules

---
title: Reverse SSH Client Execution on Linux Appliance
description: Detects execution of SSH clients with reverse-tunnel flags or common reverse SSH tool indicators on Linux systems, consistent with the post-exploitation tooling deployed via CVE-2026-59310 against VMware vCenter appliances.
references:
  - https://www.bleepingcomputer.com/news/security/critical-vmware-vcenter-rce-flaw-exploited-for-reverse-ssh-access/
  - https://attack.mitre.org/techniques/T1572/
  - https://attack.mitre.org/techniques/T1021/004/
logsource:
  category: process_creation
  product: linux
  service: auditd
detection:
  selection_reverse_flags:
    CommandLine|contains:
      - 'ssh -R'
      - 'ssh -N -R'
      - 'ssh -fN -R'
      - ' -R *: '
  selection_tools:
    Image|endswith:
      - '/rssh'
      - '/chisel'
      - '/sish'
      - '/revssh'
    CommandLine|contains:
      - 'chisel client'
      - 'sish '
  condition: 1 of selection_*
falsepositives:
  - Legitimate administrative SSH tunneling by infrastructure engineers
  - Vendor support tunnels explicitly authorized by VMware support
level: high
---
title: Suspicious Child Process of vCenter Syslog Service
description: Detects shell or scripting interpreters spawned as child processes of the rsyslog/syslog service on a vCenter appliance, indicative of post-exploitation command execution following exploitation of CVE-2026-59310.
references:
  - https://www.bleepingcomputer.com/news/security/critical-vmware-vcenter-rce-flaw-exploited-for-reverse-ssh-access/
  - https://attack.mitre.org/techniques/T1059/
logsource:
  category: process_creation
  product: linux
  service: auditd
detection:
  selection_parent:
    ParentImage|endswith:
      - '/rsyslogd'
      - '/syslogd'
  selection_child:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
      - '/ssh'
  condition: all of selection_*
falsepositives:
  - Extremely rare; rsyslog spawning interactive shells is not normal appliance behavior
level: critical
---
title: Persistence via Systemd Unit or Cron on vCenter Appliance
description: Detects creation of systemd service units or cron entries referencing SSH tunneling or unknown binaries on Linux appliances, a persistence mechanism consistent with reverse SSH implants deployed in the CVE-2026-59310 campaign.
references:
  - https://www.bleepingcomputer.com/news/security/critical-vmware-vcenter-rce-flaw-exploited-for-reverse-ssh-access/
  - https://attack.mitre.org/techniques/T1543/002/
  - https://attack.mitre.org/techniques/T1053/003/
logsource:
  category: file_event
  product: linux
  service: auditd
detection:
  selection_systemd:
    TargetFilename|startswith:
      - '/etc/systemd/system/'
      - '/usr/lib/systemd/system/'
      - '/run/systemd/system/'
    TargetFilename|endswith: '.service'
  selection_cron:
    TargetFilename|startswith:
      - '/etc/cron.d/'
      - '/var/spool/cron/'
  condition: 1 of selection_*
falsepositives:
  - VMware update cycles creating legitimate service units (correlate with patch windows)
  - Configuration management tooling (Ansible, Puppet) writing units
level: medium

KQL — Microsoft Sentinel / Defender

This query hunts across Syslog and CEF-ingested Linux telemetry for the core behaviors of this campaign: reverse SSH flags, syslog spawning shells, and outbound SSH from vCenter appliances to non-approved destinations. Tune the appliance hostname pattern and the approved destination list to your environment.

let VCSAHosts = dynamic(["vcenter", "vcsa"]);
let ApprovedSshDests = dynamic(["10.0.0.0/8", "192.168.0.0/16"]);
union isfuzzy=true
    (Syslog
    | where Computer has_any (VCSAHosts)
    | where ProcessName in~ ("ssh", "sshd", "bash", "sh", "python", "python3", "curl", "wget", "nc", "ncat")
       or SyslogMessage has_any ("ssh -R", "ssh -N -R", "chisel", "sish", "reverse")
    | where SyslogMessage has_any (" -R ", "chisel client", "Accepted password", "session opened")
    | project TimeGenerated, Computer, ProcessName, SyslogMessage, HostIP),
    (CommonSecurityLog
    | where DeviceVendor =~ "VMware" or SourceHostName has_any (VCSAHosts)
    | where DestinationPort == 22
    | where DeviceAction =~ "allowed"
    | where not(ipv4_is_private(DestinationIP))  // outbound SSH to public IP from vCenter is anomalous
    | project TimeGenerated, SourceHostName, SourceIP, DestinationIP, DestinationPort, Message)
| order by TimeGenerated desc

A second, tighter hunt for post-exploitation process ancestry, if you are collecting auditd-style process creation telemetry from the appliance:

Syslog
| where Facility =~ "user" or SyslogMessage has "execve"
| where SyslogMessage has_any ("rsyslogd", "syslog") and SyslogMessage has_any ("/bin/bash", "/bin/sh", "curl", "wget", "ssh -R", "nc ", "python")
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), SampleCommands = make_set(SyslogMessage, 10) by Computer, ProcessName
| order by LastSeen desc

Velociraptor VQL

Use this artifact in a hunt across your Linux infrastructure (or run it interactively against a suspect VCSA via your collection pipeline) to surface running reverse-SSH clients and persistence references to tunneling tools.

-- Hunt for reverse SSH processes and tunneling tools on Linux endpoints
LET processes = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(ssh .*-R |chisel|sish|revssh|-N -R)'
   OR Exe =~ '(rssh|chisel|sish|revssh)'

LET persistence = SELECT FullPath, Data, Mtime
FROM glob(globs=['/etc/systemd/system/*.service', '/etc/cron.d/*', '/var/spool/cron/crontabs/*'],
          accessor='file')
WHERE Data =~ '(ssh .*-R |chisel|sish|revssh|autossh)'

SELECT * FROM processes
UNION ALL
SELECT NULL AS Pid, NULL AS Ppid, 'persistence_artifact' AS Name,
       Data AS CommandLine, FullPath AS Exe, NULL AS Username, Mtime AS CreateTime
FROM persistence

Pair this with a netstat review to catch live outbound SSH sessions to unexpected destinations:

-- Identify outbound SSH connections from the appliance to non-internal destinations
SELECT Pid, Name, Family, Status,
       Laddr.IP AS LocalIP, Laddr.Port AS LocalPort,
       Raddr.IP AS RemoteIP, Raddr.Port AS RemotePort
FROM netstat()
WHERE Raddr.Port = 22
  AND Status =~ 'ESTAB'
  AND NOT (Raddr.IP =~ '^(10\\.|192\\.168\\.|172\\.(1[6-9]|2[0-9]|3[01])\\.)')

Verification and Hardening Script (Bash)

Run the following on each VCSA (via the appliance shell) to audit for the indicators described in this campaign. This is a read-only audit script — it changes nothing, so it is safe to run broadly.

#!/bin/bash
# CVE-2026-59310 vCenter compromise audit — run on VCSA appliance shell
echo "=== [1] Running reverse SSH / tunnel processes ==="
ps auxww | grep -Ei 'ssh .*-R |autossh|chisel|sish|revssh' | grep -v grep

echo "=== [2] Outbound established SSH connections ==="
netstat -tnp 2>/dev/null | grep ':22 ' | grep ESTABLISHED

echo "=== [3] Recently modified/created systemd units (last 14 days) ==="
find /etc/systemd/system/ /usr/lib/systemd/system/ -name '*.service' -mtime -14 -ls 2>/dev/null

echo "=== [4] Cron entries referencing ssh/tunnel tools ==="
grep -rEi 'ssh .*-R |autossh|chisel|sish' /etc/cron* /var/spool/cron/ 2>/dev/null

echo "=== [5] Syslog service children anomalies (current) ==="
RSYSLOG_PID=$(pgrep -x rsyslogd | head -1)
if [ -n "$RSYSLOG_PID" ]; then
  ps --ppid "$RSYSLOG_PID" -o pid,ppid,user,cmd
fi

echo "=== [6] Recently added local users / SSH authorized_keys changes ==="
find /root/.ssh /home/*/.ssh -name 'authorized_keys*' -mtime -14 -ls 2>/dev/null
awk -F: '($3 >= 1000) {print $1" uid="$3}' /etc/passwd

echo "=== [7] vCenter build/version (verify against patched release) ==="
/usr/sbin/vpxd -v 2>/dev/null || cat /etc/vmware-vpx/vpxd.version 2>/dev/null

echo "=== [8] Listening services (confirm syslog port exposure) ==="
netstat -tlnp 2>/dev/null | grep -E ':514|:6514'

Any hit in sections 1–4 or 6 on an appliance that was unpatched during the exposure window should be treated as a confirmed incident: isolate the appliance, preserve forensic images, and begin IR — do not simply kill the process and move on.

Remediation

1. Patch immediately. Apply the VMware security update that addresses CVE-2026-59310 to all vCenter Server appliances. Pull the fixed build number directly from the official VMware/Broadcom security advisory at https://www.vmware.com/security/advisories.html (Broadcom support portal) and verify each appliance is on the patched build — do not rely on "auto-update scheduled" assumptions.

2. Assume breach and hunt first. If the appliance was reachable while unpatched, run the audit script above and the VQL/KQL hunts before patching if forensically feasible (patching can destroy volatile evidence). At minimum, capture process lists, network connections, and filesystem timestamps before rebooting into the update.

3. Restrict Syslog Server exposure. The syslog listener should only be reachable from ESXi hosts and authorized log forwarders. Implement firewall rules (appliance-level via the VAMI firewall or upstream) that permit TCP/UDP 514 (or TLS 6514) only from your documented host management subnets. Nothing about this service should ever be internet-reachable.

4. Constrain vCenter egress. vCenter appliances have very few legitimate reasons to initiate outbound SSH. Block egress TCP/22 from vCenter at the perimeter except to explicitly approved destinations (e.g., VMware update infrastructure over its required ports). This single control would have severed this campaign's persistence channel.

5. Rotate credentials. If compromise is confirmed or suspected: rotate the vCenter SSO administrator credentials, all local appliance accounts, ESXi host root passwords, and any service accounts stored in or accessible through vCenter. Treat any credential the appliance could reach as burned.

6. Audit the management plane. Review vCenter events, ESXi host logs, and VM operations for the exposure window: new VMs, snapshot deletions, VM power-offs (pre-ransomware staging), new local accounts on ESXi hosts, and changes to host firewall rules.

7. Add detections permanently. Deploy the Sigma, KQL, and VQL content above into your standing detection stack. Reverse SSH from infrastructure appliances is a high-value, low-noise analytic — it deserves a permanent home in your SOC, not a one-time hunt.

8. Monitor for KEV inclusion. Given confirmed in-the-wild exploitation of a critical RCE in ubiquitous infrastructure software, watch CISA's Known Exploited Vulnerabilities catalog — if added, federal deadlines will apply and the urgency bar rises further.

The pattern here — a critical RCE in management-plane infrastructure converted immediately into stealthy, egress-friendly persistence — is the defining intrusion shape of 2026. Your hypervisor management layer deserves the same detection rigor you give your endpoints. If you cannot answer "what processes are running on my vCenter appliance right now," that is the gap to close this week.

Related Resources

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