BeyondTrust Remote Support flaw: patch the appliance and investigate its access

This is for the IT practitioner responsible for remote support at a business, school, or nonprofit. If your organization runs BeyondTrust Remote Support, formerly Bomgar, October’s disclosure deserves a specific check of the appliance and its access to other systems.

BeyondTrust published advisory BT26-05 on October 15, 2026, for CVE-2026-102764. A Common Vulnerabilities and Exposures identifier is the tracking number that lets administrators match notices about the same flaw. The vendor describes inadequate message-origin validation in an internal component, allowing remote file operations on an affected appliance. The advisory rates the issue critical.

This is not just a laboratory finding. The Cybersecurity and Infrastructure Security Agency (CISA) added the flaw to its Known Exploited Vulnerabilities catalog on October 16 and urged patching the same day. Canada’s Cyber Centre flags exploitation in the wild as well. That makes this an urgent exposure and investigation question, rather than something to leave in a routine patch queue.

An October disclosure of earlier exploitation

BeyondTrust’s October 16 account says exploitation occurred against one hosted Remote Support instance and one self-hosted appliance on August 29. It says the patch was released October 8 and that, at that update, it knew of those two affected customers. That is a bounded vendor account, not a final worldwide victim count. BeyondTrust’s incident explanation supplies the timeline.

Mandiant separately reports that the flaw was exploited as a zero-day in late August. It attributes the activity to ARMORY CASTLE, a suspected China-linked espionage actor formerly tracked as UNC5221. That is the investigators’ attribution, not an independently established identity. Mandiant’s October 15 report describes post-compromise persistence, theft of stored credentials from the appliance’s vault and password safe, deletion of logs, and access to downstream endpoints.

The date distinction matters. The reason to write about this now is the October disclosure, available remediation, and exploitation warning. It would be misleading to describe the documented August intrusion as a newly observed October attack wave.

Verify the patch, not just the version number

The advisory lists Remote Support versions through 26.2.3 as affected. It identifies the BT26-05-RS patch for versions 24.3.1 through 26.2.3 and says older installations need an upgrade to apply it. Self-hosted customers must apply the patch manually unless their appliance receives automatic updates. The advisory says all hosted Remote Support customers were patched as of October 9.

The vendor’s incident explanation also recommends immediate patching for self-hosted Privileged Remote Access because it shares affected code. BeyondTrust says its testing had not found a way to exploit that product. Keep those two statements together: precautionary patch guidance does not establish confirmed exploitation of Privileged Remote Access.

For your own records, capture the installed product, hosting arrangement, version, patch status, and verification time. A ticket saying “updated BeyondTrust” is too vague for the next administrator to determine what was actually done. Ask the provider for written confirmation if someone else operates the appliance.

Why the support system changes the investigation

Consider the questions you would ask if someone entered a receptionist’s workstation. Now ask those questions about a system your technicians use to reach other computers. Which accounts can start sessions? Which targets are available? What privileges do those sessions carry? What secrets are stored or made available there?

Build that map before deciding the investigation ends at the appliance. You do not need to assume every reachable computer was compromised. You do need to know which computers require examination and which credentials might need replacement.

Mandiant warns that host-level persistence can survive reboot and configuration reset, and recommends clean redeployment for appliances with confirmed or unknown compromise status. It also emphasizes preserving evidence before making changes, and isolating the appliance by blocking inbound traffic and disabling sessions and Jump Clients rather than deleting them. Use its detailed guidance with the vendor and an incident responder; avoid improvising a cleanup from a few filenames mentioned in a news report.

What to do about it

Give the appliance a named owner and verify the vendor’s current remediation instructions today. If an outside managed service provider runs it, ask for the installation’s actual patch evidence and the exposure review. Request a clear answer for your environment rather than a general statement that the provider has addressed the advisory.

Make patching and investigating prior access separate tasks. One task establishes whether the known entry point has been addressed. The other evaluates what may have happened before that point was closed. Closing the first task should not automatically close the second.

Preserve relevant evidence before disruptive changes when circumstances permit. Agree with the responder on what to collect, where it will be stored, and who can access it. Do not treat a gap in appliance logs as reassuring without checking whether another system retained the same period. Document missing evidence explicitly.

Next, work through the access map. List the accounts and credentials associated with the appliance and identify their owners. Plan any required credential replacement with the people who operate dependent services, so a security change does not silently break an unattended process. Record completion and verify the dependent service still works.

Decide how support will continue if the appliance must be isolated or rebuilt. Name the person authorized to approve emergency access, describe how that access will be recorded, and set an expiration. A temporary workaround needs an owner and a removal date, especially during an already busy incident.

Before returning a rebuilt system to service, review which people can administer it and which endpoints it can reach. Ask whether each permission has a current operational purpose. Preserve a record of that approved configuration so the next review has something concrete to compare against.

Finally, brief management using three separate statements: whether the patch is verified, whether compromise was found, and what uncertainty remains. “No compromise found in the evidence available” is a useful finding when its limits are stated. It should never quietly become “nothing happened.”

What is not established

The cited sources do not establish a final global victim count or prove that every exposed appliance was compromised. Mandiant’s warning of possible wider exploitation after disclosure is a warning, not confirmation that such a wave has occurred. Recheck the advisory before publishing or acting, particularly if the vendor has revised product guidance since October 24.

Sources

• BeyondTrust — Security advisory BT26-05, issued and updated October 15, 2026.
• BeyondTrust — ARMORY CASTLE and BT26-05: What Security Teams Need to Know, October 2026.
• Google Threat Intelligence Group / Mandiant — ARMORY CASTLE Exploits BeyondTrust, October 15, 2026.
• Canadian Centre for Cyber Security — BeyondTrust security advisory AV26-1054, Update 1, October 16, 2026.
• CISA — CISA Urges Patching Critical Vulnerability in BeyondTrust Remote Support, October 16, 2026.
• NIST National Vulnerability Database — CVE-2026-102764.