CISA Flags Exploited BeyondTrust Remote Support Zero-Day

Published Oct. 17, 2026 — The U.S. Cybersecurity and Infrastructure Security Agency added a critical BeyondTrust Remote Support vulnerability to its Known Exploited Vulnerabilities catalog on Oct. 16, one day after the flaw was publicly disclosed. The move confirms that CVE-2026-102764 is not merely a theoretical risk: attackers have already used it against an internet-facing remote-support appliance.

The vulnerability affects BeyondTrust Remote Support, formerly known as Bomgar, which IT teams use to connect to and troubleshoot computers across an organization. Because those appliances can broker privileged sessions and store credentials, compromising one can give an attacker a route beyond the gateway itself.

What CVE-2026-102764 allows

The official CVE record describes an origin-validation failure in Remote Support’s internal messaging components. In plain terms, the appliance did not adequately verify where certain internal messages came from. Under the right conditions, an unauthenticated attacker can exploit that weakness over a network to perform file operations on the appliance.

BeyondTrust rates the flaw critical, with a CVSS 4.0 base score of 9.3. The record lists supported Remote Support versions through 26.2.3 as affected. Google Threat Intelligence Group and Mandiant said successful exploitation can result in arbitrary file uploads, providing the initial opening for a deeper takeover.

According to Google’s Oct. 15 investigation, a suspected China-linked espionage actor it tracks as Armory Castle exploited the flaw as a zero-day in late August. A zero-day is a vulnerability used by attackers before a fix is available or before defenders have had a reasonable opportunity to apply one.

The appliance became a path into downstream systems

Mandiant’s incident-response findings show why remote-support infrastructure deserves the same urgency as a VPN gateway or identity server. After the initial exploit, the actor installed a lightweight PHP web shell that Google calls SAWFLY. A web shell is a malicious server-side file that lets an attacker issue commands remotely.

The researchers said the attackers then escalated to root-level control, attempted to extract secrets stored by the appliance, and created persistence designed to survive reboots and configuration resets. They also used compromised administrator access to open remote-support sessions to internal endpoints and deployed a custom tunneling tool, BARECLAW, to relay network connections.

Google also observed systematic deletion of system, web-server, and application logs. That detail is important for incident responders: a clean-looking appliance log cannot by itself prove that an exposed system was never compromised. Off-device records from firewalls, reverse proxies, web application firewalls, and centralized logging platforms may preserve evidence that the appliance no longer has.

Who needs to patch, and what patching does not solve

BeyondTrust applied the fix to Remote Support software-as-a-service tenants on Oct. 9, according to Google’s report. Self-hosted customers running version 24.3.1 or later should apply the BT26-05-RS patch through the appliance interface, or confirm that automatic updates installed it. Customers on releases older than 24.3.1 need to upgrade to a supported version and then apply the patch.

Installing the update closes the vulnerability, but it does not remove malware, undo stolen credentials, or prove that a previously exposed appliance is clean. Mandiant says any appliance that was reachable from the internet while running a vulnerable version during the exploitation window should be treated as potentially compromised until it has been reviewed.

Where compromise is confirmed or cannot be ruled out, Google’s guidance favors rebuilding from a clean, fully patched image rather than trying to clean the existing host. The reasoning is straightforward: customers cannot fully audit the underlying appliance file system, while the persistence observed in this campaign could survive ordinary reboots and configuration resets.

What defenders should do now

• Inventory every self-hosted Remote Support appliance, record its exact version, and confirm whether BT26-05-RS is installed.
• If an appliance was internet-accessible while vulnerable, preserve virtual-machine memory and disk images where possible before rebooting or rebuilding it.
• Review external firewall, reverse-proxy, web application firewall, and centralized syslog data for the full exposure window, not only local appliance logs.
• After patching or rebuilding, rotate appliance administrators, API secrets, identity-provider keys, vault credentials, integration credentials, and credentials entered during support sessions in a deliberate dependency order.
• Investigate endpoints reached through suspicious support sessions and review file transfers, role changes, new API accounts, and unexplained gaps in log forwarding.

CISA’s catalog entry raises the urgency, but the most useful lesson for VPNReviews readers is broader. Remote-access and support appliances sit on a trust boundary and often hold the keys to many other systems. A VPN cannot protect an organization from a compromised administrative gateway, and changing user passwords alone is not enough if the device that brokers privileged access remains under attacker control.