Zero Results for a CVSS 8.8 Bug: Reading the Argo CD CVE Dork That Returned Nothing

A query for a CVE with a public advisory and a CVSS score of 8.8 returns zero. That number reads like good news. It is not news at all, and understanding why separates an asset inventory from a false sense of coverage.

Context and method

Every figure here comes from the ZoomEye index, collected on 23 October 2026. Each query ran against the API with sub_type=all, pagesize=1, page 1, and the totals are what the index reported for that exact string.

One caveat governs the rest: a ZoomEye total counts fingerprint matches across the index. It is not a count of installations, and it says nothing about which of those hosts are exploitable.

The two application queries agree exactly at 62,245. The port-scoped variant drops to 25,097, which leaves 37,148 fingerprint matches that are not serving on 443. The CVE query returns nothing.

What the zero actually means

The vul.cve field is populated by correlating known CVE identifiers against version and banner data the index has already parsed. A CVE published recently, whose affected versions are not yet mapped to a fingerprint rule, produces zero results even when every host in the index runs a vulnerable build.

So the zero describes the index, not your exposure. Reading it as an all-clear inverts the meaning of the evidence.

The second thing to notice is that app and title return the same total. When two fingerprint dimensions land on an identical number, the rule building the app field is very likely derived from the same page title the title query matches. Agreement of that kind is evidence about how the index classifies the software, not independent confirmation that 62,245 installations exist.

Why the port split matters more than the total

GitOps controllers are management planes. They hold repository credentials, cluster credentials, and the ability to change what runs in production. The number that matters for triage is not how many controllers exist but how many are reachable from outside the network they administer.

The port-scoped query comes closest to that question. It reports 25,097 matches on 443 and says nothing about which of them sit behind a load balancer, a VPN, or an SSO proxy, so the genuinely internet-facing population is smaller than the port count and unknowable from outside.

A defensible reading: 25,097 matches have a TLS listener in front of the application fingerprint, and the remainder are on a non-standard port, behind a proxy that terminates TLS elsewhere, or not exposing a listener the scanner could complete a handshake with.

Using this in an inventory

ZoomEye earns its place here through the negative evidence it provides. If your asset register claims a controller count in the low dozens and a region-scoped index shows a much larger population, that gap identifies which teams deployed a controller without telling anyone.

Practical steps that follow from the query above:

• Scope by organisation or netblock before reading meaning into an aggregate. A global total describes the internet, not your estate.
• Check the vendor advisory for CVE-2026-55797 directly instead of relying on a CVE dork. Coverage of this CVE is second-hand in several places, and the fixed versions need confirming against the vendor before you record remediation.
• Treat the app field as a starting point for enumeration and the port-scoped variant as a rough reachability filter. Neither replaces an authenticated inventory of your own deployments.
• Re-run the CVE dork in a few weeks. When the index catches up, the number stops being zero, and the size of the change is itself a signal about how fast the correlation pipeline moves.

References

• ZoomEye search: https://www.zoomeye.org/
• Argo CD CVE-2026-55797 advisory (verify against the vendor before recording remediation)