Temporal at 1,992 Title Matches and 200 Application Fingerprints

Opening

Temporal is a workflow orchestration engine. Applications define workflows as code, and the engine persists their state so that a process can fail, restart and continue where it stopped. It is the durability that makes it worth running, and the durability is also what makes an exposed instance worth caring about.

Context and method

Two ZoomEye queries were run on 2026-09-28:

• title="Temporal" returned 1,992 matches.
• app="Temporal" returned 200 matches. Both figures are index match counts. They do not describe reachable instances, authenticated instances or vulnerable ones, and the title figure has a specific hazard that the application figure does not.

Analysis or walkthrough

The first thing to note about the title count is that Temporal is an ordinary English word. A title match looks for the string in page content, so an unrelated page that uses the word in its heading is indistinguishable from a Temporal deployment in this measurement. That is not a defect in the tool; it is the reason a product with a common name needs a second query before the number means anything.
The 200 application fingerprints are the more useful of the two figures precisely because they are not vulnerable to that problem. A fingerprint requires a response pattern the index recognizes as belonging to the product, so an unrelated page cannot produce one. The gap between 1,992 and 200 is mostly the cost of the product's name, and it should be read as a note about query design rather than as evidence that most matches are real deployments.
What Temporal exposes when it is reachable is the part that matters. A server deployment has a frontend service, a history service, a matching service and workers, and the frontend accepts client connections over gRPC and, in many setups, an HTTP API. The cluster's state is a database holding workflow histories, timers and task queues. Workflow histories include the inputs and outputs of activities, which in practice means the payloads of the work being done.
The capability that makes exposure more than a data disclosure is that workers execute workflow code. A workflow is code, and an activity is code, and both are supplied by the team that owns the application. Persistence means the engine holds pending work and will deliver it to a worker when one connects.
The namespace model is the control worth understanding. Temporal separates workloads into namespaces, and access is configured per namespace. A deployment that uses a single default namespace, reachable without authentication, has no boundary between the teams using it and no boundary between the cluster and anyone who can reach the frontend.

Implications

For operators, the useful work is a placement review. Confirm whether the frontend is reachable from networks beyond the applications that use it, confirm whether authentication is enforced at the frontend rather than assumed from network position, and confirm that namespaces separate the teams that share the cluster.
The database behind the cluster deserves its own review. Persisted workflow state contains activity inputs and outputs, so the data classification of the database is the data classification of the work the cluster orchestrates, which is often higher than teams expect when the cluster is thought of as infrastructure.
The two counts together carry a lesson about measuring a product with a common name. A title query is a broad net that catches documentation, discussion and unrelated headings, and a fingerprint query is narrow enough to be specific. Where both are available, the fingerprint is the one to trust for a population statement, and the title count is useful mainly for finding the pages the fingerprint would miss.

References

• ZoomEye exposure measurement platform: https://www.zoomeye.org/
• Temporal documentation: https://docs.temporal.io/