Nomad's API without an access control list

A scheduler accepts instructions. When that scheduler has no access control in front of it, the instructions come from whoever can reach the port. Nomad is a workload orchestrator with a documented HTTP API, and its own documentation treats enabling ACLs as the step that separates a development cluster from anything else.

Context and method

Counts were collected through the ZoomEye SDK on 2026-09-26 UTC, using the exact dorks shown. Each describes what a fingerprint or banner reported.

• app="Nomad": 1,251
• title="Nomad": 10,828 The two figures differ by roughly a factor of nine, which is a normal gap between a dedicated fingerprint and a word-presence match on titles. Both are small enough to be plausible product-specific counts, and the fingerprint number is the one to quote. Neither number says whether ACLs are enabled on any particular host.

What an unprotected API permits

The HTTP API accepts job specifications, which describe what to run, which image to use, which ports to expose and which host volumes to mount. Without ACLs, a caller can submit a job, stop an existing job, read allocations and query the status of the cluster. Job specifications include environment variables and template blocks that can be used to read files available to the Nomad client. The practical consequence is that reachability of the API is close to reachability of the hosts in the cluster.

Configuration points that decide the exposure

The API listens on port 4646 by default, and the address it binds is configurable. ACLs are disabled unless they have been enabled during bootstrap, so a cluster that was started for an evaluation keeps the default. TLS is separate and encrypts the transport without deciding who may call. The gossip protocol on 4648 and the RPC ports between agents are also part of the cluster's internal surface and belong behind the same boundary.

Checks worth running

From a network where a client should not exist, request the status endpoint and see whether it answers. On the servers, inspect the agent configuration for ACL enablement and the bind addresses, and confirm whether a management token was bootstrapped into a secret store or stored in a file on disk. Review which host volumes are permitted in job specifications, and whether the clients run as root. Look for the agent's own access to a container runtime, since that access is what a submitted job inherits.

References

• Nomad documentation, ACL system and bootstrap
• Nomad documentation, agent configuration and network ports
• Nomad documentation, job specification volume and template blocks