72,257 Titles Against 239,739 Fingerprints: Picking the Right NetScaler Field

When the same product can be queried four different ways and each returns a different number, the choice of field becomes a substantive decision with an audit trail. NetScaler is a clean example because the product has an old name, a new name and a corporate parent.

The measurements

On 20 October 2026, between 22:32 and 22:37 UTC, queries with sub_type="all" and a page size of one record returned:

Query	Matched assets
app="Citrix NetScaler"	239,739
app="Citrix"	211,049
app="NetScaler"	117,407
title="Citrix"	240,774
title="NetScaler"	72,257

Five queries, five answers, one product family. The spread from 72,257 to 240,774 is a factor of 3.3.

Why each field behaves differently

title reads the HTML document title. It is a literal string from a rendered page. A login page titled "NetScaler Gateway" matches; the same appliance serving an application through a proxy, where the title belongs to the proxied application, does not.

That explains the 72,257 figure for title="NetScaler": it counts assets currently rendering a page whose title contains the word. Many NetScaler deployments serve content whose title is the customer's application, so the field undercounts dramatically.

app is a product classification produced by the scanning engine from multiple signals. Within app, matching is fuzzy by default: = performs word-segmented matching while == requires exact equality. That is why app="Citrix NetScaler" (239,739) and app="Citrix" (211,049) and app="NetScaler" (117,407) all return large but different populations — each matches different subsets of the classification vocabulary.

The larger app values relative to title indicate that classification draws on more than page titles: response headers, TLS characteristics, default error pages and path behaviour.

What this means for a query you plan to reuse

A single measurement is a snapshot. The value of a field choice appears when the query is repeated and the delta is interpreted.

If a team queries title="NetScaler" this quarter and app="Citrix NetScaler" next quarter, the change mixes a real population change with a definitional change and cannot be separated. The rule is unglamorous: choose the field, record it with the count, and never change it inside a series.

For population work, the app field with the full product name is the better default because it is designed for classification. For questions about what a user sees, title is the right field, since it measures the rendered interface rather than the product identity.

A cross-check that resolved ambiguity

The near-agreement between app="Citrix NetScaler" at 239,739 and title="Citrix" at 240,774 is worth noting. Two completely different fields producing values within 0.4 percent of each other is not proof, but it is a coherent signal: it suggests the classification vocabulary and the rendered titles align closely for this product family.

It also warns against assuming that title always undercounts. For title="NetScaler" it does, because the brand appears in fewer page titles than the parent company name. The relationship depends on the string, not on the field.

The practical procedure

1. Enumerate every field and name variant you might use for the product.
2. Run all of them in one session so the timestamps are comparable.
3. Choose the one that best matches the question being asked, not the one returning the largest number.
4. Record the field, the exact string, the match mode and the timestamp with every count you publish.
5. Repeat with the identical definition for every subsequent measurement.

A count without its field and match mode is a number of unknown meaning. The spread in this measurement round — three-fold for one product family — is a fair indication of how much an unstated definition can move a conclusion.

References

• ZoomEye, search interface and query syntax documentation, queried 20 October 2026 for the dorks listed above.
• Citrix, advisory CTX697096.
• CISA, Known Exploited Vulnerabilities Catalog.

Comments

[Aiko Tanaka]

Treat each field as a different measurement, not interchangeable syntax. title is precise for branded login pages but misses appliances that front another application. app depends on the scanner's fingerprint rules, which may combine headers, TLS metadata, favicon hashes, default paths, and response-body markers.

For a defensible count, keep a small validation sample for each query and record false positives and false negatives. Use the union of narrow product signatures for discovery, deduplicate by a stable asset key, and report each field count alongside the union. Version the fingerprint rules and timestamp the scan, since parser changes, redirects, virtual hosting, and renamed products can shift the result even when the underlying population has not changed.