1,807 Gateways, 1,161 on 443, Zero CVE Matches: Scoping Cisco SEG Exposure

CVE-2026-76519 has a CVSS of 9.8, a CISA KEV entry, and confirmed exploitation. In the ZoomEye index the CVE dork returns nothing. Both facts are true, and the distance between them is the methodological argument of this piece.

Context and method

Counts from the ZoomEye index, 23 October 2026, sub_type=all, pagesize=1, page 1. Fingerprint matches, not installations, and not statements about the Content Scanner Tools version.

The application fingerprint finds 1,807 hosts. Scoping to 443 leaves 1,161, so 646 matches answer on a port other than 443. The CVE dork returns nothing at all, on a vulnerability that sits on the KEV list.

Why the CVE count is zero and the risk is not

vul.cve correlates identifiers against version data the index has already parsed. Vendors of email security appliances generally do not publish a version string on an unauthenticated page. Without a version there is nothing for the correlation to attach a CVE to, so a perfectly indexed host running a vulnerable Content Scanner Tools build produces no CVE match.

That is the general case rather than an exception. Appliance-style products hide their versions precisely because exposing them aids reconnaissance. The index cannot correlate what it cannot see, and a missing correlation is not a missing vulnerability.

For this CVE there is a second reason the vulnerable population is narrow: exposure requires File Reputation enabled and Content Scanner Tools older than 25.3.0.5525. A gateway without File Reputation enabled is not vulnerable, and it is also not distinguishable from a vulnerable one by any external query.

What the port split tells you

The 646 matches that do not answer on 443 are the interesting subset. Email gateways present management and mail interfaces differently, and a gateway whose management plane answers on a non-standard port has survived whatever firewall review was applied to 443.

The reverse reading holds too. Of the 1,161 on 443, some proportion sit behind a reverse proxy or load balancer that terminates TLS, so the index measures the proxy rather than the appliance. Neither number counts exploitable hosts.

Reading a mail gateway count in context

1,807 is small by the standards of this series. Set it against 419,779 n8n fingerprints or 5,623,921 MQTT services and it looks manageable. That comparison is the point: a mail gateway is a high-value target with a small internet population, which makes it the kind of asset where complete inventory is achievable and therefore hard to excuse skipping.

A scoped verification plan

1. Query both the app and the app-plus-port dorks against your own address space. Any host appearing in the first but not the second has its management plane somewhere a port-443 review would not have looked.
2. Do not rely on the CVE dork for appliances. Retrieve versions from the appliances themselves, and check both the AsyncOS build and the Content Scanner Tools build, because the exposure lives in the second.
3. Establish whether File Reputation is enabled. That single setting decides whether the CVE reaches the host at all.
4. If File Reputation must stay on and the scanner tools cannot be updated yet, remove untrusted senders' ability to reach the content scanner. No vendor workaround exists, so the control has to come from upstream.
5. Re-run the app dork quarterly and treat any change as a deployment event worth explaining.

The methodological conclusion

A zero on a CVE dork is evidence about the index's version visibility and nothing else. Quoting it as reassurance in a report about a KEV-listed vulnerability is the specific error this piece exists to prevent. The number to trust is the one collected from the appliance.

References

• ZoomEye search: https://www.zoomeye.org/
• Cisco advisory cisco-sa-esa-afw-zqYJkjxp for CVE-2026-76519