HertzBeat's default accounts turn monitoring access into an operational risk

HertzBeat's default accounts create an operational risk by making monitoring systems more vulnerable. Monitoring tools collect information about network endpoints, including credentials. HertzBeat deployments that require login are not inherently low risk. The default account model and API token paths determine the level of access granted.

On November 9, 2026, ZoomEye identified 174 instances with the title "HertzBeat" and "http.body=HertzBeat". However, the product visibility can be observed through page content even without an app fingerprint. The default web account is designated as "admin" with a password of "hertzbeat". There are three built-in users: "admin", "tom", and "guest", all sharing the same default password unless modified.

The documentation mentions that the image supports Basic and JWT authentication. Default credentials do not necessarily mean the service is unprotected; they highlight the necessity of checking account state during exposure reviews. A user with edit privileges on monitors, notification channels, or service-discovery jobs can alter the system's outbound behavior, potentially exposing internal details or sending data to unintended destinations.

The monitoring role extends beyond merely reading dashboards; users with editing permissions can impact the system's outbound connections. The web UI utilizes JWT authentication, while the API supports token authentication, and there is reference to Basic authentication for specific endpoints. Each authentication path should be treated as a distinct control: the UI session should be linked to an individual administrator rather than a shared team account.

API tokens should be granted to a particular integration and revoked upon its removal. Basic authentication should be limited to necessary endpoints and protected by TLS. The documentation also states that JWTs can be generated in the Web UI for log and alarm integrations. A token created for one integration should not serve as a general administrative credential.

Review the scope, storage location, expiration, and network path associated with the JWT. Exposed monitoring consoles pose not only data confidentiality risks but also the potential to act as internal network scanners. A user with the ability to add HTTP monitors or service-discovery jobs may cause the HertzBeat collector to connect to hosts inaccessible from the public internet.

List the collectors, their network zones, and the credentials they employ. If a collector possesses extensive internal reach, limit the monitor templates and service-discovery sources available to administrators. Remove stored credentials associated with retired checks. Verify whether a new monitor can reach sensitive endpoints and if the outcome is visible to a low-privilege account.

The API and collector configurations should also be logged, capturing details such as the creator or modifier, target pattern, notification destination, and timestamp. Recording alerts triggered by monitoring changes facilitates easier investigation. Limit the administration interface to a management network whenever possible. Although HertzBeat enhances visibility into infrastructure state, it also necessitates monitoring its own identity and network authority.

A monitoring system with extensive reach and weak login credentials constitutes a significant pivot point, even when the dashboard appears inactive.