GHSA-FGMC-2HQJ-86V4: Default Administrative Credentials in vantage6-server

The vantage6 federated learning framework facilitates privacy-preserving data analysis across distributed organizations. Within this decentralized architecture, the central server coordinates computation tasks and manages user identity. The system relies on security at the server level to prevent unauthorized access to task metadata.

Historically, the server initialized its database automatically on first startup. When no administrators were detected, it provisioned a root user. This behavior, while convenient for initial testing, introduced a default credential vulnerability in production environments.

This security advisory analyzes the mechanism of this default configuration flaw. It provides the necessary technical insights to detect, mitigate, and resolve the issue across affected installations.

The root cause of this vulnerability lies in the implementation of the database bootstrapping process in the vantage6-server component. When the application initializes, it evaluates whether the database contains any administrative records. If no administrator account is detected, the server automatically invokes the _create_super_user() function.

In vulnerable versions of the software, the _create_super_user() function retrieved authentication credentials from a static, hardcoded dictionary named SUPER_USER_INFO. This dictionary defined both the username and password as the literal string value root. The framework then proceeded to create an organization named root and assigned this credential pair to the newly created user record.

An associated design flaw, tracked in Issue #2466, further compounded this risk. When administrators deleted the default root user via the user interface but left the root organization intact, the system threw an IntegrityError during subsequent boots. This database constraint violation occurred because the unique constraint organization_name_key was violated when the server attempted to auto-recreate the root user and organization. The resulting crash discouraged administrators from removing the default account, leaving deployments exposed.

To understand the vulnerable implementation, analyze the bootstrapping logic in vantage6-server/vantage6/server/__init__.py. The original implementation did not support external credential injection and logged the plaintext credentials during creation.

# Vulnerable implementation in vantage6-server
# SUPER_USER_INFO is a static dictionary: {'username': 'root', 'password': 'root'}
 
log.warn(
    f"Creating root user: "
    f"username={SUPER_USER_INFO['username']}, "
    f"password={SUPER_USER_INFO['password']}"
)
 
user = db.User(
    username=SUPER_USER_INFO["username"],
    roles=[root],
    organization=org,
    email="root@domain.ext",
    password=SUPER_USER_INFO["password"],
    failed_login_attempts=0,
    last_login_attempt=None,
)

The temporary patch introduced conditional checks to allow administrators to supply the root password via an environment-defined file path, typically configured using Docker Secrets. This mitigation prevents the default fallback behavior if the variable is defined.

# Patched implementation incorporating V6_INITIAL_ROOT_PASSWORD_FILE
 
if os.environ.get("V6_INITIAL_ROOT_PASSWORD_FILE"):
    with open(
        os.environ.get("V6_INITIAL_ROOT_PASSWORD_FILE")
    ) as password_file:
        initial_root_password = password_file.read().strip()
    log.info(
        f"Creating root user with password provided via V6_INITIAL_ROOT_PASSWORD_FILE"
    ) 
else:
    initial_root_password = SUPER_USER_INFO["password"]
    log.warn(f"Creating root user with default credentials!")
 
user = db.User(
    username=SUPER_USER_INFO["username"],
    roles=[root],
    organization=org,
    email="root@domain.ext",
    password=initial_root_password,
    failed_login_attempts=0,
    last_login_attempt=None,
)

Exploiting this vulnerability does not require sophisticated techniques or specialized tools. Because the default administrative credentials are standard across all unpatched deployments, an attacker only needs network visibility to the server API endpoint to gain administrative access.

The attack begins with an external network scan to identify active vantage6-server endpoints. The default API interface typically exposes an authentication route at /api/token or a web-based user interface. Once the endpoint is located, the attacker issues a standard HTTP POST request containing the default credentials.

POST /api/token HTTP/1.1
Host: target-vantage6-server.local
Content-Type: application/json
 
{
  "username": "root",
  "password": "root"
}

If the deployment has not been configured to use the alternative password file, or if the administrator has not rotated the password post-installation, the server authenticates the request. The server returns an access token, granting the attacker administrative control over the federated learning environment.

The impact of unauthorized administrative access to a vantage6-server is significant. In a federated learning framework, the server acts as the central coordinator for sensitive analytical tasks across multiple institutions. Compromising the root account allows an attacker to manipulate the entire platform.

Specifically, an attacker can modify collaborative algorithms, view metadata associated with private federated datasets, and manipulate user roles. Because vantage6 is frequently used in high-privacy contexts such as healthcare and financial analysis, exposure of metadata or algorithm manipulation can undermine the privacy guarantees of the entire collaboration.

Furthermore, an administrative session allows the attacker to register malicious nodes or alter task definitions. This results in unauthorized model extraction or data reconstruction attacks against participating nodes. The CVSS 4.0 base score of 6.9 reflects the direct impact on confidentiality, integrity, and availability within the scope of the vantage6 deployment.

Permanent remediation requires upgrading all vantage6-server installations to version 5.0.0 or higher. In this major release, the development team deprecated the SUPER_USER_INFO structure entirely. The framework now relies strictly on secrets configuration or environment-driven setup utilities, which enforce strong, unique passwords during deployment.

For systems where an immediate upgrade to version 5.0.0 is not feasible, administrators must apply the temporary workaround introduced in the legacy branch. This involves configuring the V6_INITIAL_ROOT_PASSWORD_FILE environment variable to point to a secure file containing a strong, randomly generated password.

# Example environment variable configuration
export V6_INITIAL_ROOT_PASSWORD_FILE="/run/secrets/v6_root_password"

Additionally, security teams must verify system logs to ensure the server does not output warnings regarding default credentials. If the log contains the entry indicating creation of a root user with default credentials, the deployment is insecure and requires configuration review.