BeyondTrust Remote Support zero-day: patch, then rebuild and rotate

BeyondTrust disclosed CVE-2026-102764 on October 15, a critical flaw in its Remote Support appliance that a China-linked espionage group used as a zero-day from August 29. It lets an attacker with no login run file operations on the appliance, which Google's Mandiant team says can lead to control of the host and "every credential the appliance stores or brokers." All supported versions up to 26.2.3 are affected. CSO Online reports a CVSS 4.0 score of 9.3. Cybersecurity Dive reports that CISA has added the flaw to its Known Exploited Vulnerabilities catalog, with a Monday deadline for federal civilian agencies.

The appliance stores the credentials support staff use to reach other systems, so a break-in opens everything they do. BeyondTrust knows of two hit customers, one hosted and one self-hosted. Kelli Vanderlee, a Google Threat Intelligence Group senior analyst, told Cybersecurity Dive that Google knows of "only a small number" of victims so far. Now that the flaw is public, Mandiant tells companies to get ready for "potential widespread exploitation."

Do you need to act?

There is no new version number, according to HOL: the patch installs on top of your current release. If it is missing from /appliance, raise a support case with BeyondTrust and cite BT26-05. Privileged Remote Access shares the affected code. BeyondTrust found no way to exploit it there but patched it anyway, so apply that patch too.

BeyondTrust released the fix on October 8, 40 days after the first attack. Patching does not remove an attacker who is already in.

How to tell if you were hit

Mandiant calls the group ARMORY CASTLE (formerly UNC5221); CrowdStrike calls it WARP PANDA. A web shell named Sawfly showed up about 11 minutes after the attackers' first request, CSO Online reports. The attackers copied a shell to /usr/bin/dbus-authd to get root, added a passwordless sudo entry, dumped the stored admin credentials and deleted logs. They raised Jump Item and Team roles from "No Access" to "Administrator" and set up a tunneling tool called Bareclaw.

Look in logs kept off the appliance, since the attackers wipe local ones:

• user_changed events where a Jump Item or team role goes up, and user_added, api_account or security_provider events with no change ticket behind them.
• Successful /login from home broadband or commercial VPN addresses, and admin logins outside business hours.
• Unknown .php paths at the reverse proxy or web application firewall, and WebSocket upgrades from addresses outside your support staff and endpoint ranges.
• A gap in syslog forwarding that starts and ends inside one session, which Mandiant ties to tampering.

Mandiant's post has file hashes and YARA rules.

Rebuild first, then rotate

Mandiant says to assume that any appliance that faced the internet while unpatched during the attack window is "potentially compromised" until someone has reviewed it. Before any change or reboot, snapshot virtual appliances including memory and export the disk; B Series hardware owners should ask BeyondTrust Support to preserve evidence. Rebuild any appliance that is compromised, or whose status you cannot confirm, from a clean, patched image: the persistence survives a reboot and a configuration reset.

Rotate credentials only after that, or the attacker sees the new ones. Mandiant's order:

1. /appliance admin credentials.
2. /login administrators and local users.
3. API client secrets.
4. SAML signing keys and the bind accounts for security providers.
5. Remote Support Vault, Password Safe and Privileged Remote Access credentials, changed on the target systems.
6. Integration credentials: SMTP, syslog, ITSM connectors and outbound event secrets.
7. Any password someone typed inside a support session while the appliance was exposed.