DEV Community

jeffrey
jeffrey

Posted on

Counting the AI Gateway Surface: ZoomEye Data on LiteLLM and Kestra After the September KEV Batch

#zoomeye #internetmeasurement #aiinfrastructure #llmsecurity

Counting the AI Gateway Surface: ZoomEye Data on LiteLLM and Kestra After the September KEV Batch

The September 2026 CISA KEV batch included three flaws in AI and ML infrastructure. Two of them, in LiteLLM and Kestra, are in components that organisations deploy themselves, which makes internet exposure measurable. ZoomEye queries on those components produce a picture that is smaller than expected and more ambiguous than the raw numbers suggest.

What the queries return

A ZoomEye search for app:"LiteLLM" returned 20 results. A search for title:"LiteLLM" returned 36,676. A search for app:"Kestra" returned 0, while title:"Kestra" returned 178.
The gap between the application-fingerprint query and the title query is the central finding here, and it is a methodological one. app:"LiteLLM" matches hosts where ZoomEye has positively identified the application from its response fingerprint. title:"LiteLLM" matches any page whose title contains the string, which includes documentation, blog posts, and comparison articles. The 36,676 figure is not a count of exposed gateways.
The same logic applies to Kestra. The application fingerprint returned nothing, and the title query returned 178, which is consistent with a small deployment base plus a larger body of documentation.

Why the fingerprint number is the honest one

For the LiteLLM authentication bypass, CVE-2026-59822, the relevant population is hosts running LiteLLM as a service. The app: query is the closest available approximation, and it returns 20. That is a small number, and it is worth being explicit about why.
LiteLLM is most often deployed as an internal service behind an API gateway or on a private network. It is not designed to be a public-facing endpoint, and most operators do not expose it. The low count is therefore consistent with how the tool is normally used, not evidence that the vulnerability is unimportant.
The Kestra result is similar. Kestra OSS is a workflow orchestrator, typically deployed inside a network boundary. A fingerprint count of zero does not mean no Kestra instances are exposed; it means ZoomEye's fingerprinting did not positively identify any at collection time, which may reflect the fingerprint's coverage rather than the absence of deployments.

What exposure data can and cannot establish here

The queries establish that the internet-reachable population of these two components is small. They do not establish that the risk is small, for a reason that is specific to AI infrastructure.
An AI gateway does not need to be internet-facing to be valuable to an attacker. It needs to be reachable from wherever the attacker already is. In the incidents that matter, that starting point is usually a compromised workstation or a foothold in the internal network, not a public address. A count of 20 internet-exposed LiteLLM instances says nothing about the thousands of internal ones.

Using the data

The practical application is internal reconciliation, not headline reporting. Query app:"LiteLLM" and title:"Kestra" against your own address space, and treat any result as a finding worth investigating, because neither component is supposed to be public.
For the broader question of internal exposure, internet measurement is the wrong instrument. The right one is an authenticated scan of your own network, combined with an inventory of which teams have deployed a model gateway and whether those deployments hold provider API keys.

Query and method

  • Queries: app:"LiteLLM" returned 20; title:"LiteLLM" returned 36,676; app:"Kestra" returned 0; title:"Kestra" returned 178
  • Collection: ZoomEye, September 2026
  • Scope: application fingerprints and page titles; no version, configuration or ownership inference
  • Limitation: internal deployments are not visible to internet measurement

References

Top comments (0)