BeyondTrust Remote Support CVE-2026-102764: China-nexus zero-day, root for six weeks

A privileged remote-support appliance is the one box in the estate that is supposed to hold the keys: it brokers administrator sessions into every other system, and it stores the credentials to do so. On October 15, 2026, BeyondTrust disclosed CVE-2026-102764, a critical flaw in BeyondTrust Remote Support (formerly Bomgar) that a China-nexus espionage group had been exploiting as a zero-day since late August — roughly six weeks of unauthenticated access to exactly that box, before anyone published a CVE number.

Developing story — first published 09:38 CEST (07:38 UTC), October 16, 2026. Updated as the vendor and CISA publish more.

At a glance

CVE	CVE-2026-102764
Product / affected versions	BeyondTrust Remote Support (formerly Bomgar), all supported versions through 26.2.3
Fixed in	BT26-05 patch; SaaS tenants auto-patched the week of 2026-10-08. Self-hosted appliances must apply the BT26-05 patch manually; builds below the current supported release must upgrade first
CVSS	9.3 CRITICAL · CVSS 4.0 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H (vendor-assigned, mirrored by NVD)
Exploited in the wild	Yes — exploited as a zero-day since late August 2026; attributed by Google Threat Intelligence Group / Mandiant to Armory Castle (formerly UNC5221), a suspected PRC-nexus actor
CISA KEV	Not listed (catalog version 2026.10.15)
Public PoC	None public as of 2026-10-16; GTIG published IOCs and YARA rules, not an exploit
Official advisory	BeyondTrust BT26-05 (beyondtrust.com/blog/entry/bt26-05) and KB0024066

What happened

BeyondTrust describes CVE-2026-102764 as an internal-messaging weakness: components inside the appliance "did not adequately validate the origin of the messages" they received, which under the right conditions lets an attacker perform file operations on the appliance (NVD, CWE-290). In practice that means an unauthenticated remote attacker can write files to the box — and on a web appliance, an attacker-controlled file in the web root is a web shell.

Google Threat Intelligence Group and Mandiant published the incident analysis the same day, attributing the activity to Armory Castle, a suspected PRC-nexus group previously tracked as UNC5221 and known for racing to burn edge-device zero-days before patches ship. BeyondTrust patched its SaaS tenants the week of October 8 and disclosed publicly on October 15; self-hosted customers have to act by hand. Shadowserver tracks more than 1,400 internet-exposed Remote Support instances, and the advisory does not say how many are patched.

Who is exposed, and how to check your BeyondTrust Remote Support version

Any self-hosted Remote Support appliance on 26.2.3 or earlier that was reachable from the internet during the exploitation window is in scope. The version string is in the /login administration console footer and in the appliance's own update page. But a version check only tells you whether you can be exploited going forward — it says nothing about whether you already were between late August and the day you patched. For a box that brokers privileged sessions, those are two very different questions, and only one of them is answered by a number.

How Armory Castle turned a file write into six weeks of root on the appliance

The chain GTIG documented is a clean edge-device playbook, and worth reading as a model rather than as one vendor's bad day:

1. Initial access (T1190). POST requests to a staging path, /app_84304470%2Ephp. About eleven minutes later, a PHP web shell appeared under the site service account's web root.
2. Web shell (T1505.003). SAWFLY (mangoapi.php) is an obfuscated PHP web shell using Base32 transport and RC4 encryption. Without the _c94mfe parameter it returns an HTTP 404, so a casual scan sees a dead URL.
3. Privilege escalation (T1548.001). The actor copied /bin/sh to /usr/bin/dbus-authd, set ownership to root and flipped the SUID bit — a root backdoor disguised as a system daemon.
4. Credential access (T1555). Using root, they ran the appliance's own bt-secrets utility against the service-account vault and then the global vault, then deleted bt-secrets.log.
5. Persistence (T1548.003). A startup script, zz-root-persist, appended a NOPASSWD sudoers entry to the appliance's sudoers template and rebuilt the live sudoers file, so the change survives reboot and configuration reset.
6. Lateral movement (T1021, T1098). They logged into /login with compromised administrator credentials, raised Jump Item and Team permissions from "No Access" to "Administrator", ran remote-support sessions into downstream systems and pulled internal documents.
7. Tunneling (T1572). BARECLAW, a custom SOCKS5-over-WebSocket tunneler (ingredi_ws), listened on 127.0.0.1:19800; an injected HAProxy rule routed the path /uidchanarge to it, exposing the localhost listener through the appliance's own front-end.

"Any appliance that was reachable from the internet on a vulnerable version during the exploitation window should be treated as potentially compromised until it has been reviewed." — Mandiant

The quiet part of that chain is step 4 onward. The attacker deleted the appliance's own logs across system, web, PHP and auth locations. Mandiant is blunt about the consequence: customers cannot audit the appliance host filesystem, host-level persistence survives reboot and config reset, so a compromised box cannot be trusted to tell you it was compromised.

Remediation

1. Am I affected? Check the Remote Support version in the /login console footer; 26.2.3 or earlier is vulnerable. Then establish your exposure window: was the appliance internet-reachable at any point since late August? Preserve external firewall and reverse-proxy logs now — those are off-box and the attacker could not delete them.
2. Patch — apply BT26-05. SaaS tenants were patched the week of October 8; self-hosted appliances must apply the BT26-05 patch manually, and builds below the current supported release must upgrade first. Patching closes the hole; it does not remove prior exposure.
3. Can't patch this minute? Compensating controls. Take the admin interface and the appliance off the open internet — restrict /login and the client endpoints to known management IPs at the firewall or reverse proxy. A WAF rule that blocks requests to unknown .php paths and drops WebSocket upgrades to non-standard paths (e.g. /uidchanarge) buys time, but it is a tourniquet, not a fix.
4. Hunt for compromise. Map the GTIG indicators to your telemetry. On the host: unexpected .php files under the web root (mangoapi.php, SHA-256 dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb), a SUID /usr/bin/dbus-authd, the zz-root-persist startup script, NOPASSWD sudoers additions, bt-secrets vault access with a missing bt-secrets.log, and a BARECLAW listener (ingredi_ws, SHA-256 1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462) on TCP 19800. In the logs: user_changed events raising Jump Item or Team roles to Administrator, /login logins from residential or VPN address space, requests to unknown .php paths, and WebSocket upgrades from unexpected sources. GTIG published YARA rules G_Hunting_Webshell_SAWFLY_1 and G_Hunting_Backdoor_BARECLAW_1. But note the asymmetry: every host-side indicator sits on a box the attacker had root on and whose logs they deleted.
5. Eradicate and verify. Mandiant's guidance is rebuild, not clean: snapshot the appliance (with memory) for evidence first, then redeploy from a clean, fully patched image, restoring only a configuration backup from before the exposure window and issuing a new TLS certificate. Rotate credentials only after patching or rebuilding, in dependency order — rotate while the attacker still controls the box and you hand them the new secrets. Then confirm the appliance is clean by the same evidence you used to find it dirty.

Detecting the next appliance breach while it is happening

Steps 4 and 5 are the honest admission that host-based detection failed here by design: the one box the attacker fully owned is the one you were asking to report on itself. What the attacker could not delete is the traffic. BARECLAW is a SOCKS5 tunnel riding WebSockets to a localhost listener; the lateral movement is a privileged-access appliance suddenly opening remote sessions into downstream systems and transferring internal documents outward. On the wire, both are anomalies against the appliance's own baseline — a box that normally brokers inbound sessions now sustaining outbound tunnels and egress — regardless of what the appliance's own logs say, or no longer say.

This is the case Zero Hunt's AI Traffic Analysis was built for. It is a proprietary deep-learning model with four parallel inference heads — suspicious traffic, malware classification, attack-type identification and application fingerprinting — trained on billions of PCAP sequences and running locally on the appliance GPU at multi-gigabit line rate. When a compromised host's own telemetry is worthless because the intruder has root and has wiped the logs, the network is the only witness that was never under their control — and it sees the tunnel and the lateral fan-out while they are happening, not in next morning's SIEM digest.

The other half of the answer is not waiting six weeks for someone else to find the zero-day in your edge appliance. Zero Hunt is an autonomous AI red team that runs on-premise on its own models, with a human in the loop for every action that matters: a 10-agent swarm fingerprints an internet-facing device like Remote Support and, black-box by default, writes a per-target proof-of-concept to establish whether your deployment is reachable — the same question the version table cannot answer, and the one Armory Castle answered for its victims in late August. When a fix lands, the AI Remediation Advisor ranks it by real exploitability and re-verifies with the same proof that demonstrated the issue. For teams weighing how much of this to keep in-house on a sovereign appliance rather than a cloud service, our on-premise pentest platform buyer's guide lays out the trade-offs — the same residency logic that makes a privileged-access appliance worth defending in the first place.

What is not known yet

• The exact fixed version number. The advisory names the BT26-05 patch and the ≤26.2.3 affected range; a single fixed build number was not confirmable from public primary sources at publication.
• Total number of compromised appliances. GTIG documented the technique on observed intrusions; the full victim count is not public, and the 1,400+ exposed figure from Shadowserver is exposure, not confirmed compromise.
• CISA KEV status. As of catalog version 2026.10.15 the CVE is not listed; given active nation-state exploitation of mass-deployed software, a KEV addition would not be surprising. We will update this post if it lands.
• Whether exploitation has broadened beyond Armory Castle now that the flaw is public. Mandiant warns the group's history is wide, opportunistic exploitation, and public disclosure typically widens the field.