Useful tools

Security alert

Patch BeyondTrust Remote Support now: an exploited flaw let attackers act on the appliance, and patching alone may not be enough

CISA added a critical BeyondTrust Remote Support flaw on October 16 with a three-day deadline. Self-hosted servers need the BT26-05 patch, and exposed ones should be checked for compromise.

If you or your IT company runs a self-hosted BeyondTrust Remote Support server (the product formerly called Bomgar), patch it today and then check whether it was already compromised. CISA added CVE-2026-102764 to its Known Exploited Vulnerabilities (KEV) catalog on October 16, 2026, with a federal due date of October 19.

A remote support server can reach every computer it manages and holds credentials for many of them. That’s why one flaw here is worse than one flaw on a single workstation.

The details

  • CVE: CVE-2026-102764, an improper origin check (CWE-290, authentication bypass by spoofing)
  • What it allows: an unauthenticated attacker over the network can perform file operations on the appliance
  • Severity: CVSS 4.0 score of 9.3 (Critical), per the CVE record
  • Affected: Remote Support versions up to and including 26.2.3
  • Exploited: yes. Google’s Threat Intelligence Group and Mandiant report it was used as a zero-day starting in late August 2026 by a suspected China-linked espionage group, and expect broader opportunistic attacks now that it’s public
  • Ransomware use: unknown, per CISA

What to do

If you use BeyondTrust’s cloud (SaaS) service: BeyondTrust patched SaaS tenants by October 9. The appliance itself needs nothing from you, but the credential steps below still apply if you were told your instance was affected.

If you run it yourself (self-hosted):

  1. Apply patch BT26-05-RS. On version 24.3.1 or later, install it from the appliance’s /appliance interface, or confirm automatic updates already applied it. If you can’t see it, open a case with BeyondTrust Support and reference BT26-05.
  2. On a version older than 24.3.1, upgrade to a supported version first, then apply the patch. Mandiant notes that upgrading closes the hole but doesn’t undo any earlier compromise.
  3. Not ready to patch? Block inbound access to the appliance at your firewall (not inside the appliance’s own settings), or at least restrict the /login and /appliance pages to known addresses. This reduces exposure; it doesn’t replace the patch.

If the server was reachable from the internet while on a vulnerable version, treat it as possibly compromised until someone has reviewed it. The reported attacks included hidden backdoors that survive reboots and configuration resets, and deleted logs.

Check whether it was already hit

Patching stops new attacks. It doesn’t remove an attacker who’s already in. Mandiant’s report lists specific file and configuration indicators; start there rather than guessing. Beyond that, in the /login admin console look for:

  • Users, API accounts, or security providers you didn’t add, or changes with no ticket behind them
  • Accounts whose Jump Item or Team roles were raised to Administrator
  • Admin logins at odd hours or from unfamiliar networks
  • Changes to syslog or event destinations, or gaps in forwarded logs
  • Support sessions and file transfers started by accounts you don’t recognize

Because the appliance’s own logs can be deleted, rely on copies held elsewhere: your firewall, reverse proxy, and any syslog server.

If you find signs of compromise, or can’t rule it out

Mandiant’s guidance is to rebuild rather than clean, because customers can’t fully audit the appliance’s file system.

  1. Preserve first. Snapshot a virtual appliance (with memory) or export its disks before changing anything. For SaaS or hardware, ask BeyondTrust Support to preserve evidence.
  2. Isolate it, and disable rather than delete sessions, Jump Clients, and API accounts so the audit trail survives.
  3. Redeploy from a clean, patched image. Restore only a configuration backup that predates the exposure, then issue a new TLS certificate and redeploy Jump Clients and Jumpoints.
  4. Rotate credentials after the rebuild, not before, or the new ones go to anyone still inside. Mandiant’s order: appliance admins, then login admins and local users, API secrets, SAML and directory bind accounts, vault credentials, and any password typed into a support session during the exposure window.

Compromised remote-support tools can be used to reach the computers behind them. Treat any machine that had a session during the window as in scope for review. If you’re a public agency or a bank, this may also be a reportable incident, so confirm your notification obligations with your CSA, examiner, or counsel.

Longer term

Mandiant also recommends requiring SAML single sign-on with phishing-resistant MFA, defaulting the Jump Item role to No Access, keeping privileged credentials in an external vault, and forwarding appliance logs to a system the appliance can’t edit. See also our two-step sign-in guide and the incident response plan checklist.

Sources

  • CVE-2026-102764 record (CVE Program): description, affected versions through 26.2.3, CVSS 4.0 score of 9.3
  • Known Exploited Vulnerabilities catalog (CISA): added October 16, 2026, due October 19, ransomware use unknown, forensic triage required, link to BeyondTrust advisory BT26-05
  • ARMORY CASTLE Exploits BeyondTrust (Google Threat Intelligence Group / Mandiant, October 15, 2026): exploitation timeline, patch BT26-05-RS steps, SaaS patch date, indicators, and rebuild and credential rotation guidance

All articles