Description

NebulaGraph exposes its runtime configuration over an unauthenticated HTTP service. Each daemon starts the web service defined in src/webservice/WebService.cpp, whose bind address defaults to all interfaces, and registers routes for reading and writing gflags alongside status and statistics. Neither the service nor its router carries any authentication, token check or address restriction. The read route returns the daemon's full set of runtime flag values, which includes the configured certificate, key and certificate-authority paths, the password file path, data directories and the transport-security enable flags. The write route parses a supplied map and applies each entry through the gflags runtime setter, so a caller able to reach the port can change the daemon's behaviour without restarting it, including disabling the transport-security flags, redirecting log files and altering flags such as failed_login_attempts and password_lock_time_in_secs. Public reports of this endpoint describe a single name, enable_authorize, being refused by the handler; at release 3.8.0 that refusal is not present and the handler applies every name it is given.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "9.8",
  "pubDate": "2026-08-26T16:16:46.013Z",
  "pubdate": "2026-08-26T16:16:46.013Z",
  "executiveSummary": "NebulaGraph versions up to 3.8.0 are susceptible to an unauthenticated configuration modification vulnerability residing within the internal web service daemon.\nThe vulnerability allows remote, unauthenticated attackers to query runtime configuration flags and execute arbitrary state changes by interacting with the administrative HTTP interface.\nThe affected component, defined in src/webservice/WebService.cpp, lacks authentication, authorization, or IP address restrictions, exposing sensitive operational parameters.\nAttackers can disable transport-level security, redirect system logs, modify authentication thresholds such as password lock-out policies, and exfiltrate sensitive file paths including certificate and key locations.\nThe risk is critical due to the ease of exploitation; an attacker with network reach to the service port can achieve full control over the daemon's runtime behavior without needing prior credentials.\nThe absence of a validation mechanism for the provided gflags map permits the modification of almost any internal flag that is marked as mutable at runtime.\nThis exposure creates a significant security risk for the confidentiality, integrity, and availability of the NebulaGraph cluster.",
  "technicalDetails": "The root cause of this vulnerability is the implementation of an administrative HTTP service within the NebulaGraph daemon (src/webservice/WebService.cpp) that performs no authentication or authorization checks on inbound requests. This service, by default, binds to all network interfaces, making the administrative API globally accessible if not explicitly firewalled.\nThe service implements both read and write HTTP routes for gflags management. The read route facilitates information disclosure, returning the complete set of runtime flag values. This exposes sensitive environmental data, including the file system paths to SSL/TLS certificates, private keys, certificate authority files, password storage files, and various data directories. Additionally, it reveals the current status of transport security (e.g., enable_ssl flags), providing attackers with a roadmap for further infrastructure compromise.\nThe write route is critical; it parses a user-supplied map of key-value pairs and directly invokes the gflags runtime setter. As of release 3.8.0, the handler lacks the restrictive logic (previously observed for the 'enable_authorize' flag) that would prevent modification of sensitive settings. Consequently, an attacker can submit an HTTP request containing malicious gflags updates to modify the daemon's internal state on-the-fly.\nExploitation flow: 1. Network reconnaissance identifies an open NebulaGraph administrative port. 2. The attacker sends a GET request to the read route to enumerate current security policies and file paths. 3. The attacker crafts a POST request to the write route containing sensitive flag redefinitions. For example, by setting transport-security flags to false or altering failed_login_attempts and password_lock_time_in_secs, the attacker weakens the system's security posture. 4. The daemon processes the request and immediately applies the new configuration values to the running process without requiring a restart, effectively altering the system's behavior without logging or administrative intervention.\nThe lack of authentication combined with the broad scope of mutable gflags results in a post-exploitation state where the integrity of the database service is fully compromised. An attacker can essentially disable security controls, manipulate audit or log paths for evasion, or force the service into an insecure state to facilitate further exploitation or data exfiltration."
}