Struts body strings appear 984,485 times while its page title appears 519

Framework versions matter more than product versions in one respect: a framework vulnerability can apply to every application built on it, including applications that share no vendor. That is why the two numbers below are worth reading together rather than separately.

Measurements

Taken 27 October 2026, sub_type=all, one page request per query:

The first figure is close to a million and the second is a few hundred. Neither counts applications running Apache Struts.

What a million body matches means

Struts is a Java web framework, and the string Struts2 appears in stack traces, error pages, debug output, sample code, tutorials, and the HTML comments that a misconfigured development instance renders to every visitor.

A page that leaks a stack trace containing a Struts class name is a genuine signal about the application behind it, and a page that reproduces a tutorial is not. The index cannot tell those apart. What it records is that the response body contained the string at collection time.

The gap of roughly 1,900 to 1 between this count and the title count is the measure of how much of the web's content mentions a popular framework against how much of it presents the framework as the identity of the page.

Why the title count is the more interesting number

A page titled Struts is unusual because frameworks do not title pages; applications do. A match here tends to be a sample application, a demo instance, an empty default page from a freshly deployed skeleton, or a management console that names the framework it is built on.

Those are exactly the hosts most likely to be running an unpatched scaffold deployed for evaluation and never removed. A demo application dropped onto a server for a proof of concept has no users to complain when it is stale, and it therefore tends to stay stale.

The version question nobody can answer from outside

Whether a given application is exposed to a framework flaw depends on the version of the framework packaged inside its archive, which is not visible in HTML. A host can return a page that mentions Struts2 in a stack trace and be running a fully patched release.

This is the central limitation of using a search index to assess framework exposure: the informative fact is inside the build artefact, and the index sees only what renders. Any conclusion drawn from the 984,485 figure about how many vulnerable applications exist would be fabricated.

What an engineering team can do instead

Inventory applications, not hosts. A software bill of materials per application, produced at build time and stored with the deployment record, answers the version question directly and keeps answering it as frameworks are patched.

Where a bill of materials is not yet in place, the practical substitutes are a dependency manifest committed to the repository and a deployment check that refuses to publish an artefact without one. Both are cheap, and both produce a record that survives the departure of whoever built the application.

Using the index as a lead generator

The title query is a reasonable lead generator for an organisation scanning its own ranges: a small population, mostly default deployments, and each one worth a look. The body query is too broad to act on directly, though restricting it to the organisation's own address space turns a million matches into a short list that can be triaged by hand.

Record the date with the result. Framework fingerprints and body strings both change when vendors publish new rules, and a count that moves because a rule changed is not a change in the world.

References

• ZoomEye, cyberspace search: https://www.zoomeye.ai
• Measurements taken 2026-10-27, sub_type=all, single page request per query.
• Apache Struts project site, for the framework's role as a component of applications: https://struts.apache.org/