BREAKING: BeyondTrust Remote Support zero-day lets attackers plant a web shell without logging in, now on CISA KEV (CVE-2026-102764)

Someone with no account can write files onto a self-hosted BeyondTrust Remote Support appliance, drop a web shell, and turn it into root on the box that holds your support team's stored credentials. BeyondTrust disclosed CVE-2026-102764 on October 15 and shipped the BT26-05-RS patch a week earlier, on October 8. Mandiant says a China-nexus espionage group used it as a zero-day starting August 29. On October 16, CISA added it to the Known Exploited Vulnerabilities catalog with a federal deadline of October 19. If you run Remote Support (the product formerly called Bomgar) on your own appliance, apply the patch first and read the rest after.

This is our operator read of BeyondTrust advisory BT26-05, BeyondTrust's incident post, Mandiant's analysis, and the CISA KEV entry. The source record for the CVE lives in the HOL Guard evidence pack.

How to fix

Every Remote Support version up to and including 26.2.3 is affected. There is no new version number to jump to. The fix is a patch named BT26-05-RS that installs on top of 24.3.1 through 26.2.3.

If the patch does not show up in /appliance, BeyondTrust's instruction is to open a support case that cites BT26-05.

If you cannot patch today, block inbound traffic to the appliance's public address at your firewall. Mandiant recommends doing this at the firewall rather than inside /appliance, so the appliance configuration stays intact for review. That takes remote support offline, so warn the help desk first.

Patching closes the door. It does not remove anyone already inside.

This is the part that is easy to miss in a "patch now" headline. Mandiant traced what the attackers did after the file write, and every step was built to survive the fix:

• They planted a PHP web shell (Mandiant calls it SAWFLY, filename mangoapi.php) in the appliance's web root. It answers 404 to anything that does not carry the right parameter, so a scanner sees nothing.
• They copied /bin/sh to /usr/bin/dbus-authd, set it owned by root with the SUID bit, and had a root shell on demand.
• They added a startup script that writes a passwordless sudo line into the appliance's sudoers template and then rebuilds /etc/sudoers from it. That survives a reboot and a configuration reset.
• They used BeyondTrust's own bt-secrets tool to try to dump the credential vault, then deleted its log.
• They edited the appliance's HAProxy config so a WebSocket path, /uidchanarge, forwarded to a SOCKS tunnel listening on localhost. To the outside world that looks like ordinary HTTPS to your support portal.
• They logged into /login with an admin account and raised its Jump Item and Team roles from No Access to Administrator, which let them open remote sessions to the endpoints behind the appliance and pull files off users' desktops.

Mandiant's guidance follows from that: customers cannot audit the appliance's host filesystem, so an appliance that was internet-facing and unpatched during the exposure window should be treated as possibly compromised until reviewed. If you find any sign of it, rebuild from a clean, fully patched image instead of cleaning in place, and image the old one first.

The order of operations matters too. Rotate credentials only after the appliance is patched or rebuilt. Rotating earlier hands the new passwords to whoever still controls the box.

Check your exposure from off the box

The attackers deleted on-appliance logs throughout, including /ns/log/http-access.log, /ns/log/auth.log and /var/log/messages. Whatever is left on the appliance cannot be trusted. Look where they could not reach: your reverse proxy or WAF, your firewall, and the syslog your SIEM already received.

Search proxy or WAF access logs for the paths Mandiant published:

grep -E 'app_84304470|mangoapi\.php|/uidchanarge' /var/log/your-proxy/access*.log

Then widen it. Mandiant's detection advice is any request path outside the normal Remote Support set, especially unknown .php paths, and WebSocket upgrades from addresses that are not your support staff or your endpoints.

In the Remote Support syslog in your SIEM, look for user_changed events where new_permissions:jump_item_role moves to Administrator, and for /login successes from consumer broadband or commercial VPN address space. BeyondTrust adds one more tell: a gap in log forwarding that starts and ends inside a single session.

Mandiant published SHA-256 hashes and YARA rules for the web shell and the tunnel binary (ingredi_ws). BeyondTrust customers can also request its threat hunting package for this actor through the BeyondTrust trust portal.

If anything turns up, rotate in this order

Mandiant lists the dependency order. In short: /appliance admin credentials, then /login admins and local users, then API client secrets, then security provider bind accounts and SAML signing keys, then Remote Support Vault and any Password Safe or PRA credentials (rotated at the target system, not only in the vault), then integration secrets like SMTP, syslog and ITSM connectors. Last, any password someone typed during a support session in the window. Then redeploy Jump Clients, Jumpoints and the representative console from the patched or rebuilt appliance so old tokens stop working.

Who is not in scope

• SaaS customers, for the appliance itself. BeyondTrust patched SaaS by October 9. One of the two victims BeyondTrust knows of was a BeyondTrust-hosted instance, so SaaS customers still need the credential and configuration review if they were exposed before that date.
• Self-hosted appliances that already took BT26-05-RS, either manually or through automatic updates, for new exploitation. Prior exposure still needs the review above.
• Privileged Remote Access, for now. BeyondTrust says its testing found no way to exploit PRA. It patched PRA anyway because the code is shared, and it recommends applying that patch.

What this is not

This is not a bug in the Jump Client or representative console on your users' machines; the flaw is on the appliance, and the endpoints were reached afterward through the appliance's own admin features.

The details

• CVE: CVE-2026-102764, improper origin validation in an internal messaging component of Remote Support. CWE-290, authentication bypass by spoofing.
• Severity: BeyondTrust rates it Critical, CVSS 4.0 score 9.3 (AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H). NVD analysis is still pending.
• Preconditions: network reach to the appliance. No account and no user interaction. BeyondTrust is withholding technical details of the entry point while customers patch.
• Exploitation: BeyondTrust says the actor hit one BeyondTrust-hosted and one self-hosted instance on August 29, and as of October 16 it knows of only those two customers. Mandiant and Google Threat Intelligence attribute it to ARMORY CASTLE (formerly UNC5221; CrowdStrike tracks it as WARP PANDA), the group behind earlier zero-days in Ivanti Connect Secure and Citrix NetScaler. Mandiant warns of broad exploitation now that the bug is public.
• Timeline: exploited August 29. BeyondTrust found it September 28 through a threat hunt. Its sensors had fired during the intrusion, but an automated triage tool closed those alerts as false positives. Patch released October 8, SaaS fully patched October 9, public disclosure October 15, CISA KEV October 16 with a due date of October 19.
• KEV: known ransomware use listed as Unknown. CISA marks it for forensic triage under BOD 26-04, so agencies need to look for compromise, not only patch.

References

• BeyondTrust security advisory BT26-05
• BeyondTrust: ARMORY CASTLE and BT26-05, what security teams need to know
• Mandiant / Google Threat Intelligence: ARMORY CASTLE Exploits BeyondTrust (IOCs and YARA rules)
• CISA Known Exploited Vulnerabilities catalog (CVE-2026-102764, added 2026-10-16)
• NVD: CVE-2026-102764
• CVE.org record