1.2 Million Ivanti Assets and 3 Under the Old Brand: Naming Drift in Exposure Queries
Product names change. Companies acquire products, rename them, and keep the old name alive in documentation for a decade. Exposure queries are built on product names, which means an acquisition can silently invalidate a whole class of monitoring.
The measurements
On 20 October 2026, between 22:33 and 22:37 UTC, queries with sub_type="all" and a page size of one record returned:
| Query | Matched assets |
|---|---|
app="Ivanti Connect Secure" |
1,225,564 |
app="Ivanti" |
3 |
app="Ivanti Connect Secure" && country="US" |
301,082 |
app="Pulse Secure" && country="US" |
62,753 |
The parent brand returns three assets. The full product name returns 1.2 million. The difference is not a measurement error; it is what the classification vocabulary contains.
Reading the three
app="Ivanti" returning 3 is the interesting result. If fuzzy word-segmented matching applied as it does for app="Citrix" at 211,049, a query for the corporate name would be expected to match every asset classified with a compound product name containing it.
The value of 3 indicates that the vocabulary does not decompose the product name into the vendor token plus a product token. The classifier stores the full product string, and a bare vendor query does not match it by prefix.
That is a useful negative result. It means vendor-name queries are not a shortcut for a product inventory, and building one on that assumption yields a near-zero count that looks like an absence of exposure.
The Pulse Secure residue
app="Pulse Secure" && country="US" returns 62,753. Pulse Secure was the product's earlier name, and the classifier still holds that vocabulary for the deployments it detected under that identity.
Connect Secure under its current name, restricted to the United States, is 301,082. The legacy-name population in the same country is roughly a fifth of that.
Two readings are possible and the counts cannot distinguish them. The first is that these are older deployments that never rebranded their presentation. The second is that the classification of some assets still resolves to the pre-acquisition name because their observable output did not change after the acquisition.
The second reading is more likely for an appliance whose management interface did not change with the corporate logo, and it has an operational consequence: a query on the current name alone does not cover the full deployed base.
Why this matters beyond one vendor
October 2026 provided a concentrated illustration of the problem. Ivanti Connect Secure was under active exploitation, with CISA adding CVE-2026-104935 to the KEV catalog and reporting a memory-only exploitation chain. Meanwhile, the same product family appears in exposure data under two names, and the parent brand returns almost nothing.
An organization that built its external monitoring on the vendor name would have seen no signal at all. One that monitored the current product name would have covered most of the base. Only a query set covering both names would have been complete.
Building a name-resistant query set
- List every name the product has had, including acquisition-era names and OEM variants.
- Run each as a separate query rather than trying to combine them.
- Add the vendor name as a diagnostic — a near-zero result confirms the classifier does not decompose names.
- Record which name variants return non-trivial populations, and treat that list as the monitoring definition.
- Re-run the diagnostic periodically, since a classifier update can change results without any change in the world.
Step five is the one that catches silent breakage. A vocabulary update that reclassifies assets from a legacy name to a current one would appear as a migration in a trend series and as nothing at all in a single snapshot.
The general lesson
Exposure data inherits the vocabulary of the products it describes, and product vocabularies drift. The countermeasure is not clever query syntax; it is enumeration and record-keeping. Write down every name variant you tested, which ones produced results, and when you tested them.
The three hits for the parent brand are the least useful number in this measurement round and the most instructive. A near-zero result from a query that should have worked is a signal about the classifier, and reading it as a signal about exposure is exactly the mistake that leaves a fleet unmonitored.
References
- ZoomEye, search interface and query syntax documentation, queried 20 October 2026 for the dorks listed above.
- Ivanti, security advisory for CVE-2026-104935.
- CISA, alert on Ivanti Connect Secure exploitation.
- CISA, Known Exploited Vulnerabilities Catalog.
Top comments (0)