VMware vCenter Syslog Server Directory Traversal RCE — CVE-2026-59310

CVE-2026-59310 is a critical (CVSSv3.1 9.8) directory-traversal vulnerability in VMware vCenter's Syslog Server, disclosed by Broadcom on 2026-07-29 (VMSA-2026-0006) alongside a paired authentication-bypass flaw (CVE-2026-59309, also 9.8). The attacker's objective is straightforward and severe: the vCenter syslog collector is designed to accept inbound data from managed ESXi hosts and network devices with no authentication, so any network-adjacent attacker can write outside the intended log directory and achieve arbitrary code execution on the appliance that controls every VM, host, and snapshot in the environment. No vendor workaround exists — patching is the only fix.

Five days after public disclosure, German incident-response firm QUIRSO observed active exploitation beginning 2026-08-03, reaching 95% of an eventual 361 victim IPs across 47 countries within 48 hours. Post-exploitation, the actor installs a cron job on the appliance's Photon OS to relaunch reverse_ssh, an open-source Go-based reverse-SSH tool, for durable outbound C2. Attribution is unconfirmed — press coverage raises circumstantial, not confirmed, stylistic overlap with UNC5174's history of weaponizing VMware flaws.

The highest-value defensive angle here is behavioral, not IOC-driven: no source in this pack's research turned up a single published hash, C2 domain, or C2 IP. Every detection in this pack hunts the attack chain itself — anomalous syslog-service child processes, cron-persistence writes, and outbound SSH connect-back from an appliance that should never initiate that traffic — rather than waiting on a blocklist feed that does not yet exist.

Seven sources fetched and saved verbatim to VMware-vCenter-CVE-2026-59310-Hunt-sources/ for IOC-provenance tracing. All five press write-ups independently cite the same underlying QUIRSO GmbH incident-response research (published ~2026-08-10); QUIRSO's original post was not directly reachable within the research scope, so campaign-timeline facts are corroborated across 5 independent secondary sources rather than traced to the primary. No content in any fetched source attempted to direct this agent's behavior — all extracted text was pure threat-intel prose.

Confidence note: vulnerability facts (CVSS, affected/fixed versions, no-workaround) are High confidence — two independent T1 sources agree. Campaign facts (victim counts, timeline, reverse_ssh behavior) are Medium confidence — five T2 sources agree closely but all trace to one uningested T3 primary (QUIRSO).

Hypothesis set — each numbered hypothesis below maps directly to a CQL query in Section 8:

1. If CVE-2026-59310 is being exploited, the vCenter syslog service (or its process tree) spawns an unexpected shell/interpreter/reverse_ssh child process.
2. If post-exploitation persistence is installed, a new or modified cron entry appears on the appliance outside a documented VMware maintenance window.
3. If reverse_ssh is deployed, a binary named reverse_ssh (or executed from a non-standard path like /tmp) runs on the appliance.
4. If reverse_ssh is maintaining C2, the appliance initiates outbound port-22 connections to non-RFC1918 destinations — traffic it should never originate.
5. A single agent showing ≥2 of the above signal types within a short window is a high-confidence compromise chain.

No atomic IOCs (hashes, C2 domains, C2 IPs) were published in any of the 7 saved sources as of 2026-08-13. Rows below are explicitly labelled behavioral or placeholder — no indicator has been fabricated to fill this table. See Section 10 for the import-ready grouped grid.

Affected products/versions: VMware vCenter Server (all versions prior to fixed releases). VMSA-2026-0006 as a whole also touches ESX, Workstation 25H2, Fusion 25H2, Cloud Foundation, vSphere Foundation, Telco Cloud Platform/Infrastructure via other CVEs in the same bulletin — CVE-2026-59310 itself is vCenter Syslog Server-specific.

Patch status: Available — 9.1.0.0300 / 9.0.2.0100 / 8.0 U3k / 8.0 U2f. Workarounds: None (Broadcom, verbatim: "There are no workarounds for CVE-2026-59309 or CVE-2026-59310").

Telemetry gap — read before deploying Section 8: the CQL queries in this pack assume Falcon sensor telemetry (ProcessRollup2/NetworkConnectIP4) on the host generating the events. VMware vCenter is a vendor-locked Photon OS appliance; installing a third-party EDR sensor directly on it is atypical and may be unsupported by Broadcom. Where sensor deployment on the appliance itself is not possible, use Section 7's native/audit-log hunts instead, or forward vCenter's syslog/audit output to Falcon LogScale as a custom log source and adapt field names to that ingest's schema before relying on Section 8 as-is.

Given the Section 5 telemetry gap, these native checks are frequently the only viable option on a vCenter appliance without a deployed EDR sensor. Run via direct appliance shell access (VAMI/Bash shell, enabled temporarily and disabled after) or via vCenter's native remote-syslog-forwarding feature into your SIEM/LogScale.

• Cron audit: crontab -l -u root and ls -la /etc/cron.d/ /var/spool/cron/ — flag any entry referencing a binary outside standard VMware appliance paths, especially anything in /tmp, /var/tmp, or a home directory.
• Process spot-check: ps aux | grep -i ssh and diff against a known-good appliance baseline; look specifically for a process named reverse_ssh or an unlabeled statically-linked Go binary.
• Outbound connection check: netstat -tnp | grep :22 or ss -tnp | grep :22 — the appliance should not be the initiator of outbound SSH sessions.
• vpxd / syslog.log review: review the vCenter support bundle's vpxd.log and the syslog server's own logs for anomalous entries around traversal-style path patterns (repeated ../ sequences or writes outside the configured log directory) beginning 2026-08-03 forward.
• Remote syslog forwarding: vCenter natively supports forwarding to an external syslog target (VAMI > Syslog Configuration) — route this to your SIEM/LogScale if it isn't already, so these checks become queryable centrally rather than requiring appliance shell access each time.
• VAMI update-log review: confirm no unauthorized changes were made through the VAMI update mechanism outside your documented patch windows.

Both IOAs below require a Falcon sensor on the vCenter appliance itself — see the Section 5 telemetry-gap callout. Where sensor deployment isn't possible, treat these as aspirational and rely on Section 7's native audit hunts instead.

IOA-1 · vCenter Syslog Service Unexpected Child Process

FP tuning: VMware's own log-rotation/helper scripts under the syslog service may legitimately spawn shell utilities; baseline your specific appliance version's normal process tree first. Validation: in an isolated lab appliance (patched, non-production), manually spawn a benign shell as a child of the syslog service process, confirm the rule fires, then revert.

IOA-2 · Cron Persistence Write on vCenter Appliance

FP tuning: exclude VAMI-driven patch/update processes; correlate against documented maintenance windows. Validation: in an isolated lab appliance, add and remove a benign crontab entry to confirm the rule fires.

No atomic IOCs were published for this campaign as of 2026-08-13 (see Section 4). The grid below is deliberately behavioral-first, with the Falcon CSV block carrying labelled placeholders rather than fabricated indicators.

type,value,action,severity,expiration,description,tags
sha256,REPLACE_WITH_CONFIRMED_HASH,detect,high,2027-08-13,vCenter Syslog RCE payload - CVE-2026-59310,campaign:vCenterSyslogRCE
domain,REPLACE_WITH_CONFIRMED_C2_DOMAIN,detect,high,2026-11-13,reverse_ssh C2 - CVE-2026-59310,campaign:vCenterSyslogRCE
ipv4,REPLACE_WITH_CONFIRMED_C2_IP,detect,medium,2026-09-13,reverse_ssh C2 - CVE-2026-59310,campaign:vCenterSyslogRCE

FileName regex (exact binary name): ^reverse_?ssh$
Cron path indicators: /etc/cron.d/, /var/spool/cron/, "crontab -"
Syslog-parented child process: ParentBaseFileName=/syslog/i + FileName in [sh,bash,dash,python*,perl,reverse_ssh]
Outbound egress: RemotePort=22 initiated FROM the vCenter appliance to a non-RFC1918 destination
Path-of-execution anomaly: ImageFileName under /tmp/ or /var/tmp/ on the appliance

Tool: reverse_ssh
Type: open-source, Go-based reverse-SSH connect-back framework
Capabilities (per press reporting): connect-back operation, port forwarding,
file transfer, multiple transports, remote-shell management
Specific fork/build used in this campaign: NOT confirmed by any fetched source
Do not treat "reverse_ssh" as a unique atomic indicator - it is a public tool
name, not a campaign-specific artifact. Use the behavioral signatures above.

Fixed releases (VMSA-2026-0006 / .1):
  vCenter 9.1.x -> 9.1.0.0300
  vCenter 9.0.x -> 9.0.2.0100
  vCenter 8.0   -> 8.0 U3k or 8.0 U2f

Verify on the appliance:
  vpxd -v
  (or vSphere Client -> Help -> About)

No workaround exists. Patch is the only remediation.

Primary Mitigations: M1051 (Update Software), M1030 (Network Segmentation), M1037 (Filter Network Traffic), M1022 (Restrict File and Directory Permissions)

What to verify after deployment

• Confirm patched version via vpxd -v or the vSphere Client "About" panel — should report 9.1.0.0300 / 9.0.2.0100 / 8.0 U3k / 8.0 U2f or later.
• Confirm cron audit is clean: crontab -l -u root and ls -la /etc/cron.d/ /var/spool/cron/ should show only recognized, documented entries.
• Confirm egress filtering is effective: in a maintenance window, attempt an outbound connection to a test IP on port 22 and verify it is blocked.
• Spot-check with CQL: re-run Q2 (cron) and Q4 (outbound SSH) against the deployment-date window — a clean result plus continued monitoring is the expected steady state.

Playbook 1 — Cron Audit (run on each vCenter appliance)

What it does: lists all root-owned cron entries and cron.d/spool contents for manual review. Why it works: direct implementation of M1022 and the Section 12 immediate-tier audit recommendation.

#!/bin/sh
# Run as root on the vCenter appliance shell (VAMI/Bash access).
echo "=== crontab -l (root) ==="
crontab -l -u root 2>/dev/null
echo "=== /etc/cron.d/ ==="
ls -la /etc/cron.d/ 2>/dev/null
for f in /etc/cron.d/*; do
  [ -f "$f" ] && echo "--- $f ---" && cat "$f"
done
echo "=== /var/spool/cron/ ==="
ls -la /var/spool/cron/ 2>/dev/null
echo "=== flag entries referencing /tmp or /var/tmp ==="
grep -rE '/(tmp|var/tmp)/' /etc/cron.d/ /var/spool/cron/ 2>/dev/null

Verify: output should contain only entries you recognize from documented VMware maintenance/patch activity. Escalate any unrecognized entry immediately.

Playbook 2 — Egress Filter for Outbound SSH (appliance-local, iptables)

What it does: blocks the appliance from initiating new outbound TCP/22 connections while leaving inbound (managed-host) syslog traffic untouched. Why it works: directly removes the reverse_ssh connect-back channel described in Section 3, Stage 4 (M1037).

# Review with your VMware support agreement before applying local iptables
# changes on a vendor-supported appliance -- prefer an upstream network ACL
# where policy allows it. Local rule shown for environments where it doesn't.
iptables -A OUTPUT -p tcp --dport 22 -m state --state NEW -j REJECT
# Verify:
iptables -L OUTPUT -n | grep ':22'

Verify: from the appliance, attempt ssh test-target to a benign external host in a maintenance window — connection should be refused.

Playbook 3 — Patch Version Verification (fleet-wide)

# Against each vCenter appliance's shell or via govc/PowerCLI at scale:
vpxd -v
# Expect: 9.1.0.0300+ / 9.0.2.0100+ / 8.0 U3k+ / 8.0 U2f+
# Anything earlier is unpatched and exploitable -- prioritize immediately.

Deploying via your RMM: the scripts above are raw shell. To wrap them for fleet deployment (admin check, error handling, custom-field writeback for compliance tracking), hand them to your RMM deployment tooling and ask for a deployable package.

Coverage summary: 4 of 5 identified techniques have at least partial behavioral detection coverage. 1 gap remains.

Priority gap: T1036 — sources only assert generic "firewall evasion" capability of reverse_ssh; no specific evasion technique (protocol mimicry, port choice, TLS wrapping) is documented, so no targeted query can be built without speculation. Monitor for updated QUIRSO/vendor detail and revise this pack when available.

Validation gates: see Section 11 in full — in short, telemetry availability on the vCenter appliance itself is the single biggest open question for this pack and must be confirmed in your tenant before relying on Section 8's queries operationally.