BeyondTrust Remote Support Zero-Day: The Appliance That Holds the Keys Was the Target

A remote support appliance exists to log in to other machines for you. That is why its credential vault is the first thing a skilled intruder reaches for. On 15 October BeyondTrust disclosed CVE-2026-102764 in its Remote Support product, formerly Bomgar. Google Threat Intelligence Group and Mandiant say a suspected China-linked espionage actor they track as ARMORY CASTLE had been exploiting it as a zero-day since late August, roughly seven weeks earlier, and that in the intrusions they investigated the actor dumped the appliance's credential vault.

The patch is available, but it does not remove an intruder who is already inside, and it does not return what was in the vault.

What is confirmed

BeyondTrust's advisory BT26-05, as relayed by secondary sources, rates the flaw critical at 9.3 and says a remote attacker could perform file operations on an affected appliance. Affected self-hosted versions run up to 26.2.3, and BeyondTrust's software-as-a-service instances were patched on 9 October, so SaaS customers need take no action. Self-hosted customers need the BT26-05 patch; Google's write-up says those on versions older than 24.3.1 must upgrade first. A companion advisory covers Privileged Remote Access. We could not open BeyondTrust's own advisory page, so check it for the exact fixed versions.

Google and Mandiant describe the flaw as an unauthenticated arbitrary file upload. Reuters syndications relay the same account: exploitation in August, before disclosure, with a webshell Google calls SAWFLY and a tunneller it calls BARECLAW.

What Google and Mandiant say the actor did

Foothold. A staged file upload, then a custom PHP webshell with encrypted command-and-control.
Privilege. Escalation from a service account to root through a copy of the shell with the set-user-ID bit.
Credentials. The appliance's credential vault was dumped using its own command-line tool for secrets.
Persistence. Passwordless sudo was added through a configuration template and re-applied at boot.
Cover. Appliance, web and application logs were deleted.
Spreading. Using a compromised administrator account, the actor raised Jump Item and Team roles to Administrator and ran remote sessions and file transfers to internal endpoints, with a tunneller exposed through modified reverse-proxy routing.

These details come from Google's own report on intrusions it investigated. We have not seen them independently reproduced.

What is not known

How many organisations were hit and which sectors. Google's post names none, and notes the group has historically targeted a wide range of countries and industries.
What was taken. The post says the vault was dumped in the cases examined. It does not give a count of credentials or say what they reached.
The staging file. Mandiant could not recover it, and customers cannot audit the appliance host's filesystem, which limits what anyone can prove about an individual appliance.
Attribution strength. Google calls the actor a suspected PRC-nexus group because its tooling and techniques match earlier activity, not because of a confirmed identity.
Whether CISA lists it. We did not see a known-exploited entry for this flaw. The BeyondTrust advisory wording we saw does not mention exploitation, though Google's report postdates it.

Google also expects wider opportunistic exploitation now that the flaw is public, based on earlier campaigns by the same group.

Why the vault changes the response

Remote support and privileged access tools are built to hold credentials: for the systems engineers connect to, for the service accounts that connect them and for the integrations around them. If the appliance vault was dumped, those are the secrets to replace. The list depends on how you use the product, which is exactly why you should write it down before an incident, not after.

The second concern is what the actor did with its administrator access. Raising roles and running sessions to internal endpoints means the compromise can reach beyond the appliance into systems that trusted it.

A response order, following Google's guidance

Treat exposed, vulnerable appliances as possibly compromised. If a self-hosted Remote Support appliance was reachable from the internet and unpatched during the window, assume the worst until you can show otherwise.
Preserve first. Snapshot the appliance and collect logs held outside it, such as the reverse proxy, web application firewall and firewall, before you change anything. The actor deleted local logs.
Close the door. Block public access at the perimeter and apply the BT26-05 patch, upgrading first if you are below 24.3.1. If compromise is suspected, rebuild from a clean image rather than patching in place.
Rotate after patching or rebuilding, in dependency order. Google says to rotate only afterwards, so you do not hand fresh secrets to an intruder who is still present. Start with the appliance's administrator and API accounts, then the credentials stored in the vault, then those of the systems reached by support sessions.
Audit the appliance's own state. Review user and role changes, API accounts, security providers and outbound log destinations, and review file transfers during support sessions. Look for roles raised to Administrator.
Hunt for the quiet traces. Google suggests looking for requests to unexpected PHP paths, WebSocket upgrades from unknown sources, role-change events and gaps in log forwarding.
Harden the rebuilt system. Enforce single sign-on with phishing-resistant multi-factor authentication, default the Jump Item role to no access and restrict the administration interface by address.

The handover that cannot go wrong

A rotation like this produces dozens of new credentials that must reach the engineers who install them, often across teams and time zones during an incident. If the support tool is itself the suspect, nothing about the replacement values should travel through it, or through the chat that the same administrators monitor. Send each value once, to the one person who needs it, over a channel that does not keep it.

Where Secretus fits, and where it does not

Secretus covers that handover: a person encrypts a short text secret in the browser and shares a link that stops working after the expiry they set or the first successful open. Team Split can require several holders to reconstruct a high-value text secret, such as a break-glass administrator password.

It is not a privileged access management product. It cannot patch the appliance, inspect its vault, rotate credentials on your systems or tell you whether you were compromised. Use BeyondTrust's guidance, Mandiant's hunting advice and your own tooling for that, and a one-time link for the moment one person gives another a new credential.