CVE-2026-77933 in DB-GPT
Summary
by MITRE • 10/20/2026
DB-GPT through 0.8.2 contains a hardcoded credentials vulnerability in its default docker-compose.yml that sets a static MYSQL_ROOT_PASSWORD and publishes port 3306 on all interfaces. Attackers reaching port 3306 or the shared dbgptnet network can authenticate as root@% to gain full database access including FILE and SUPER privileges.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in DB-GPT versions through 0.8.2 represents a critical misconfiguration rooted in insecure default settings within its Docker Compose deployment template. This flaw falls under the category of CWE-798, which involves the use of hardcoded credentials that are difficult to change and often known by attackers. The specific issue arises from the docker-compose.yml file provided with the software distribution, which configures a MySQL database instance using static authentication parameters rather than requiring user-defined secure inputs during deployment. This design choice fundamentally undermines the security posture of any environment where these defaults are utilized without modification, as it establishes a predictable and exploitable entry point for unauthorized access.
Technically, the vulnerability manifests through two primary mechanisms: hardcoded credentials and excessive network exposure. The configuration explicitly sets MYSQL_ROOT_PASSWORD to a static value that is publicly documented or easily discoverable within the source code repository. Furthermore, the container networking settings publish port 3306 on all available interfaces rather than binding it exclusively to localhost or restricting access via firewall rules. This combination allows any external actor with network reachability to connect directly to the database service. The authentication mechanism permits connections from any host using the wildcard user identifier root@%, granting immediate administrative privileges upon successful credential validation.
The operational impact of this vulnerability is severe, as it results in a complete compromise of the underlying data store and potentially the broader system hosting the container. An attacker who authenticates with these default credentials gains full database access, including FILE and SUPER privileges. The FILE privilege allows for reading files from the server's file system that are readable by all users or writable by the MySQL server process, which can lead to further exploitation such as web shell uploads if applicable paths are accessible. The SUPER privilege grants unrestricted administrative control over the database engine, enabling actions like killing other connections, changing global variables, and executing arbitrary SQL statements with elevated permissions. This level of access effectively neutralizes all data confidentiality and integrity controls provided by the database layer itself.
From a threat intelligence perspective, this vulnerability aligns with ATT&CK technique T1078, Valid Accounts, specifically involving default accounts that are commonly known or easily guessed. It also relates to T1539, Steal Web Application Credentials, although in this context, the credentials are not stolen through phishing but rather obtained via static configuration exposure. The attack vector is classified as Network (T1078) with a complexity of Low due to the lack of required authentication challenges beyond knowing the hardcoded password and network accessibility.
Mitigation strategies must focus on immediate remediation of deployment configurations and long-term security hardening practices. Organizations using DB-GPT should immediately update their docker-compose.yml files to remove any static MYSQL_ROOT_PASSWORD values, replacing them with dynamically generated secrets or integrating with external secret management systems such as HashiCorp Vault or AWS Secrets Manager. Network exposure must be restricted by binding the MySQL port exclusively to localhost (127.0.0.1) if remote access is not strictly required, or by implementing strict firewall rules and network policies that limit connectivity to trusted IP ranges only. Additionally, adhering to the principle of least privilege dictates that root accounts should never be exposed over networks; instead, application-specific users with minimal necessary permissions should be created for operational use. Regular audits of container configurations against industry standards like CIS Benchmarks for Docker are essential to prevent such misconfigurations in production environments.