BeyondTrust's Remote Support zero-day: exploited for weeks before a patch existed

TechScripts Nepal · Kathmandu · October 26, 2026 · 6 min read

Remote support tools are built to do something that would alarm any security team if it came from an outsider: reach into machines, run commands, and hold the credentials needed to do it. That's what makes them a favorite target. In October, BeyondTrust and Google's Mandiant disclosed that attackers had been exploiting a zero-day in BeyondTrust Remote Support since late August, weeks before anyone knew, and CISA has since added it to its Known Exploited Vulnerabilities catalog.

What the flaw is

The vulnerability is CVE-2026-102764. CISA describes it as a critical authentication bypass. BeyondTrust rates it 9.3 on the CVSS 4.0 scale, and one report notes the NVD records a different score (9.8) under the older CVSS 3.1 system. The gap is a scoring-version difference, not a disagreement about severity: everyone calls it critical.

It affects BeyondTrust Remote Support (formerly Bomgar) version 26.2.3 and earlier. Patches exist for supported releases from 24.3.1 onward, and organizations on older versions have to upgrade before they can apply the patch. Reporting indicates Privileged Remote Access shares the affected code and was also patched, though sources are somewhat ambiguous on that point.

BeyondTrust is reportedly withholding low-level technical details while self-hosted customers finish patching. That's a normal precaution, and it means public technical analysis is limited for now.

The timeline

This is the part that deserves attention.

• August 29: First exploitation, against one BeyondTrust-hosted instance and one self-hosted appliance. About eleven minutes after the first malicious request, a PHP web shell (named SAWFLY by researchers) appeared in the web root.
• September 28: BeyondTrust found the intrusion, roughly a month after it began. According to reporting, this followed public reports of another vendor's edge appliances being compromised and a brief, non-specific warning from Mandiant.
• October 8: The patch was released.
• October 9: SaaS instances were patched, per Mandiant.
• October 16: BeyondTrust published advisory BT26-05, and CISA added the flaw to its catalog and published an alert urging immediate patching.

From first exploitation to public advisory is about seven weeks, and about a month of that elapsed before the vendor itself noticed. During that time, no patch existed and no customer had been told. That's what a zero-day means in practice: a defender's usual playbook of "patch when the advisory drops" doesn't cover the weeks before the advisory exists.

Who is behind it, and how sure is that

Google's Threat Intelligence Group and Mandiant attribute the activity to a group they track as ARMORY CASTLE (formerly UNC5221), which they describe as a suspected China-nexus espionage actor active since at least October 2023. BeyondTrust says CrowdStrike tracks the same cluster as WARP PANDA. The attribution is described as suspected, and neither company has said whether other customers were compromised. GTIG also assesses with high confidence that the group will keep exploiting zero-days in edge devices, meaning the internet-facing appliances that sit at a network's border.

What the attackers did once inside

Per Mandiant's observations, as reported by CSO, the intrusion went well beyond the initial foothold:

• Privilege escalation to root by copying a shell binary to a path with the SUID bit set, disguised as a system service binary.
• Persistence through a startup script that granted passwordless sudo via the sudoers template, so access would survive reboots and configuration resets.
• Credential theft attempts, including several tries at dumping the appliance's credential vault.
• Log deletion, with more than a dozen system, web server, and application logs removed.
• Permission changes using a compromised administrator account to raise Jump Item and Team permissions to Administrator, enabling sessions into downstream systems.
• Tunneling: a SOCKS5 tunneler (BARECLAW) was deployed and the HAProxy configuration edited to route traffic through a hidden local listener.

The pattern is a familiar one for capable espionage actors: get root on a trusted appliance, take the credentials it holds, cover tracks, and use the appliance as a doorway into everything it was authorized to reach.

What to do

CISA's alert and the reporting around it point to the following steps.

For every self-hosted deployment:

1. Apply the BT26-05 patch per BeyondTrust's advisory. SaaS deployments are already patched.
2. Limit external access to the appliance to necessary services, and restrict administrative interfaces to trusted networks.

If your appliance was reachable from the internet on a vulnerable version at any point since late August, treat it as potentially compromised until reviewed. Patching closes the door; it doesn't evict someone already inside. Upgrading does not remediate prior exposure.

1. Snapshot before you reboot. Preserve a forensic image of suspect appliances, because a restart can destroy evidence.
2. Collect logs from the exposure window from your WAF, reverse proxy, perimeter firewall, and the appliance, and forward them to your SIEM. Remember that attackers in this campaign deleted local logs.
3. Hunt for the specific signs: unrecognized privileged or administrative sessions, unknown script files, gaps or interruptions in log forwarding, unexpected SUID binaries, unusual sudoers entries, changes to HAProxy, and unauthorized changes to accounts, permissions, or session policies.
4. Rebuild from a known-good image rather than cleaning in place, then apply the patch.
5. Rotate credentials after patching, including everything the appliance stored or injected, and revoke active support sessions. Review any new multi-factor registrations on privileged accounts.

There's one point where the guidance isn't fully consistent: BeyondTrust says SaaS customers need take no further action, while Mandiant says credential rotation and configuration review still apply. If you use the SaaS version, the cautious reading is to do the review.

The broader lesson

Two ideas from this incident apply well beyond BeyondTrust.

Tools with the keys to everything deserve the strictest scrutiny. Remote support, privileged access management, VPN gateways, and similar appliances are all designed to reach many systems. A compromise there is a compromise of everything they connect to. Many organizations keep a good inventory of servers and laptops and a poor one of these appliances, which tend to be installed once and forgotten.

"Patched" and "safe" are different states. When a flaw is exploited before disclosure, the question isn't only "are we on the fixed version?" but "were we exposed in the weeks before it existed, and could anyone have been inside?" Answering that needs logs kept off the appliance, a clear picture of what was internet-facing and when, and the ability to rebuild a system from a clean image.

That's the same lesson as in our recent look at the Atlassian Data Center flaw, and it echoes the dwell-time problem behind the FBI job-portal breach.

If you're not sure what's internet-facing in your environment, or nobody owns the answer, that's a good first task for an outside pair of hands. A technical partner who maps your edge, checks exposure against advisories like this one, and sets up off-box logging can close that gap quickly, and at TechScripts Nepal we sometimes do that work as an embedded engineer working inside the team, which we describe in our forward-deployed engineering explainer.