Remote support appliances: the exposure you can see is the login page, not the patch level

BeyondTrust Remote Support carries CVE-2026-102764, scored 9.3 under CVSS v4.0. The weakness is insufficient validation of message origin, and the documented impact is file operations on the appliance itself. That combination matters because a remote support appliance is, by design, reachable from outside the network and trusted by everything inside it.
ZoomEye was not queryable for this article: the API returned HTTP 502 across the research window, and no counts are reported. What follows is the measurement design, which for this product class turns out to be more informative than a number.

What an internet scan actually sees

A remote support appliance presents a login page, a set of fixed administrative paths, and a TLS certificate. Each of those is a fingerprintable property. None of them is the firmware version.
The distinction is not academic. BeyondTrust publishes appliance updates through its own channel, and the version is frequently visible only after authentication or through a version endpoint that many deployments restrict. So a scan can confirm that a BeyondTrust appliance is on the internet at a given organisation, and it cannot confirm whether it has been updated.
That gap sets the practical value of measurement here. The scan answers "who has one of these exposed", which is a governance question. The patch question has to be answered by the appliance owner.

Query construction

Product-name queries are the primary tool, and the product has a long naming history that fragments the population:

app="BeyondTrust"
app="Bomgar"
title="Remote Support"
title="BeyondTrust Remote Support"

Bomgar is the former name, and a substantial number of deployments still carry the branding in page titles and certificate subjects. Querying only the current name undercounts the estate by an amount that is large enough to change conclusions about a sector.
Certificate evidence is often cleaner than page evidence:

ssl.cert.subject.cn="*bomgar*"
ssl.cert.subject.cn="*beyondtrust*"

Certificates persist across web front-end redesigns, which makes the certificate angle the more stable of the two. It also produces the occasional finding where the page has been rebranded and the certificate has not.
Administrative paths are worth knowing but should not be relied upon as the whole query:

title="BeyondTrust" && port=443
app="Bomgar" && country="US"

The second example illustrates a normal analytical use: partitioning by country or by hosting organisation to separate self-hosted enterprise appliances from vendor-hosted instances, which should be excluded from a count of customer exposure.

What to do with the result

Three outputs are worth producing, and only one of them is a number.
The asset list, first. Every appliance found should map to a named owner. An unmatched appliance is a finding regardless of version.
The second is a hosting distinction. An appliance in a corporate ASN is a different risk profile from one in a shared hosting provider, and appliance vendors do not generally support the latter.
The third is the trend. A count that holds steady while an organisation's cloud migration proceeds suggests the appliance is not being maintained as part of the migration, which is how forgotten appliances accumulate.
The number itself, for reasons above, describes the login pages that are reachable. Reporting it as "exposed installations of a 9.3 vulnerability" is inaccurate and will be challenged by anyone who understands the product.

The control that actually reduces the number

Restricting appliance access to known source addresses, or placing it behind a VPN with device posture checks, removes it from an unauthenticated scan entirely. Vendors of remote support products generally document this as an option, because the appliance is designed to be reachable and therefore needs to be constrained by policy.
That constraint is measurable in one narrow way: the appliance either answers from the public internet or it does not. It is the single most useful binary in this product category, and it is the one thing ZoomEye can tell you with confidence.

References

• NVD entry for CVE-2026-102764, CVSS v4.0 9.3, insufficient validation of message origin with file-operation impact
• BeyondTrust security advisory for CVE-2026-102764
• ZoomEye official MCP search syntax reference for app, title, ssl.cert.subject.cn, port and country