CVE-2026-102764: BeyondTrust Remote Support Auth Bypass

CISA added CVE-2026-102764 to its Known Exploited Vulnerabilities catalog on 2026-10-16, and the entry is short enough to read twice: BeyondTrust Remote Support contains an authentication bypass by spoofing vulnerability that could allow a remote attacker to perform file operations on the appliance. What is affected is your Remote Support appliance, specifically any instance an attacker can reach over the network. What fixes it is the mitigation set in BeyondTrust's own instructions, applied in line with CISA's required action — and the remediation due date of 2026-10-19 has already passed, so this is catch-up work, not forward planning. The catalog was at version 2026.10.26 when the entry was published.

What CVE-2026-102764 actually is

It is an authentication bypass in BeyondTrust Remote Support that lets a remote attacker spoof their way past authentication and then perform file operations on the appliance. That sentence is the entire public description, and it is worth noticing what it leaves out: it does not name the files touched, the privilege level reached, or the interface involved, and the advisory does not specify them. Two other details matter. First, the entry is in KEV, which means CISA has grounds to treat the flaw as exploited rather than theoretical. Second, "known ransomware campaign use" is listed as Unknown — that is an absence of attribution, not a clean bill of health.

Am I affected by CVE-2026-102764 in BeyondTrust Remote Support?

If you run a Remote Support appliance that answers from the public internet, assume you are affected until you have confirmed the build on every node. These appliances live in an awkward spot: they are internet-facing by design, frequently installed and maintained by an MSP or an outsourced IT partner, and usually carry a standing firewall exception nobody has revisited. CISA's required action puts that judgement on you — stakeholders are responsible for evaluating each asset's internet exposure. So the first task is not patching, it is a list: every Remote Support instance, its owner, and whether it is genuinely reachable from outside your network.

The next 24 hours: patch, verify, then watch

Apply the vendor mitigations today, then prove which build is answering on the wire — a change ticket saying "patched" is not evidence. Concretely, this is the sequence we would run:

• Apply mitigations in accordance with the vendor instructions, which is CISA's stated required action. Follow applicable BOD 26-04 guidance for cloud services, or discontinue use of the product if mitigations are unavailable for your deployment.
• Verify the version actually serving traffic: read the build string in the admin console after the restart, hit the internet-facing endpoint from outside and confirm it reports the same build, and repeat behind the load balancer for every node.
• Sweep for the instances nobody owns — the DR copy, the lab box, the staging appliance the MSP set up and never decommissioned.
• Preserve logs before you reboot anything. CISA's action references its Forensics Triage Requirements, and a restart can cost you the evidence you would want later.
• Treat the deadline as blown rather than pending: 2026-10-19 has passed, so any exposure since then is unexplained until your logs say otherwise.

What to watch in the appliance logs

Look for authenticated activity with no plausible authentication behind it, and for file operations you cannot attribute to a named person. Because the flaw is a bypass by spoofing, the tell is usually absence rather than noise: a session that starts with no preceding credential exchange, no MFA prompt where your policy demands one, or a source address that does not match how that account normally connects. Pull file-transfer and audit records alongside the access log — a file operation is the outcome the description warns about. Ship appliance logs off the box to your central store now, not after an incident review makes it urgent. If your team needs help with the plumbing, our notes on self-hosted infrastructure cover the basics.

What AI changes about a bug like this

AI did not necessarily find this bug — the facts do not say who did — but it changes how fast you can scope and check it. Two uses hold up in practice. One is review: an AI-assisted pass over authentication paths is decent at flagging the shape of this defect, a decision made about identity without a check in front of it, even when it cannot tell you whether the path is reachable. The other is triage: pointing a model at your appliance inventory, vendor bulletin and firewall rules to produce a verification checklist you can hand to whoever owns the box. What AI will not do is know your estate. It cannot tell you that a node exists, that it is exposed, or that it is running the build you think it is. Treat its output as a faster first draft of the questions, and keep the confirmation human.

Where to start

Start with the list, not the patch: every Remote Support instance, who owns it, and whether it is reachable from outside. Then apply the vendor mitigations, verify the build on each node from outside the network, and keep the logs. If you want a second pair of hands on the exposure inventory or the architecture review around it, that is the kind of work we do at Maysan Labs.