Three ZoomEye queries from 23 October 2026, read together, describe why log collection is hard to measure from outside.app="FortiAnalyzer" returned 14,860 matches. app="FortiAnalyzer" && service="ssl" returned 0. port=514 returned 994,157, and port=6514 returned 1.
Forty-nine of the fifty or so lines in this article are about what those numbers do not say. The four that matter are about what they do.
Port 514 is syslog, not FortiAnalyzer
The port query is the least useful of the four and the one most likely to be quoted. Unix syslog has used 514 since the 1980s, and every syslog-emitting device on the internet contributes to that count: routers, switches, firewalls, Linux hosts, printers, and a great deal of consumer equipment that was never intended to be reachable.
A count of 994,157 hosts answering on 514 is a count of hosts that answered on 514. It cannot be filtered into a product population, and pairing it with a vendor name in a report produces a number that is wrong by an unknown factor.
Port 6514, the TLS syslog port defined in RFC 5425, returned a single match. That is not evidence that almost nobody secures syslog transport. It is evidence that a TLS listener on a non-standard port does not answer a plain probe in a fingerprintable way, which is what TLS is for.
The zero on TLS is the interesting figure
app="FortiAnalyzer" && service="ssl" returning zero while the base application fingerprint returns 14,860 describes a real property of the identified population: none of those hosts presented a TLS service fingerprint that the scanner associated with the application match.
Two readings are possible and they lead to different follow-up work. Either the console is reached over plain HTTP in the identified population, or TLS is terminated at a proxy and the application fingerprint comes from the backend response rather than the TLS handshake. Distinguishing them requires inspecting individual hosts, which is precisely the step a count cannot replace.
What FortiAnalyzer collects and why that matters
A FortiAnalyzer appliance aggregates logs from FortiGate firewalls and other Fortinet devices. It holds traffic logs, security events, and configuration records for the estate it monitors. Its own vulnerabilities are therefore relevant to the integrity of that record.
On 13 October 2026, Fortinet published advisories for multiple SQL injection defects affecting FortiAnalyzer and FortiManager, tracked as CVE-2026-23705 (7.2), CVE-2026-23706 (6.5) and CVE-2026-23707 (7.2), along with CVE-2025-46773 (8.8). All four describe a low-privileged user able to execute arbitrary commands through crafted requests, and the advisories list affected branches from 7.2 through 7.6, with cloud variants in the same bulletins.
A separate path traversal in FortiSIEM, CVE-2026-106173, is rated 9.8 and described as allowing unauthorised code or command execution through specially crafted packets.
The common thread for an operator is that the appliance holding the security record is itself software that needs patching on its own schedule. Where the log store is treated as infrastructure rather than as an application, its patch cycle tends to lag.
Verification that produces an auditable answer
Version first. The FortiAnalyzer GUI reports the firmware build, and Fortinet's release notes map builds to advisory ranges. The check that matters is whether a specific build string appears in the advisory's affected list, not whether the appliance is "current" in a general sense.
Reachability second. Query your own netblocks for the appliance's management interface and record what answers. The management plane of a log collector should be reachable from the administrative network only, and the measurement is a way to confirm the firewall rule matches the intent.
Transport third. Confirm whether log ingestion is on 514, 6514, or an IPsec tunnel, and whether the source address is restricted. A collector that accepts syslog from any source accepts forged events from any source, which turns a patch management problem into a data integrity problem.
Retention fourth. FortiAnalyzer's analytics retain logs for a configured window, and the window depends on licences and disk. A retention window shorter than the incident's discovery time produces the same outcome as no log at all.
The question to ask about the record
The comparison worth running this quarter is between the collector's retention and the organisation's detection latency. If the median time from compromise to discovery exceeds the analytic retention window, the appliance cannot answer the question it exists to answer.
That is a measurable gap, and it is unaffected by any of the counts above.
References
Fortinet PSIRT advisory FG-IR-26-178: https://fortiguard.fortinet.com/psirt/FG-IR-26-178
Fortinet PSIRT advisory FG-IR-25-246: https://fortiguard.fortinet.com/psirt/FG-IR-25-246
Fortinet FortiAnalyzer documentation: https://docs.fortinet.com/product/fortianalyzer
RFC 5425, Transport Layer Security for Syslog: https://www.rfc-editor.org/rfc/rfc5425
ZoomEye query syntax reference: https://www.zoomeye.org/doc
NVD records: https://nvd.nist.gov/vuln/detail/CVE-2026-23705, https://nvd.nist.gov/vuln/detail/CVE-2026-106173
Measurement note: counts collected 23 October 2026 with
app="FortiAnalyzer"(14,860),app="FortiAnalyzer" && service="ssl"(0),port=514(994,157),port=6514(1).