BeyondTrust Remote Support Zero-Day CVE-2026-102764: What to Do

CVE-2026-102764 is a critical flaw in BeyondTrust Remote Support 26.2.3 and earlier that a suspected China-nexus espionage group exploited as a zero-day from late August 2026. SaaS customers were patched by 9 October. Self-hosted owners should apply BT26-05-RS now, treat exposed appliances as possibly compromised, review them, rebuild if needed and then rotate credentials.

A remote support appliance holds credentials for, and opens sessions into, every endpoint your help desk can reach. Our edge device roundup gave this flaw one sentence. This post covers the verified facts, why remote support tools are a supply chain risk, and the response order Mandiant, CISA and BeyondTrust recommend.

What happened

BeyondTrust's advisory page returned an access error for us, so vendor details come from the Google Threat Intelligence Group (GTIG) and Mandiant report, CISA, the Canadian Centre for Cyber Security and reporting that quotes the advisory.

Sources disagree on three points:

• Instances hit. Rapid7 and CSO Online, citing BeyondTrust, report two: one hosted, one self-hosted. The Hacker News describes a single self-hosted appliance. CSO Online says neither company has said whether other customers were affected.
• SaaS patch date. BleepingComputer says 8 October. BeyondTrust, as cited by Rapid7 and the Cyber Centre, says all SaaS customers were patched as of 9 October. Most likely the patch shipped on the 8th and the rollout finished on the 9th.
• Disclosure date. GTIG, Rapid7 and the Cyber Centre date the advisory 15 October; some reporting gives 16 October.

The facts in one table

The Cyber Centre puts the core risk plainly: "The vulnerability requires no credentials or user action."

Who did it, and what we know about them

GTIG attributes the zero-day exploitation to ARMORY CASTLE, saying the tooling and techniques match activity it tracked before. It gives no confidence level for this attribution, so we use its own label: a suspected PRC-nexus espionage actor. GTIG does assess with high confidence that the group will keep using edge device zero-days.

BleepingComputer and The Hacker News link the cluster, under its older name UNC5221, to exploitation of Citrix NetScaler CVE-2023-4966 and Ivanti Connect Secure CVE-2023-46805, CVE-2024-21887 and CVE-2025-0282. The Hacker News lists past targets including legal services, SaaS providers, business process outsourcers, technology firms and governments.

Two claims come from BeyondTrust alone. The Hacker News reports its view that the actor uses zero-days quietly against chosen targets, then exploits broadly once a flaw is public. CSO Online reports BeyondTrust suspects, without forensic proof, that the actor uses AI to model target products.

GTIG's warning is the practical part: organisations should prepare for possible widespread exploitation now that the flaw is public. BleepingComputer reports that Shadowserver tracks more than 1,400 internet-exposed BeyondTrust remote support instances, without saying how many are patched.

What the attackers did after getting in

We will not describe how the flaw is exploited; Rapid7 notes BeyondTrust is withholding those details while customers patch. Here is the post-exploitation pattern GTIG and Mandiant documented, at a high level:

• A web shell foothold. GTIG names it SAWFLY, an obfuscated PHP web shell with encrypted command and control. CSO Online reports it appeared in the web root about 11 minutes after the first malicious request.
• Root on the appliance host, followed by persistence designed to survive reboot and configuration reset.
• Attempts to dump the appliance's credential store.
• Log deletion. CSO Online reports more than a dozen system, web server and application logs were removed.
• Abuse of the product itself. Using a compromised administrator account, the actor raised permissions on Jump Items and Teams, which let it open remote sessions to downstream systems, and used the file transfer feature to collect internal documents.
• A tunnel back in. GTIG names BARECLAW, a SOCKS5 tunneler over WebSocket, exposed to the internet through a change to the appliance's reverse proxy configuration.

Mandiant's report lists file names, SHA-256 hashes and two YARA rules for SAWFLY and BARECLAW. Use those directly from the report rather than from a copy. GTIG also notes a hard limit: customers cannot audit the appliance host file system themselves. Inspection of the host needs BeyondTrust Support.

One detail applies to every security team. CSO Online reports that BeyondTrust's sensors alerted in real time on the privilege escalation, but a third-party detection platform's automated triage closed those alerts as false positives. BeyondTrust's lesson, as reported: automated triage should not close high-severity signals on its own.

Why remote support tools are a supply chain risk

Supply chain talk usually means packages and build systems. Remote support software belongs in it too, for five reasons.

It is trusted by design. The product exists to reach inside other machines. Agents such as Jump Clients sit on endpoints and servers, often with high privilege. GTIG says control of this appliance can give an attacker every credential it stores or brokers. That includes vault entries injected into sessions and anything a technician typed during a support call.

One box fans out to many. A single appliance can reach every desktop, server and network device in its Jump Item list. If an outsourced IT provider or MSP runs it, the fan-out crosses company lines to every client that provider supports. The Hacker News notes ARMORY CASTLE has historically targeted outsourcers and SaaS providers, exactly where that multiplier lives.

The vendor's cloud is shared infrastructure. This time one of the two compromised instances was BeyondTrust-hosted, per BeyondTrust's own account. In an earlier incident tied to CVE-2024-12356 and CVE-2024-12686, BleepingComputer reports that a stolen API key was used to compromise 17 Remote Support SaaS instances, including one used by the US Treasury Department. SaaS moves patching to the vendor, which helped here, but the vendor's platform can still be the target.

You cannot see inside it. You cannot run your own agent on most appliances or audit the host, and this attacker deleted local logs. Your visibility is whatever left the box first.

It is often owned outside security. Remote support tools usually belong to the service desk and may be missing from the inventory security works from. CSO Online notes BT26-05 is BeyondTrust's third critical-rated Remote Support advisory this year, and Rapid7 notes that CVE-2026-1731, an earlier Remote Support flaw, entered KEV in February 2026. A tool with that cadence needs a named owner who reads every advisory.

For the broader pattern of third-party platforms becoming everyone's incident, see our IDCF Cloud ransomware post.

What to do now

This sequence combines BeyondTrust's guidance as reported, Mandiant's phased, patch-first approach, and CISA's alert. Placeholders in angle brackets appear only inside code blocks; replace them with your own values.

1. Find every deployment. The Cyber Centre's first step: identify every Remote Support deployment and whether it is SaaS or self-hosted. Include PRA, and ask outsourced IT providers and MSPs whether they use BeyondTrust to reach your systems. Confirm the KEV entry:

curl -s --max-time 30 \
  https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  | jq '.vulnerabilities[] | select(.cveID=="CVE-2026-102764")
        | {cveID, vendorProject, product, dateAdded, dueDate, requiredAction}'

2. Check the version and patch status. Self-hosted customers confirm the installed version and the BT26-05-RS patch in the /appliance interface, per Rapid7. Anything at 26.2.3 or earlier without the patch is affected. If automatic updates are off, the patch will not arrive on its own.

3. Check exposure from outside your network. GTIG recommends restricting /login and /appliance by IP address or network segment. Run this from a host outside your perimeter. A timeout is what you want for both paths.

for path in /login /appliance; do
  printf "%s " "$path"
  curl -sk -o /dev/null -w "%{http_code}\n" --max-time 5 "https://<rs-hostname>$path"
done

4. Preserve evidence before you change anything. CISA asks for a snapshot of virtual appliances or an image of physical ones, immediate forwarding of appliance syslog and session events to your SIEM, and collection of WAF, reverse proxy and perimeter firewall logs for the exposure window. CSO Online reports Mandiant's advice to snapshot before any reboot. Record the current certificate so you can confirm a new one is issued after a rebuild:

echo | openssl s_client -connect <rs-hostname>:443 -servername <rs-hostname> 2>/dev/null \
  | openssl x509 -noout -subject -issuer -serial -dates -fingerprint -sha256

5. Patch. SaaS needs no appliance action. Self-hosted 24.3.1 or later applies BT26-05-RS from /appliance. Older versions upgrade, then patch. GTIG is clear that upgrading does not undo any exposure that already happened.

6. Hunt. Use the table in the next section. BeyondTrust offers a hunting package through its trust portal, per Rapid7, and warns that the absence of known indicators does not prove an appliance is clean.

7. Isolate and rebuild if you find anything, or cannot rule it out. Mandiant's isolation steps: block inbound traffic at the perimeter, limit outbound traffic to BeyondTrust update and licensing endpoints, and disable (not delete) sessions, Jump Clients, Jumpoints and API accounts. Rebuild from a clean, patched image rather than cleaning in place, with a new TLS certificate.

8. Rotate credentials, in order, after the patch or rebuild. Mandiant's rule, in its words: "Rotate credentials only after the appliance has been patched or rebuilt." Mandiant's order: /appliance admin credentials; /login administrators and local users; API client secrets; security provider bind accounts and SAML signing keys; vault, Password Safe or PRA credentials, rotated at the target system; integration credentials such as SMTP, syslog and ticketing connectors; and any credential typed into a support session during the exposure window. CISA adds: revoke all active support sessions and review new MFA registrations on privileged accounts.

9. Check the downstream side. The actor used the appliance to open sessions on other systems. Review support session reports and file transfers for the window, then look at the endpoints those sessions touched. Inventory Jump Clients on your fleet so you know what the appliance could reach:

# Windows: services from BeyondTrust or its former Bomgar name
Get-Service | Where-Object { $_.DisplayName -match 'BeyondTrust|Bomgar' } |
  Select-Object Name, DisplayName, Status

# macOS
ls /Library/LaunchDaemons /Library/LaunchAgents 2>/dev/null | grep -i -E 'bomgar|beyondtrust'
# Linux
systemctl list-units --all 2>/dev/null | grep -i -E 'bomgar|beyondtrust'

10. Harden. Mandiant's compensating controls, which do not replace the patch: SAML SSO with phishing-resistant MFA, no local accounts except one vaulted break-glass account, default Jump Item role of No Access, minimally scoped API accounts, privileged credentials in an external vault, default-deny outbound filtering, and a logging reverse proxy or WAF in front.

Hunting guide

These signals come from GTIG and Mandiant's report and BeyondTrust's guidance as quoted by Rapid7 and CISA.

Log gaps are easy to miss by eye. If you can export the appliance's syslog timestamps from your SIEM, a short script lists every silence longer than 30 minutes:

# timestamps.txt: one ISO 8601 timestamp per line, exported from your SIEM
python3 - timestamps.txt <<'EOF'
import sys
from datetime import datetime
ts = sorted(datetime.fromisoformat(l.strip().replace("Z", "+00:00"))
            for l in open(sys.argv[1]) if l.strip())
for a, b in zip(ts, ts[1:]):
    gap = (b - a).total_seconds() / 60
    if gap > 30:
        print(f"{a.isoformat()} to {b.isoformat()}  gap {gap:.0f} min")
EOF

Escalate any gap you cannot match to maintenance. Rapid7 notes that turning on forwarding now cannot recover evidence that was already deleted.

What would have helped

We do not know the setup of any affected organisation. These lessons apply to any team running a remote support platform.

Practices any team can use

Put remote access tools in the security inventory. List every remote support and privileged access tool, who runs it (you, the vendor's cloud or a provider), its version, owner and reach. Include tools your MSPs use to reach you.

Keep admin and technician interfaces off the internet. Customers need the public support portal; nobody outside needs /appliance. This is the cheapest control on Mandiant's list.

Shrink the blast radius. Default Jump Item access to none, scope each technician to what their team supports, and remove standing admin accounts. One stolen account should not reach every server.

Do not let a tool hold secrets it does not need. Mandiant's advice to move privileged credentials to an external vault limits what a compromised appliance gives away.

Ship logs off the box with long retention. The attacker deleted local logs. Forward syslog over TLS to a SIEM with months of retention, as Mandiant recommends, and alert on forwarding gaps.

Never auto-close high-severity alerts on privileged infrastructure. A person should look at a privilege escalation alert on the system that holds the keys to every endpoint.

Use auto-update where you can, and own the advisory feed where you cannot. SaaS customers were patched before disclosure; self-hosted owners without automatic updates had to act. For the wider month, see our October incident summary.

Where Safeguard fits

Limits first. Safeguard does not scan vendor appliance firmware. It would not have found this flaw, flagged a vulnerable Remote Support version, read appliance logs, detected SAWFLY or BARECLAW, monitored remote sessions or stopped the intrusion. For the appliance, rely on BeyondTrust, Mandiant and your own teams.

It helps with the software you build and run, which an attacker with remote support access may have reached.

Inventory of what you build. Safeguard generates SBOMs and scans dependencies in repositories, container images and SBOM files: safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, with JSON results under ./output. The platform shows which projects contain a given component and version. If a vendor provides an SBOM for an appliance, scanning it shows only the third-party components it declares.

Prioritised fixes while the appliance team works. Components are matched against vulnerability databases, with reachability analysis, so known exploited flaws in your own code rise to the top. Policies and gates evaluated in the platform can block a release that carries one. Autonomous remediation can open fix PRs; it ships off by default.

Approved changes, not standing access. The Safeguard CLI's assistant edits code and runs commands with your approval, under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. safeguard exec runs in CI. The desktop and phone apps can send work to a computer running the CLI and approve each command. That is itself a remote channel into a machine, so put it in the same inventory as everything else on this page and use Ask or Strict during an incident.

For tracing affected components fast, see SBOM incident response.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh) is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or above, Sigstore-signed, with evidence pages. An artifact loses its badge if it regresses.

Gold does not patch a vendor appliance. The habit it supports matters if an intrusion touched your build or application servers: rebuild quickly from patched, signed components from a curated source.

Common mistakes

• Patching and stopping. GTIG says upgrading does not fix prior exposure, and the persistence it found survives reboot and configuration reset.
• Rotating credentials before the patch or rebuild. Mandiant warns this gives fresh secrets to an attacker who still controls the appliance.
• Assuming SaaS means no work. The appliance is patched, but GTIG and CISA say credential rotation and configuration review still apply.
• Cleaning in place. Customers cannot audit the host file system. Rebuild from a clean, patched image with a new certificate.
• Forgetting downstream endpoints. Review session reports and the machines those sessions reached.
• Ignoring PRA. It shares the code. BeyondTrust recommends patching self-hosted PRA even though it found no way to exploit it there.

FAQ

What is CVE-2026-102764?

A critical flaw in BeyondTrust Remote Support, scored 9.3 under CVSS v4.0. Internal components did not properly check where messages came from, letting an unauthenticated remote attacker perform file operations on the appliance. Versions 26.2.3 and earlier are affected.

Who exploited it?

GTIG attributes the zero-day exploitation to ARMORY CASTLE, a suspected PRC-nexus espionage actor formerly tracked as UNC5221. BeyondTrust says CrowdStrike tracks the same cluster as WARP PANDA.

I use BeyondTrust's SaaS. Am I done?

The appliance was patched by 9 October, according to BeyondTrust. GTIG and CISA still advise credential rotation and configuration review. One BeyondTrust-hosted instance was among the two compromised, per BeyondTrust's account.

Is Privileged Remote Access affected?

PRA shares the affected code. BeyondTrust says it found no way to exploit it in PRA but released a patch and recommends that self-hosted PRA customers apply it. Confirm the right patch with BeyondTrust Support.

Why does Mandiant say to rotate credentials last?

Because rotating while an attacker still controls the appliance hands them the new secrets. Patch or rebuild first, then rotate in dependency order.

Does Safeguard scan BeyondTrust appliances?

No. Safeguard scans repositories, container images and SBOM files. Vendor appliance firmware is outside its scope. If the vendor provides an SBOM, Safeguard can check the third-party components listed in it.

Fix it without waiting for upstream

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show this incident or a BeyondTrust appliance. Each shows a real flow for the software you own while the appliance is patched and reviewed.

The first demo is a CLI session that fixes a lodash CVE: it reads the finding and the advisory, asks before each command, edits package.json, runs the install and tests with your approval, and pushes nothing. After a remote support compromise, you would run the same scan on the internal services those sessions could reach and ask the assistant to move vulnerable components to fixed versions before redeploying, approving each step.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then approve or deny each command and file edit until the upgrade is done and tests pass. The contrast with this incident is the point: each action waits for a named person's yes, rather than relying on standing access.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. It is the same least privilege habit this incident argues for, applied to an AI assistant: grant only the tools a task needs.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs.

Quick check

Sources

• Google Threat Intelligence Group and Mandiant: ARMORY CASTLE Exploits BeyondTrust
• CISA: CISA Urges Patching of Critical Vulnerability in BeyondTrust Remote Support
• CISA: Adds Two Known Exploited Vulnerabilities to Catalog (16 Oct 2026)
• Canadian Centre for Cyber Security: AL26-025, Critical vulnerability impacting BeyondTrust Remote Support
• Rapid7: CVE-2026-102764, critical BeyondTrust Remote Support authentication bypass exploited in the wild
• BleepingComputer: BeyondTrust patches zero-day exploited in attacks since August
• CSO Online: BeyondTrust zero-day tied to Chinese spies puts Remote Support users on alert
• The Hacker News: China-linked hackers exploited BeyondTrust Remote Support zero-day
• BeyondTrust: Security advisory BT26-05 (did not load for us; cited through the sources above)

Last reviewed: 22 October 2026. This is a developing story; check the linked advisories for the latest status.