BeyondTrust CVE-2026-102764: NC Plant Vendor Access Check

You may not own a BeyondTrust appliance. The question is whether someone who supports your plant does.

TL;DR: CVE-2026-102764 is an authentication bypass in BeyondTrust Remote Support, version 26.2.3 and earlier, and CISA added it to the Known Exploited Vulnerabilities catalog on October 16, 2026. Google's threat intelligence team says a suspected PRC-nexus espionage threat actor exploited it as a zero-day in late August 2026. If an IT provider, machine builder or software vendor reaches your computers through BeyondTrust, ask them in writing this week whether the patch is on, whether anyone has checked for an earlier break-in, and which of your passwords their tool holds.

As of October 24, 2026: BeyondTrust's advisory, BT26-05, is the document to hold your vendor to. CISA's deadline for federal agencies, October 19, has passed.

Does a vendor reach my plant through BeyondTrust?

Only your vendors can tell you for certain, so ask each one in writing. BeyondTrust Remote Support was formerly Bomgar, and Google describes it as a tool that lets IT teams reach and troubleshoot remote computers. The Canadian Centre for Cyber Security's October 16 alert tells organizations to find their deployments and work out whether each is SaaS-hosted or self-hosted. For you, the deployment usually belongs to the vendor, so that is the question you put to them.

Send it to everyone with standing remote access. On a plant floor that list is longer than the front office thinks: the managed IT provider and the ERP reseller, yes, but also the integrator who programs your PLCs and the machine builder who dials into the PC beside a press or a CNC when it faults at 2 a.m. Ask each one:

1. Do you use BeyondTrust Remote Support, BeyondTrust Privileged Remote Access, or Bomgar to reach any of our computers?
2. Is it BeyondTrust's cloud (SaaS), or an appliance you run yourselves?
3. Which version is it on, and is the BT26-05 patch on it?

You can check a few machines yourself while you wait. Look under installed programs on a front-office PC and on any HMI or engineering PC that a vendor supports, for anything named BeyondTrust or Bomgar. An empty result proves little, since the one machine you skipped may be the one with the client on it; a hit tells you which vendor to call first.

If you would rather hand the list to someone, a North Carolina plant can call Preferred Data Corporation at (336) 886-3282.

Our recommendation: do not build this list from memory. Check it against purchase records, firewall rules and the remote access tools installed on your PCs, and look hardest for the machine builder or software reseller who may have been given standing access years ago and never removed.

What is CVE-2026-102764, and how serious is it?

It lets an attacker who has not logged in perform file operations on the appliance, which Google says can lead to host-level control. BeyondTrust's CVE record says internal Remote Support components "did not adequately validate the origin of the messages it received," and lists Remote Support 26.2.3 and earlier as affected. BeyondTrust scores it 9.3 of 10 under CVSS 4.0. NVD scores it 9.8 under CVSS 3.1.

The CISA KEV catalog entry was added October 16, 2026, gave federal agencies until October 19, and marks forensic triage as required, pointing agencies to CISA's forensics triage requirements on top of the patch.

Google Threat Intelligence Group's October 15 report says Mandiant found evidence, during an incident response engagement, that ARMORY CASTLE, "a suspected PRC-nexus espionage threat actor," exploited the flaw "as a zero-day, in late August 2026." Google warns that the group and other actors have historically followed disclosure with "broad, opportunistic exploitation."

On Privileged Remote Access, BeyondTrust told customers, as quoted by BleepingComputer on October 16, that its testing "has not identified any way for an attacker to exploit this vulnerability" there, but "PRA shares the affected code."

Not sure which of your vendors use remote support tools? Preferred Data Corporation's cybersecurity team can work through the vendor list with you this week. Call (336) 886-3282.

What did the attackers do once they were on the appliance?

They used it as a key ring. In the intrusion Google describes, the attacker planted a web shell, made itself root on the appliance, and tried to dump the appliance's built-in credential vault. Google says root gave "access to every credential the appliance stored or brokered." The attacker then logged in to the admin portal with a compromised administrator account, raised that account's Jump Item and Team permissions from No Access to Administrator, and opened a remote support session to internal endpoints. From there it used the tool's own file transfer to take documents such as software inventories off a user's desktop.

It also deleted logs throughout the incident, and Google says its persistence survives "system reboots and configuration resets."

Now apply it to your plant. A vendor's appliance holds the list of machines it can reach and often the passwords to get in. If your machines are on that list, they are among the endpoints an attacker on the appliance can open a session to. That is our reading of Google's account, not a claim that any named vendor or customer was hit.

Key takeaway: A patch closes the hole. It says nothing about whether someone came through it before the fix, and your passwords may have been on the box the whole time.

What should I demand from the vendor, and by when?

Ask for written answers within one business day, and a named person who owns the follow-up. That deadline is our advice, not CISA's, and the federal date has passed. A vendor that needs more than a day to say which version it runs probably does not track its own tools, which is worth knowing before the contract renews.

Put these in the email. The window is our suggestion: from late August, the earliest exploitation Google reports, to today.

• [ ] The product, hosting model (SaaS or self-hosted) and version, and the date BT26-05 went on.
• [ ] Whether the appliance was reachable from the internet on a vulnerable version during that window. Google says any such appliance "should be treated as potentially compromised until it has been reviewed."
• [ ] Who did that review, what it found, and whether evidence was kept before any patching or rebuild.
• [ ] Which of our systems sit on your appliance, and which of our passwords or keys it stores.
• [ ] A list of every support session to our machines since late August, with any file transfers. Google tells appliance owners to review session reports "including file transfers" and treats every endpoint touched as in scope.
• [ ] Confirmation that credentials for our systems will be rotated once the appliance is patched or rebuilt.

A vendor that answers "we use the cloud version, so we are fine" is partly right. The Canadian Cyber Centre says SaaS customers need no further action to remediate the flaw. Google goes further and says the credential and configuration steps still apply to SaaS customers. Our advice is to ask the vendor whether it did that review anyway, because the patch only stopped new break-ins from October 9.

If your managed IT provider is the one using BeyondTrust, the same list applies. Being your IT company does not exempt them from answering in writing.

What if the vendor's appliance may already be compromised?

Then the order matters: contain, preserve, then change the box. If nothing points to a break-in, patching first is correct, and it is the option Mandiant marks as recommended. Once a vendor says "possible compromise," the steps below apply. They are our ordering of Google's Mandiant guidance, and most of them are the vendor's to do.

Steps for the appliance owner (your vendor):

1. Contain at the perimeter. Block inbound traffic to the appliance's public address at the firewall, rather than inside the appliance, so its configuration stays intact for review. Deny outbound traffic except to BeyondTrust's update and licensing endpoints, and log what is denied.
2. Preserve before changing anything. For a virtual appliance, snapshot it with memory and export the disk before any change or reboot. For B Series hardware or a SaaS tenant, request forensic preservation through BeyondTrust Support. Collect syslog, proxy or WAF logs and firewall logs for the whole exposure window, because the attacker deleted logs on the appliance. Our addition: leave the appliance powered on.
3. Call the insurer and an incident responder before anything is rebuilt.
4. Disable, do not delete. End active sessions and disable new sessions, Jump Clients, Jumpoints and API accounts, so the audit trail survives.
5. Rebuild rather than clean. Google says customers cannot audit the appliance's host file system, so an appliance with confirmed or unknown compromise status is redeployed from a clean, fully patched image, with a new TLS certificate.
6. Rotate credentials after the patch or rebuild, not before. Google is explicit: rotating earlier exposes the new passwords to an attacker who still controls the appliance.

Steps for you:

1. Cut the path, and leave the machines on. If the vendor runs its own appliance, ask for its address and block your network from reaching it at your own firewall. If the vendor uses BeyondTrust's cloud, the address may be shared with other customers, so ask the vendor to disable access to your machines from its side instead. Do not uninstall the vendor's software from your PCs: that destroys evidence your responder may need. Disconnect a PC from the network if it looks wrong. Do not unplug it. If that PC runs a machine, have the integrator or a lead operator bring the line to a safe stop first.
2. Call your cyber insurer before you pay anyone to rebuild a machine.
3. Have your incident responder examine every machine on the vendor's session list before it is reimaged, starting with any that had file transfers.
4. Change the passwords the vendor's tool stored, once the vendor confirms its appliance is patched or rebuilt. Google says vault credentials are "rotated at the target system," which means on your server or device, not in the vendor's tool. Include any password typed during a support session since late August.

Indicators. This part is for your vendor or responder. Google's report publishes three file indicators, listed below. Treat it as a sample: Google says it has also put indicators in a collection for registered users. These files sit on the appliance, not on your PCs.

Google also names /usr/bin/dbus-authd, a post-boot script named zz-root-persist, and an added /uidchanarge route in the appliance's HAProxy configuration. Our advice: a clean check for these does not clear an appliance.

What should a Piedmont Triad plant do on Monday?

Send the email from the first section to every vendor with remote access before lunch, and put the replies in one folder. Then decide whether each vendor really needs standing access to your plant. In our view, access somebody has to approve each time is a smaller target than access that is always on. Expect pushback from the line: a machine builder who has to wait for approval at 2 a.m. costs you uptime. Agree a named approver on each shift before you switch it on. If the vendor list itself is the problem, that is ordinary network and vendor-access work.

Preferred Data Corporation has supported manufacturers since 1987. We are headquartered in High Point, NC, work on site within 200 miles, and support clients remotely across the US and around the world. Call (336) 886-3282 or email [email protected].

Frequently Asked Questions

Is BeyondTrust Privileged Remote Access affected by CVE-2026-102764?

In a statement quoted by BleepingComputer, BeyondTrust said its internal testing has not found a way to exploit the flaw in Privileged Remote Access, but the product shares the affected code. It said it released a patch and recommends self-hosted PRA customers apply it immediately. The Canadian Cyber Centre says PRA SaaS was patched as of October 9, 2026. Ask your vendor to confirm the patch is on.

We do not use BeyondTrust. Does this matter to us?

It matters if any vendor uses it to reach you, which only they can confirm. Ask each one with standing access. If none does, keep the replies: the same questions apply to every remote support tool.

Our vendor uses the BeyondTrust cloud. Are we done?

Not necessarily. Google and the Canadian Cyber Centre say BeyondTrust patched SaaS tenants as of October 9, 2026, and the Cyber Centre says SaaS customers need no further action to remediate the flaw. The patch does not undo anything that happened before it, and Google says the credential and configuration review still applies to SaaS. Ask whether the vendor did that review and what it covered.

Who attacked these appliances?

Google Threat Intelligence Group attributes the zero-day exploitation to ARMORY CASTLE, which it calls a suspected PRC-nexus espionage actor formerly tracked as UNC5221. Google tells organizations to prepare for possible widespread exploitation now the flaw is public.

Does patching remove an attacker who is already in?

No. Google says upgrading "does not remediate prior exposure," and the persistence it found survives reboots and configuration resets. That is why it recommends rebuilding an appliance with confirmed or unknown compromise status.

Should we make our IT provider stop using remote support tools?

In our view, no. For most North Carolina plants it is how outside help arrives, and taking it away means slower fixes. Ask instead for approval before each session, multi-factor login for every technician, and a session log you can see.

Related Resources

• ScreenConnect CVE-2026-84869: Worm-Like NC Endpoint Alert, the sibling remote support risk on your own PCs.
• Your Machine Builder Is a Target: NC Plant Playbook, on integrator and machine builder access.
• MSP Remote Tools Hacked Again: NC Business Guide 2026, on questions for your IT provider.
• China-Linked Hacker Advisory: What an NC Plant Should Check.