FortiSIEM CVE-2026-106173 is reachable through a gRPC service on TCP port 27918 using a path traversal that makes no authentication demand. The exposure question that follows is whether that port answers on the internet, and the measurement question is whether ZoomEye can be used to find out.
ZoomEye queries for this article could not be completed: the API returned HTTP 502 throughout the research window. The query designs below are reproducible and carry no result counts, because reporting a count that was never retrieved would be fabrication.
Port queries are the strongest and weakest evidence at once
port=27918 is unambiguous about one thing: something answered a TCP handshake on that number. ZoomEye associates services with ports and protocols, and a bare port query does not require the service to have been identified as FortiSIEM.
That property cuts both ways. A port query will not miss an instance because its banner changed, and it will also not distinguish a FortiSIEM appliance from a load balancer, a honeypot, or an unrelated service that happens to listen on the same number.
The tighter version combines the port with product identity:
port=27918 && app="FortiSIEM"
port=27918 && product="Fortinet"
Neither will find every exposed instance, because the service may not volunteer an identifying banner within the collection window. It will find the subset that does, which is a defensible denominator when described honestly.
The distinction that matters for this CVE
FortiSIEM is a management platform. In a correctly segmented network, port 27918 is reachable from other FortiSIEM components and from nothing else. Its appearance on an internet-facing address is therefore a configuration finding independent of the vulnerability.
That reframing changes what the measurement is for. The question is not "how many FortiSIEM installations exist" but "are there FortiSIEM installations whose management plane is reachable from untrusted networks". The first is an inventory problem, the second is a control failure, and only the second one makes CVE-2026-106173 an emergency for a specific organisation.
Reading results with the segmentation in mind
When a query does return assets, the useful next step is geolocation and network attribution rather than the raw count. country, org and isp fields let you separate consumer broadband addresses from cloud hosting and from enterprise ranges. A FortiSIEM management port answering from a consumer connection is a very different finding from the same port answering from a hosting provider.
The same logic applies to the rest of the Fortinet estate. FortiSIEM rarely sits alone; organisations running it typically run FortiManager, FortiAnalyzer and FortiGate devices. A query design that maps the whole management plane is more useful than one that counts a single product:
app="FortiSIEM" || app="FortiManager" || app="FortiAnalyzer"
product="Fortinet" && port=443
The union describes management-plane reachability. Whether each member of that union needs to be reachable from the internet is a policy question the measurement cannot answer.
Limits worth stating up front
A port-based query cannot distinguish a patched appliance from an unpatched one. CVE-2026-106173 affects FortiSIEM 7.5.0 only, with 7.5.1 fixing it and 7.6 unaffected, so an exposed instance is a lead rather than a confirmed finding.
ZoomEye collection is a sample of what responded during the scan window. Assets behind a proxy that returns a generic error, or appliances that only accept connections from allow-listed addresses, will not appear. Every internet-wide count understates the true population of reachable devices by an unknown amount, and the honest phrasing is "at least these were visible", not "these are all that exist".
References
Fortinet advisory FG-IR-26-180 for CVE-2026-106173, including the TCP 27918 gRPC service
Horizon3.ai technical analysis, 20 October 2026
NVD entry for CVE-2026-106173, CVSS v3.1 9.8
ZoomEye official MCP search syntax reference for
port,app,product,country,organdisp