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

Last updated: 26 October 2026. Sources are listed at the end.

BeyondTrust has patched a critical BeyondTrust vulnerability in its Remote Support product, tracked as CVE-2026-102764. The vendor published advisory BT26-05 on 15 October 2026. However, attackers had already been using the flaw as a zero-day since 29 August 2026, according to Google Threat Intelligence Group (GTIG) and Mandiant.

GTIG links the attacks to a suspected China-nexus espionage group it calls ARMORY CASTLE, formerly UNC5221. CrowdStrike tracks the same cluster as WARP PANDA. The next day, 16 October, CISA added the CVE to its Known Exploited Vulnerabilities (KEV) catalog.

This matters for Indian IT teams and managed service providers (MSPs) because Remote Support sits in a trusted position. It holds saved credentials and can open sessions straight onto your servers and staff laptops. So if the appliance falls, everything it can reach is exposed too.

The short answer

• Self-hosted Remote Support: apply the BT26-05-RS patch now if you run 24.3.1 to 26.2.3. Older versions must upgrade first, then patch.
• SaaS customers: BeyondTrust patched all cloud instances by 9 October 2026. Still, Mandiant advises reviewing configuration and rotating credentials.
• Privileged Remote Access (PRA): BeyondTrust found no way to exploit it, but PRA shares the code. Apply the precautionary patch on self-hosted PRA and confirm the right package with BeyondTrust Support.
• Assume compromise if your appliance was internet-facing on a vulnerable version since late August. Preserve evidence before you reboot or rebuild.
• Rotate credentials only after patching or rebuilding, otherwise the attacker can simply steal the new ones.

What is the BeyondTrust vulnerability?

The advisory describes the bug as improper origin validation (CWE-290, authentication bypass by spoofing). In plain English, internal Remote Support components accepted messages without properly checking where they came from. As a result, a remote attacker with no login could perform file operations on the appliance.

GTIG puts it more bluntly: the flaw allows unauthenticated arbitrary file upload. Uploading a PHP file to a web server is usually enough to run code, and that is what happened here. BeyondTrust scores it 9.3 (Critical) under CVSS 4.0. Rescana reports that NVD rates it 9.8 under CVSS 3.1, although we could not load the NVD page to confirm this.

BeyondTrust has not published technical details of the bug, and we have not seen a public proof-of-concept. That said, GTIG expects possible wider, opportunistic exploitation now that the flaw is public. The same group did this after the 2024 Ivanti Connect Secure disclosures.

Timeline

Sources differ slightly on the SaaS date. BleepingComputer says 8 October, while the BeyondTrust advisory and the Canadian Cyber Centre say 9 October. Either way, cloud tenants were patched before public disclosure.

So far, only two victims of this BeyondTrust vulnerability have been confirmed publicly. Neither BeyondTrust nor Google has said whether other customers were breached. Meanwhile, BleepingComputer cites Shadowserver tracking more than 1,400 internet-exposed Remote Support instances, without saying how many are patched.

What the attackers did after getting in

GTIG’s report is detailed, and it explains why patching the BeyondTrust vulnerability alone is not enough. In summary, the attackers:

1. Uploaded a staging file, then dropped the SAWFLY PHP web shell (mangoapi.php) about 11 minutes later.
2. Copied /bin/sh to /usr/bin/dbus-authd with the SUID bit set, giving them a root backdoor.
3. Used the appliance’s own bt-secrets tool to dump the credential vault, then deleted its log.
4. Added a boot script that grants passwordless sudo, which survives reboots and configuration resets.
5. Deleted appliance, web and PHP logs to hide their tracks.
6. Logged in to the /login admin portal with a stolen Administrator account. Then they raised Jump Item and Team permissions from No Access to Administrator.
7. Opened support sessions to user desktops and pulled internal documents, such as software inventories.
8. Installed the BARECLAW SOCKS5-over-WebSocket tunneller and exposed it through the appliance’s HAProxy on the path /uidchanarge.

In other words, the Remote Support box became a stepping stone into the networks it served. For an MSP, that could mean every client whose machines appear in your Jump Item list.

Am I affected?

Remote Support is a closed appliance, so there is no shell command to check its version. Instead, sign in to the /appliance admin interface and check the installed version and patch list. Also confirm whether automatic updates are on. Rapid7 notes that customers cannot inspect the appliance filesystem themselves, so host-level checks need BeyondTrust Support.

Next, check whether your admin pages are reachable from the internet. Run this from a machine outside your network, replacing the hostname with yours. It only sends a normal web request and prints the HTTP status code. We wrote it ourselves; it is not a vendor command.

for p in /appliance /login; do
  printf '%s ' "$p"
  curl -s -o /dev/null -m 10 -w '%{http_code}\n' "https://support.example.com$p"
done

A 200 or a redirect to a login page means the page is publicly reachable. In that case, restrict it to your VPN or office IP ranges.

How to fix the BeyondTrust vulnerability, step by step

The order matters here, because the attackers stole credentials and deleted logs. GTIG and Rapid7 recommend roughly this sequence:

1. Preserve evidence first. Take a VM snapshot including memory, export the disk, and collect syslog, WAF, proxy and firewall logs. Do this before rebooting.
2. Isolate at the network edge, not from inside /appliance, so the configuration stays intact. Allow outbound traffic only to BeyondTrust update and licensing endpoints.
3. Patch. Apply BT26-05-RS from /appliance, or upgrade first if you run something older than 24.3.1. Note that upgrading closes the hole but does not remove an attacker who is already inside.
4. Rebuild if compromise is confirmed or cannot be ruled out. Deploy a clean, patched image and restore only a configuration backup taken before late August. Then issue a new TLS certificate and redeploy Jump Clients, Jumpoints and the representative console.
5. Rotate credentials, in this order: /appliance admin, /login admins and local users, API secrets, LDAP or SAML security provider accounts and keys, Vault and PRA credentials (rotated on the target systems), then integrations such as SMTP, syslog and ticketing.
6. Harden. Enforce SAML single sign-on with phishing-resistant MFA, and remove local accounts except one break-glass account. Also set the default Jump Item role to No Access, limit API account scopes, and forward logs off the appliance to a SIEM.

If you are on SaaS, steps 3 and 4 are already handled. However, steps 5 and 6 still apply, because the hosted victim shows cloud tenants were targeted too.

How to check if you were already compromised

Because the attackers wiped on-appliance logs, your best evidence is usually outside the appliance. First, search your reverse proxy, WAF or load balancer logs for the paths GTIG published. The script below is read-only. We tested it against sample plain and gzipped logs.

#!/bin/bash
# Search proxy/WAF/web logs for paths published by GTIG
LOGDIR="${1:-/var/log/nginx}"
zgrep -HiE 'app_84304470|mangoapi\.php|/uidchanarge' "$LOGDIR"/*.log* 2>/dev/null

Second, if you exported syslog from the appliance to a SIEM or log server, look for account and permission changes. GTIG highlights user_changed, user_added, api_account and security_provider events with no matching change ticket. Then count lines per day; a sudden drop to zero may mean forwarding was cut.

grep -E 'user_changed|user_added|api_account|security_provider' bt-syslog.log
awk '{print $1,$2}' bt-syslog.log | uniq -c

Third, if BeyondTrust Support or your incident responder gives you files from the appliance, compare them against GTIG’s published SHA-256 hashes:

find ./evidence -type f -exec sha256sum {} + | grep -iE 'dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb|1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462' || echo "No match for published hashes"

GTIG also lists these host artefacts for responders: /usr/bin/dbus-authd (SUID shell), /home/bomgar/sbin/post_boot.d/zz-root-persist, a NOPASSWD line in /ns/config/sudoers.template, /tmp/ingredi_ws, and an acl wswsws path /uidchanarge block in /ns/config/haproxy.conf. In addition, its report includes YARA rules for both malware families. GTIG says network indicators such as IP addresses sit in a VirusTotal collection for registered users, so we have not listed any here.

Finally, review session reports and file transfers since late August. Look for admin logins from VPN or hosting IP ranges, logins outside office hours, and sessions opened by accounts whose roles changed. Each endpoint touched in a suspicious session needs its own check.

What this means for Indian organisations and MSPs

We have not found a CERT-In advisory for CVE-2026-102764 at the time of writing. Even so, many Indian IT service firms and enterprises use BeyondTrust (formerly Bomgar) to support clients at home and abroad.

If you are an MSP and find signs of compromise, tell affected clients quickly. Their endpoints were reachable through your appliance. Also, if your organisation is covered by the CERT-In Directions of April 2022, a compromise of a remote-access system is a reportable incident within 6 hours of noticing it. The DPDP Rule 7 breach notice to the Data Protection Board applies only from May 2027, so it is not yet in force. Still, it is worth recording what personal data the attackers could reach now.

Quick checklist

• ☐ List every Remote Support and PRA deployment, and mark each as SaaS or self-hosted
• ☐ Check the version and patch status in /appliance
• ☐ Apply BT26-05-RS (upgrade first if older than 24.3.1)
• ☐ Patch self-hosted PRA as a precaution
• ☐ Snapshot and collect logs before any reboot or rebuild
• ☐ Search proxy and WAF logs for app_84304470, mangoapi.php and /uidchanarge
• ☐ Review user_changed, user_added, api_account and security_provider events since 29 August
• ☐ Look for gaps in syslog forwarding
• ☐ Review session reports and file transfers; list every endpoint touched
• ☐ Rebuild from a clean image if compromise cannot be ruled out
• ☐ Rotate admin, API, security provider, Vault and integration credentials after patching
• ☐ Restrict /appliance and /login to trusted networks and enforce MFA
• ☐ Notify downstream clients and file a CERT-In report within 6 hours if you were compromised

If you run remote-access tools at the edge of your network, a VAPT engagement can show what an attacker would reach from that foothold. Edge devices keep getting targeted, as our post on the k0t firewall and VPN credentials leak also shows.

Sources

• BeyondTrust security advisory BT26-05
• Google Threat Intelligence Group: ARMORY CASTLE exploits BeyondTrust Remote Support
• Canadian Centre for Cyber Security alert AL26-025
• Rapid7: CVE-2026-102764 exploited in the wild
• BleepingComputer: BeyondTrust patches zero-day exploited in attacks since August
• SecurityWeek: Chinese APT exploited BeyondTrust vulnerability as zero-day
• Rescana: CVE-2026-102764 now in CISA KEV

Need help finding and fixing exposed systems? Our VAPT services find unpatched and exposed systems before attackers do, and our free website safety check grades your site in seconds. Contact us for a quote.