DB-GPT 0.8.2 Hardcoded MySQL Root Password Exposes Database to Remote Attackers

eosphoros-ai’s DB-GPT through version 0.8.2 contains a hardcoded credentials vulnerability that exposes MySQL root access to remote attackers. The default docker-compose.yml file sets a static MYSQL_ROOT_PASSWORD and publishes port 3306 on all network interfaces. This misconfiguration allows anyone reaching that port or the shared dbgptnet network to authenticate as root@% and gain full database control, including FILE and SUPER privileges.

Root cause

The issue stems from the default docker-compose.yml configuration file included with DB-GPT. According to the NVD record, this file sets a static MYSQL_ROOT_PASSWORD rather than using a secure, randomized secret. Additionally, the configuration publishes port 3306 on all interfaces, making the database service accessible from any network path that can reach the host. This combination of static secrets and open network exposure creates a direct path for unauthorized access.

Attack path

An attacker does not need valid credentials to exploit this flaw. By reaching port 3306 or the shared dbgptnet network, they can authenticate as root@% using the hardcoded password. Once authenticated, the attacker gains full database access. This includes high-level privileges such as FILE and SUPER, which allow for extensive data manipulation and system-level operations within the database environment, effectively granting complete control over the database instance.

Affected versions

• eosphoros-ai DB-GPT version 0.8.2
• All earlier versions of DB-GPT
• Versions prior to 0.8.2 are also affected by this hardcoded credential vulnerability

Mitigation

• Review and modify the docker-compose.yml file to remove hardcoded passwords.
• Generate a strong, unique password for the MySQL root account.
• Restrict network access to port 3306 to trusted internal networks only.
• Do not publish the database port on all interfaces in production environments.

Detection notes

Security teams should monitor for unexpected connections to database ports, particularly from external or untrusted IP ranges. Look for authentication attempts using default or well-known root credentials. Check database logs for successful logins that do not match known administrative activity. If suspicious access is detected, immediately isolate the affected container or host. Verify that no unauthorized users have created new accounts or modified existing data. Ensure that network segmentation prevents lateral movement from compromised database services to other critical assets within the infrastructure.

Background: Network segmentation

Start by mapping your current traffic flows. Define security zones based on function, not just department. Configure firewalls to deny all traffic by default, then explicitly permit only necessary connections. Test these rules rigorously before full deployment to avoid breaking critical business applications.

Read the full guide: Network Segmentation: How to Partition and Protect Your Data

What to do and how to stay safe: DB-GPT

• Audit all Docker compose files for hardcoded secrets or static passwords.
• Restrict database port exposure to internal networks only.
• Implement network segmentation to limit access to sensitive services.
• Monitor logs for unusual authentication patterns or privilege escalation attempts.

Step-by-step guide: Unpatched Software Myths: Why Common Beliefs Fail to Protect You

General security guidance from the BlueTeam Insider newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

What is the CVE ID for this DB-GPT vulnerability?

The vulnerability is tracked as CVE-2026-77933.

How severe is this vulnerability rated?

The National Vulnerability Database rates it as CVSS 9.3 Critical.

Which versions of DB-GPT are affected?

DB-GPT versions through 0.8.2 are affected by this hardcoded credentials issue.