BeyondTrust CVE-2026-102764: active attacks target Remote Support

A remote support platform is designed to let an administrator operate another person’s device. When the vulnerability sits in that platform, the consequences can extend far beyond one server. Teams need to check not only the product version, but also the accounts, sessions, files and connections the appliance could reach.

On October 16, CISA added CVE-2026-102764 in BeyondTrust Remote Support to its Known Exploited Vulnerabilities catalog. The remediation deadline for US federal civilian agencies is October 19. That deadline is not automatically a legal obligation for companies elsewhere, but inclusion in KEV is strong evidence that exploitation is no longer theoretical.

BeyondTrust advisory BT26-05 rates the issue critical, with a CVSS v4 score of 9.3. The vendor describes inadequate validation of message origin in an internal messaging component. Under the right conditions, a remote attacker can perform file operations on the appliance.

Breachroad’s conclusion: an internet-exposed deployment should be treated as both an urgent patching task and a potential incident. The patch closes the known path, but it cannot undo actions taken before remediation.

Who is affected

The vendor’s table lists Remote Support versions through 26.2.3. Patch BT26-05-RS is available for supported releases from 24.3.1 through 26.2.3. An older installation must first be upgraded to a supported release before the relevant patch can be applied.

The response depends on the deployment model:

• BeyondTrust says its SaaS customers were patched by October 9;
• self-hosted customers must confirm automatic patch installation or apply it manually;
• absence from a central inventory is not proof of absence—the appliance may have been introduced by a help desk, an IT supplier or an older contract.

The advisory lists Remote Support as the product affected by the CVE. BeyondTrust also released a precautionary patch for Privileged Remote Access because it shares code, but that should not be presented as confirmation of the same vulnerability in PRA. Owners of either product should follow the vendor’s current instructions.

Why file operations are a serious signal

“File operations” need not mean access to a single document. Impact depends on process privileges, appliance contents and integrations. Configuration files, keys, certificates, logs, update artifacts and data used to establish sessions may all matter.

It is equally important not to invent consequences the sources do not confirm. A KEV listing does not prove that every vulnerable deployment was compromised, and finding a vulnerable version is not the same as confirming data theft. It is a reason to examine evidence, not to announce a breach by default.

An action plan for today

1. Find every instance. Check DNS, the CMDB, external attack-surface results, help-desk contracts and supplier accounts.
2. Separate SaaS from self-hosted. Preserve evidence of the SaaS patch date and scope; read the actual version and patch level on each self-hosted appliance.
3. Reduce exposure. If immediate patching is impossible, apply vendor-recommended restrictions and reduce network access without destroying the logs needed for investigation.
4. Patch and verify. Do not close the task at “installation completed.” Confirm the version on every node and verify normal service operation.
5. Preserve evidence. Export authentication, session, administrative, configuration-change and network logs covering a meaningful period before the patch.
6. Look for unexpected changes. Review accounts, keys, jobs, files, integrations and outbound connections. Compare the configuration with an approved copy.
7. Assess secrets and adjacent systems. If credentials, certificates or tokens were stored on the appliance, plan controlled rotation and inspect their use in destination systems.

Before rebooting or rebuilding, preserve the state needed for analysis. If an attack is ongoing, isolation may come first, but teams should record the time and scope of each action.

Patching does not answer “did they get in?”

The team should run two workstreams. One closes the vulnerability. The other determines whether activity occurred before closure. Combining both into a single “server updated” ticket often ends the investigation too soon.

Evidence of file manipulation, new accounts, unusual sessions or unknown outbound traffic should trigger the incident response plan. Scoping should include endpoints reached through Remote Support and the identities used by operators.

Facts and recommendations

Affected versions, vulnerability mechanics, the CVSS score and patch delivery details come from BeyondTrust’s advisory. Active exploitation and the October 19 federal deadline come from CISA’s KEV catalog. Neither source says that every deployment has been compromised.

Parallel patching and triage, checks of adjacent systems and the evidence-preservation sequence are Breachroad recommendations. Make them part of a repeatable vulnerability management process and incident response plan. IT, security and service owners can rehearse these decisions in cybersecurity training for organisations, while an IT security audit can assess exposed appliances and privileged access paths.