BeyondTrust Remote Support CVE-2026-102764: Patch Guide and Compromise Checklist

Action required for BeyondTrust Remote Support administrators: CVE-2026-102764 is a critical, actively exploited authentication-bypass vulnerability in Remote Support versions 26.2.3 and earlier. BeyondTrust rates it 9.3 under CVSS v4.0. If you operate a self-hosted appliance, determine its version and patch status immediately. Versions 24.3.1 through 26.2.3 need the BT26-05-RS patch; older installations must upgrade to a supported release and then apply the patch. SaaS Remote Support appliances were patched by BeyondTrust by October 9, 2026. A patch stops the known exposure but cannot rule out an earlier compromise.

This October 22, 2026 guide turns the vendor advisory and Mandiant investigation into an administrator-facing decision workflow: identify the deployment, verify the exact fix, preserve evidence, investigate past exposure, and determine when to involve incident responders. It does not provide exploitation instructions, and it does not claim that Horus Valley tested a live appliance.

What CVE-2026-102764 does—and why it matters

The flaw involves inadequate validation of message origin in internal Remote Support components, classified as CWE-290 (authentication bypass by spoofing). Under the conditions described by the vendor, an unauthenticated remote attacker can perform unauthorized file operations on the appliance. Security investigators observed arbitrary uploads followed by further compromise. This is especially serious because a remote-support gateway can broker privileged connections and hold or handle sensitive credentials. BeyondTrust’s BT26-05 advisory describes the vulnerability without publishing exploit mechanics.

The vendor describes Remote Support as affected; it separately advises self-hosted Privileged Remote Access (PRA) customers to apply the related patch because PRA shares code. BeyondTrust states it did not identify a way to exploit the flaw in PRA during its testing. Do not collapse those two statements into a claim of confirmed PRA exploitation. Read the vendor’s product-specific explanation.

Who needs to act now? A deployment-by-deployment decision table

This decision matrix is derived from BeyondTrust, the Canadian Cyber Centre’s detailed alert and the vendor incident timeline. Some organizations use both Remote Support and PRA; inventory each independently. If a managed service provider operates the appliance, obtain written confirmation of the product, hosting model, patch and review status.

A practical 30-minute triage workflow for administrators

The following is a planning checklist, not a claim that every environment can finish within 30 minutes. A production appliance may require change control, outage planning, vendor assistance and incident-response expertise. Use the first triage session to establish facts and ownership rather than rushing into destructive actions.

• Assign an incident owner and record the current time, affected business services, appliance hostname and public exposure status.
• Identify whether the appliance is BeyondTrust-hosted SaaS or self-hosted. Record RS and PRA separately if both are deployed.
• For self-hosted appliances, inspect the supported /appliance interface and maintenance records for installed version, update subscriptions and BT26-05 patch status.
• If the patch is missing, obtain the vendor-provided update using official channels. Versions older than 24.3.1 must be upgraded first.
• If the appliance was reachable while vulnerable, open a security investigation even if the patch is now installed.
• Preserve existing external logs, relevant alerts and configuration records; coordinate evidence collection with incident response and BeyondTrust Support.
• Document remediation evidence, test authorized support workflows, and schedule credential review according to your incident findings.

How to apply and verify the BT26-05-RS patch

For self-hosted Remote Support on supported versions, BeyondTrust directs administrators to the appliance management interface, commonly shown as /appliance. Automatic-update subscribers should confirm the specific security patch is actually installed; those without automatic updates should apply it manually. If the patch is unavailable, contact BeyondTrust Support and reference BT26-05. Do not download appliance updates from third-party file-sharing links.

• Capture the exact product and version and confirm you are authorized to administer it.
• Review BT26-05 and your product-specific maintenance documentation.
• For Remote Support 24.3.1–26.2.3, apply or verify the BT26-05-RS patch through the supported management workflow.
• For releases older than 24.3.1, follow the supported upgrade path before applying BT26-05-RS.
• Confirm the interface reports the relevant patch as installed; save change-ticket evidence and the time of completion.
• Test permitted representative remote-support workflows and monitor for errors; escalate any failures to vendor support.
• Continue investigation of any period during which the appliance was unpatched and accessible.

A green update indicator or a later maintenance date is not a substitute for verifying the specific BT26-05 remediation. Conversely, an affected base version may already have the patch installed; use the vendor interface and records rather than labeling every installation with that version compromised.

Why patching alone is not enough: the August-to-October timeline

The timeline comes from BeyondTrust’s retrospective and Mandiant’s primary investigation. Publication in October does not mean the vulnerability only became exploitable in October. Where log retention permits, teams should review the pre-disclosure window, not merely events after the advisory.

What Mandiant observed after initial access

Mandiant attributed the observed campaign to ARMORY CASTLE, a suspected PRC-nexus espionage actor previously tracked as UNC5221. Its incident response documented the SAWFLY web shell, the BARECLAW tunneler, privilege escalation, persistence, attempted access to credentials and deletion of logs or artifacts. These are observations from investigated incidents, not a prediction that every vulnerable appliance has these artifacts. See the original technical investigation.

Attribution is an analytical assessment, not proof of the identity of every attacker exploiting the same CVE. Likewise, the absence of one named malware file does not establish that an appliance is clean: attackers may change tools, erase evidence or exploit the same vulnerability differently.

Incident-response checklist: preserve, assess, contain, recover

• Preserve: retain off-appliance SIEM, syslog, network, identity-provider and access-control records before changes that could destroy evidence.
• Assess: identify the appliance’s external exposure window and compare logs and telemetry against Mandiant’s current detection guidance.
• Contain: if compromise is suspected, coordinate network isolation and emergency access continuity with responders and the service owner.
• Investigate: seek BeyondTrust Support and qualified incident-response help for host-level artifacts that normal appliance administrators may not be able to inspect.
• Protect credentials: scope privileged accounts, service credentials, tokens and secrets brokered or stored by the appliance; rotate according to a coordinated recovery plan.
• Recover: where compromise is confirmed or cannot be reasonably excluded, follow vendor and responder advice on clean rebuilding, trust restoration and monitoring.
• Validate: check that the specific patch is present and that restored support workflows, access restrictions and log forwarding work as expected.

The distinction between vulnerability remediation and incident eradication is central: applying BT26-05 addresses the known software weakness; it does not necessarily remove persistence, recover stolen secrets or restore trust in an already compromised appliance. Mandiant explicitly recommends treating internet-reachable, previously vulnerable appliances as potentially compromised until reviewed.

A simple risk-priority model for organizations with many appliances

Use the following editorial triage model to prioritize work. It is not a vendor risk score or a substitute for a formal security assessment. Assign the highest urgency to an internet-exposed self-hosted Remote Support appliance with no verified BT26-05 patch; next prioritize internal-only or access-restricted appliances that remain unpatched; then confirm patched appliances have had historical exposure reviewed. Any credible compromise indicator overrides this order and triggers incident response.

What to ask your managed service provider or internal IT team

• Is our BeyondTrust deployment Remote Support, Privileged Remote Access, or both? Is each SaaS or self-hosted?
• What exact software versions and security patches are installed, and how was installation verified?
• Was any appliance reachable from the internet between late August and remediation?
• Which centralized logs and identity events cover that exposure period, and how long are they retained?
• Have we checked the latest Mandiant indicators and investigated anomalous access or credential use?
• What is the plan if compromise is suspected: isolation, vendor case, forensics, credential rotation and clean recovery?

Ask for evidence such as maintenance-ticket IDs and sanitized screenshots rather than a blanket statement that “everything is up to date.” Avoid sharing passwords, full logs, internal IP addresses or other sensitive information in public support forums.

Common mistakes that leave organizations exposed

• Confusing SaaS and self-hosted: vendor-managed SaaS patching does not automatically update an organization’s own appliance.
• Checking only the version: a version in the affected range needs patch verification; the presence or absence of the fix matters.
• Upgrading without checking the advisory: very old releases require an upgrade and then the applicable security patch.
• Assuming a successful patch proves no intrusion: forensic review may still be needed.
• Deleting logs during repair: preserve external evidence and consult responders before destructive changes.
• Overstating PRA findings: vendor precautionary patching is not the same as confirmed exploitability in PRA.
• Relying on a single malware indicator: absence of a named file is not a clean bill of health.

Official sources, scope and update policy

The factual basis is the BeyondTrust BT26-05 advisory, BeyondTrust’s incident account, Google Threat Intelligence Group / Mandiant investigation, Canadian Cyber Centre alert and NHS England cyber alert. This article is an independently organized administrator checklist, not an appliance penetration test or a claim of access to proprietary customer systems. Recheck the vendor advisory before implementing changes because patch instructions and incident intelligence can evolve.

Bottom line

If you run BeyondTrust Remote Support, verify the BT26-05 patch today. Self-hosted instances through 26.2.3 need the appropriate fix, and versions older than 24.3.1 must upgrade first. BeyondTrust reports SaaS remediation, but organizations still need to consider historical exposure. The essential distinction is simple: patch the vulnerability, then investigate whether the appliance was already compromised.