CRITICAL: BeyondTrust Remote Support Zero-Day Exploited by China-Nexus Spies

There is a special kind of irony in an attacker breaking into the very tool your organization uses to securely reach everything else. BeyondTrust Remote Support, the product many IT teams and managed service providers still affectionately call Bomgar, sits in a privileged spot in the network. It stores credentials, brokers sessions into servers and workstations, and holds a tidy list of every machine an administrator might ever need to touch. So when a China-nexus espionage crew figures out how to own the appliance without logging in, the blast radius is not one box. It is every box that appliance can reach.

That is exactly what happened here. BeyondTrust published advisory BT26-05 this week for CVE-2026-102764, a vulnerability in Remote Support carrying a CVSS score of 9.3, and confirmed it had already been exploited as a zero-day. Google Threat Intelligence Group and Mandiant attribute the activity with high confidence to a cluster they now call ARMORY CASTLE, the same suspected PRC-nexus group previously tracked as UNC5221 and also known as Warp Panda. If that name rings a bell, it should. This is the crew behind waves of Ivanti Connect Secure exploitation and a long list of edge appliance compromises going back to at least October 2023.

Drop everything and patch this now. Then assume you need to do a lot more than patch.

What the Flaw Actually Does

BeyondTrust describes CVE-2026-102764 as an improper origin validation issue inside an internal messaging component of Remote Support. In plain terms, a component that should only be accepting trusted internal messages can be convinced to accept messages from somewhere it absolutely should not. Google's write-up says the bug lets an unauthenticated remote attacker perform file operations on the appliance, including arbitrary file upload, and that it affects all supported self-hosted versions up to and including 26.2.3.

Arbitrary file upload on an appliance that runs a PHP web stack is about as close to game over as it gets. Mandiant reconstructed the intrusion and found the attacker sending POST requests to an oddly named staging path, /app_84304470%2Ephp, and then dropping a web shell into the web root roughly eleven minutes later. From there the attacker had code execution as the appliance's site service account, and it did not stay that way for long.

The timeline matters. The zero-day was first used in late August 2026, specifically August 29, against a single self-hosted Remote Support appliance. BeyondTrust started hunting for similar activity after another security vendor's compromise became public on September 27. SaaS tenants were patched on October 9, and public disclosure followed on October 15. That means self-hosted customers had a window of roughly seven weeks where a capable, motivated adversary held a working exploit and nobody else knew about it.

How ARMORY CASTLE Worked the Box

The post-exploitation tradecraft is worth reading closely, because it shows an operator who understood BeyondTrust internals better than most of the admins who run these appliances.

The initial foothold was a web shell Google calls SAWFLY, dropped as mangoapi.php. It is a small, obfuscated PHP implant that speaks over a custom Base32 transport wrapped in RC4 encryption. It also returns an HTTP 404 to any request missing a specific parameter, which is a polite way of saying it hides from scanners and curious administrators alike.

Escalation to root was refreshingly low tech. The attacker copied /bin/sh to /usr/bin/dbus-authd, changed its owner to root, and set the SUID bit. That gives anyone who runs the file a root shell, and the name was clearly chosen to look like a boring system daemon nobody would think twice about. For persistence across reboots, they dropped a script named zz-root-persist into /home/bomgar/sbin/post_boot.d/ that quietly adds a passwordless sudo rule for the site service account to the sudoers template and rebuilds the configuration at startup.

Then came the part that should keep MSPs up at night. The attacker used BeyondTrust's own proprietary command line tool, /ns/sbin/bt-secrets, to dump the credential vault. Mandiant observed them trying several different command syntaxes until one worked, then deleting the bt-secrets logs afterward. Every stored password, API key, and endpoint credential on that appliance should be considered stolen.

With administrator credentials in hand, the intruder logged into the /login admin portal, bumped their account's Jump Item and Team roles from No Access to Administrator, and started remote support sessions into downstream systems. They used the built-in file transfer feature to pull internal documents, including software inventories. In other words, they used the remote support tool to do remote support, just not for anyone who was paying for it.

To keep a reliable tunnel into the environment, ARMORY CASTLE deployed BARECLAW, a C-based SOCKS5 over WebSocket proxy written with embedded CivetWeb and OpenSSL. It ran from /tmp/ingredi_ws on a localhost-only port, which means external scans would never see it. The clever bit was editing the appliance's own HAProxy configuration at /ns/config/haproxy.conf so that requests to the path /uidchanarge were quietly routed to that hidden backend. The appliance's legitimate front door became the attacker's tunnel entrance. Finally, the operators wiped auth, SSL, HTTP access, PHP and system logs on the way out, because of course they did.

Who Is Affected

Every self-hosted BeyondTrust Remote Support appliance running a version up to 26.2.3 is in scope. BeyondTrust says customers on versions 24.3.1 through 26.2.3 should manually apply the BT26-05-RS patch from the /appliance interface. Anyone running something older than 24.3.1 has to upgrade to a supported release first and then apply the patch. SaaS customers were patched by BeyondTrust on October 9, but that only closes the hole. It does not tell you whether someone already walked through it.

The targets ARMORY CASTLE has historically favored should make a lot of readers uncomfortable. Legal services, SaaS providers, business process outsourcers, technology firms, and government agencies all show up on its list, and the group is after long-term intelligence collection rather than a quick ransom. BeyondTrust notes the actor uses zero-days selectively against chosen targets, then pivots to broad, opportunistic exploitation of unpatched systems once a bug goes public. Google explicitly expects that pattern to repeat here, just as it did after the Ivanti disclosures in early 2024. Translation: the selective phase is over, and the spray and pray phase is about to start.

What to Do Right Now

Patching is step one, and it should happen today. Self-hosted customers on 24.3.1 or later need to apply BT26-05-RS, and anyone older needs to upgrade and then patch. Do not treat the upgrade itself as remediation, because Google is clear that upgrading does not undo any compromise that already happened.

Step two is accepting the uncomfortable guidance from the researchers. Any appliance that was reachable from the internet on a vulnerable version during the exploitation window should be treated as potentially compromised until someone actually reviews it. If you have reason to believe an appliance was touched, preserve evidence before you start changing things. Snapshot the VM with memory, export disks, and pull external syslog, WAF, and firewall logs. Then block inbound traffic, restrict egress, disable (rather than delete) sessions, Jump Clients, Jumpoints and API accounts, and rebuild from a clean patched image. Restore only a configuration backup taken before the exposure window and issue a fresh TLS certificate.

Credential rotation needs to happen after patching or rebuilding, not before. Rotate in dependency order, covering administrator accounts, API accounts, SAML configuration, vault entries, and every integration credential. Rotating while the attacker still has a foothold just hands them the new passwords, which is the security equivalent of changing your locks and leaving the new key under the mat.

On the detection side, there is a solid list of things to hunt for. Look on the appliance for mangoapi.php, a SUID binary at /usr/bin/dbus-authd, the zz-root-persist script in the post boot directory, anything at /tmp/ingredi_ws, and an HAProxy ACL named wswsws pointing at a local backend. Check sudoers for unexpected passwordless entries for the site service account. Google published SHA-256 hashes for the SAWFLY sample (dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb) and the BARECLAW binary (1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462), along with a YARA rule for the web shell.

In your logs, the most telling signal is likely a user_changed event where a Jump Item or team role jumps to Administrator, followed by new sessions and file transfers from that same account. Also watch for user_added, API account, or security provider changes that have no change ticket behind them, admin logins to /login from residential or commercial VPN address space, requests to unfamiliar .php paths, WebSocket upgrades to odd paths like /uidchanarge, and unexplained gaps in syslog forwarding. That last one matters more than people think. Silence from an appliance that is usually chatty is itself an indicator.

Longer term, this is a good moment to tighten the control plane. Restrict /login and /appliance to known IP ranges, put a logging reverse proxy or WAF in front of the appliance, require SAML SSO with phishing-resistant MFA, enable MFA on the built-in admin account, set the default Jump Item role to No Access, scope API accounts tightly, and consider an external vault for privileged credentials. Default-deny outbound filtering on the appliance would have made BARECLAW's job considerably harder.

The Bigger Picture

This is the second serious BeyondTrust Remote Support story of 2026, following CVE-2026-1731 in February, and it continues a pattern that has been building for years. Remote access and privileged access tools are among the most valuable targets on any network because they concentrate trust. Compromise one and you inherit the keys to everything downstream. ARMORY CASTLE knows this, and BeyondTrust even assesses the group is using an AI-assisted working model of the products it targets to speed up exploit development. Expect more of this, not less.

The MSP Angle

If you or your clients run self-hosted BeyondTrust Remote Support, this is a ready-made reason to offer a paid compromise assessment and credential rotation engagement for every appliance exposed during the August to October window. It is also a natural opening to sell managed privileged access hardening, SIEM log forwarding for remote access tools, and an external attack surface review of every remote support and VPN appliance in the client's environment.