ZoomEye data shows 1,537 Jenkins controllers reachable from the public internet

A measurement exercise published on dev.to has put a number on a long-running problem: Jenkins build controllers that anyone on the internet can reach. Using the search engine ZoomEye, the author counted 1,537 instances matching Jenkins' product fingerprint at the time of collection, and argues that putting build controllers online remains a routine architectural decision across the industry.

What the scan actually measured

The figure comes from a single ZoomEye fingerprint query for the Jenkins product. According to the dev.to article, it should be read as an observed count of reachable systems, not of vulnerable ones: a patched and hardened controller may sit on a public address deliberately, and reachability alone does not prove exploitability.

What the number does establish is scale. Whenever a new flaw lands in Jenkins core or in one of its many plugins, a pool of more than a thousand controllers is immediately in scope for anyone scanning the internet.

Why the exposure persists

The article attributes the persistence to organisational factors as much as technical ones. Jenkins is typically installed by build or platform engineers rather than security staff, so controllers often go missing from the asset inventories that drive vulnerability scanning. A public address is frequently the path of least resistance for connecting external build agents and receiving webhooks from hosted Git services. And because controllers are internal tooling, they are often left outside the change-management discipline applied to production services.

The plugin model compounds the maintenance burden. Jenkins functionality arrives largely through plugins, each shipping on its own release cadence and publishing its own advisories, so keeping a controller current means tracking the core product plus a long list of extensions.

The vulnerability record

Jenkins publishes security advisories on a regular schedule, and the dev.to piece highlights several recent ones with particular weight for internet-facing deployments: a flaw allowing arbitrary file reads through the CLI, path traversal, and stored cross-site scripting in plugins.

The clearest illustration of why reachability matters is CVE-2024-23897. Per the source, an unauthenticated attacker who could reach the CLI endpoint was able to read files from the controller, which in practice can include stored credentials and configuration. The bug drew wide attention largely because so many controllers were exposed in the first place.

What defenders are advised to do

The article closes with a set of recommendations for teams running Jenkins:

• Treat internet reachability of any controller as a finding in its own right, regardless of how authentication is configured.
• Move controllers behind a VPN or an identity-aware proxy, exposing only the specific endpoints that external agents genuinely need.
• Track advisories for Jenkins core and plugins as first-class vulnerability findings, each with a named owner and a remediation deadline.
• Rotate credentials held on controllers and shrink the set of secrets any single controller can access.
• Forward build logs to storage that the controller itself cannot modify.

The author also points to existing CISA and NSA guidance on defending CI/CD environments as a broader reference for hardening build infrastructure.

Why it matters

Build controllers occupy an unusually sensitive position in the software supply chain: they hold credentials for source control, deployment targets and cloud accounts, and they emit artifacts that downstream systems trust. An exposed controller is therefore not just another unpatched server — a compromise can propagate toward production through both the secrets it stores and the artifacts it produces.

The ZoomEye figure is a snapshot rather than a census, and it says nothing about how many of those instances are actually vulnerable. But it suggests the architectural choice that made CVE-2024-23897 so consequential is still being made at scale. For platform and security teams, the actionable takeaway is simpler than any single patch: find out whether your Jenkins controllers are reachable from the internet, and if they are, treat that as the finding.