Counting BeyondTrust Remote Support appliances before patching CVE-2026-102764
Patch instructions are only useful if you know which machines they apply to. CVE-2026-102764, an authentication bypass by spoofing rated 9.8 under CVSS 3.1 and added to the CISA KEV catalog on 16 October 2026, affects BeyondTrust Remote Support through 26.2.3. Remote support appliances tend to be few, well known to the team that runs them, and invisible to everyone else. An outside view helps find the ones nobody listed.
What the fingerprint data shows
Four queries run on 17 October 2026 against ZoomEye returned different pictures of the same product family.
- app="Bomgar" returned 2,184 deployments. Bomgar is the former name of Remote Support, and the application fingerprint still carries it.
- title="BeyondTrust" returned 962 deployments whose page titles mention the vendor, a broader set that may include other BeyondTrust products.
- product="BeyondTrust" returned 1.
- app="BeyondTrust Remote Support" returned 0, and vul.cve="CVE-2026-102764" returned 0. The zero for vul.cve is expected. Vendor and CVE fingerprinting trails disclosure by days or weeks, so an empty result says the index has not caught up. It says nothing about how many appliances are exposed. The difference between 2,184 and 962 also needs care: the app fingerprint is the narrower, more deliberate signal for this product, while a title match can catch login pages, documentation portals or unrelated appliances carrying the vendor name. The search used for the app query is reproducible: https://www.zoomeye.ai/searchResult?q=YXBwPSJCb21nYXIi
Why appliance inventory is harder than server inventory
Remote support platforms are installed by the team that needs them. A subsidiary support desk, a lab, or an acquired business unit can run an appliance for years without it appearing in a central configuration database. The appliance then answers on 443 and looks like any other web service to a vulnerability scanner that lacks a product fingerprint.
External fingerprinting does not replace asset management. It provides an independent list to reconcile against the one you maintain. Where the two lists disagree, the gap is the interesting part. A host in the outside list with no internal owner is either decommissioned and still listening or unmanaged and still listening, and both cases call for the same next step.
Turning counts into decisions
Treat each external match as a claim to verify locally, not as a finding. Check the version string, then check whether it is below or above 26.2.3. Appliances older than 24.3.1 fall outside patchable support branches, so the immediate action is an upgrade rather than a patch, which usually needs a maintenance window and a rollback plan.
Sort what remains by who can reach it. An appliance published to the internet carries a different risk from one reachable only from a management VLAN, even when both run the same build. CISA guidance for this CVE points in the same direction, asking operators to limit external access to the services that support users and to keep administrative interfaces on trusted networks. Exposure reduction buys time when a patching window is days away.
Limits of the evidence
The counts above describe deployments that matched a product fingerprint. They do not prove vulnerable versions, they do not prove exploitation, and they say nothing about hosts that hide behind authentication prompts or sit on networks the crawler cannot reach. Internal scanning sees a different and often larger population. Use the external number to challenge the internal one, then rely on authenticated inventory for the patching decision.
Next steps
Reconcile your appliance list against external fingerprint data, confirm versions on every self-hosted instance, and apply BT26-05-RS where supported. Upgrade the older builds first, because they cannot take the patch. Record the date each instance was confirmed patched. When the next KEV entry arrives with a three-day deadline, that record is what turns a scramble into a checklist.
