Exposed Prometheus Blackbox Exporter endpoints can be abused as network relays

How the relay works

The Prometheus Blackbox Exporter probes HTTP, HTTPS, DNS, TCP, ICMP and gRPC endpoints from wherever it happens to run. That vantage point is the point of the tool: it can reach targets the central monitoring server cannot. As a recent dev.to post explains, the standard multi-target setup passes the target to the exporter's /probe endpoint as a request parameter. Prometheus normally fills in that parameter from reviewed configuration, but the endpoint itself does not enforce the arrangement.

If /probe answers without authentication, a third party can supply any target and have the exporter open a connection from its own host, whether an internal address, a cloud metadata service, or an arbitrary internet destination. The probe's output can also leak reconnaissance detail such as status codes, headers, timing and certificate information.

The post frames the problem as request forgery rather than credential theft. A deployment with no stored secrets is still exposed, because what an attacker borrows is the exporter's place on the network: its DNS resolution, its egress routes, and its possible reach into management networks or cluster metadata endpoints.

Sizing the exposure

To estimate how many instances are visible, the author ran a bounded ZoomEye search on 12 November 2026, between 00:49:31 and 00:49:34 UTC. An application-fingerprint query returned zero results, a title search for "Blackbox Exporter" returned 1,050 hosts, and a body search returned 30,915. The title result is a candidate set; the body figure is inflated by documentation, dashboards and references, so it is not a count of monitoring services.

Locking down the endpoint

The exporter's README documents TLS and basic authentication through a web configuration file, and those settings cover /metrics, /probe and the web UI. The dev.to writeup recommends turning them on whenever the service is not confined to a dedicated monitoring network, with the caveat that authentication alone is insufficient, since a valid credential can be shared or leaked. Network policy is still required.

The safest pattern keeps target generation inside Prometheus and reviewed service discovery, and makes the exporter reachable only from the monitoring system. Egress should be restricted with a firewall, network policy or dedicated subnet, blocking metadata addresses and administrative networks unless a documented monitoring need justifies access.

Modules and the reload path

Module configuration matters too. A module defines the protocol, TLS behavior, redirect handling, preferred IP protocol, headers and authentication used for probes. One that follows redirects broadly can turn a nominally trusted target into a chain of unintended requests, and client credentials embedded in a module should be scoped to the target service alone.

The /-/reload endpoint gets separate attention. Per the README, a configuration reload can be triggered by a process signal or an HTTP POST to that path. An unauthenticated caller who can either edit the configuration file or reach the reload path can change probe behavior, so the post argues that both write access and reload access should be treated as administrative controls.

Auditing your own deployment

For internet-visible hosts, the author suggests starting from the title-based candidate list, confirming the exporter with a harmless request from an approved network, and never probing internal destinations without written authorization. For deployments you own, the checklist is: verify that an unauthenticated /probe request is denied; verify that egress policy blocks a target outside the approved list; test the reload path; and review logs for target, module, response code and requester identity, making sure the logs themselves do not expose probe credentials.

Why it matters

There is no bug in the Blackbox Exporter here; the risk lives in how it is deployed. Monitoring agents are privileged by design, sitting on networks that can see things an outside attacker cannot, and an unauthenticated probe endpoint converts that privilege into a free relay. The dev.to post draws the useful distinction: a monitor that probes a fixed, reviewed set of targets from a tightly filtered network is not the same animal as one that will connect wherever a stranger tells it to.