Some platforms are interesting precisely because they are rare. Apache StreamPark manages the lifecycle of streaming jobs against a Flink cluster: submit, start, stop, monitor, redeploy. A defender who finds one on the public internet has found something that can start and stop production data pipelines, and the population of such systems is small enough that a specific answer is possible rather than a statistical one.

The measurement

Run through ZoomEye on 2026-10-23, page size one, all sub-types:

  • app="Apache StreamPark" returned 167.

  • title="Apache StreamPark" returned 170.

Search link: https://www.zoomeye.ai/searchResult?q=YXBwPSJBcGFjaGUgU3RyZWFtUGFyayI%3D

The two figures are within two per cent of each other, which is the tidiest correlation in this series and means something specific. There is essentially no embedded deployment, no title rewriting and no third-party population inflating the title side. The product presents itself the same way to a fingerprint engine and to a title search, so either query describes the same set of hosts.

A hundred and seventy hosts is small. It is also a complete enough picture to act on directly: an organisation can enumerate the addresses answering as StreamPark and compare that list against its own inventory in an afternoon.

What the control plane can do

StreamPark holds the operational relationship with a Flink cluster, which places it in a privileged position:

  • It submits jobs, which means it can run code on the cluster, because a streaming job is a program.

  • It stores the cluster connection details, including the address of the JobManager and any credentials required to reach it.

  • It holds application configuration, which for streaming pipelines routinely includes Kafka bootstrap addresses, schema registry endpoints, database credentials and object storage keys for checkpoints.

  • It retains job history, which describes which pipelines exist, how often they deploy and what they are called.

Reading that list in reverse order is the attacker's sequence. Job history names the pipelines, application configuration supplies the credentials, and job submission provides execution. None of it needs a vulnerability in StreamPark itself if the interface is reachable without authentication.

The specific risk of submitting a job

Most control planes expose configuration. StreamPark also exposes the ability to launch arbitrary code in the form of a Flink job, which is a materially stronger primitive. A submitted job runs on the cluster, inherits the cluster's network position, and has access to whatever the pipeline configuration references.

That changes containment. Removing the exposed interface stops further submissions. It does not tell you whether a job was already submitted, and a job that was deployed deliberately will appear in the history as a normal deployment unless someone knows the baseline. An incident review therefore has to compare the current job list against a known-good state rather than simply count jobs.

Why so few are exposed

The low count is not an accident of adoption. StreamPark is an operator's tool, installed by the team that runs the platform, and it is usually placed where that team already works: behind a VPN, on a management subnet, or inside a bastion. The architecture pulls it toward the interior.

That makes an internet-facing instance a signal rather than a statistic. It suggests a deployment that was published for a specific reason, most likely remote access during an incident or convenience for a distributed team, and that the reason was never revisited afterwards. Reviewing it is cheap, and the number of hosts to review is small.

Checks worth running

  • Confirm no StreamPark instance answers on a public address, and if one does, identify who published it and why.

  • Require authentication at the application and place the interface behind a VPN rather than a firewall rule tied to an office address that no longer exists.

  • Treat the stored Flink connection configuration as a credential store, and rotate anything it holds if the instance was reachable.

  • Compare the current job list against change records, including stopped jobs, because a stopped job still names a code path that was once executable.

  • Restrict the Flink cluster so that a submission from the management host is the only accepted source.

Limitations

ZoomEye totals describe observed hosts and will change with crawl coverage over time. A fingerprint match confirms the application answered; it does not confirm that authentication is absent, that a Flink cluster is connected, or that job submission is enabled for an unauthenticated caller.

References

  • ZoomEye application fingerprint query for Apache StreamPark, run 2026-10-23, total 167.

  • ZoomEye title query for Apache StreamPark, run 2026-10-23, total 170.

  • Apache StreamPark documentation covering Flink cluster configuration, job submission and application management.