CVE-2026-41930: Vvveb Hard-Coded phpMyAdmin Database Credentials Exposure
CVE-2026-41930 affects Vvveb versions before 1.0.8.2 and stems from hard-coded database credentials in the docker-compose-apache.yaml file that deploys a bundled phpMyAdmin container. The record describes unauthenticated access to the full Vvveb database, including administrator password hashes and customer and order data. The record rates it critical (CVSS 3.1 score 9.8) and shows it is not listed in the CISA KEV catalog.
Overview
CVE-2026-41930 is a missing-authentication issue caused by hard-coded credentials in the docker-compose-apache.yaml file shipped with Vvveb. According to the record, the bundled phpMyAdmin container relies on pre-configured database credentials embedded in that configuration, so an unauthenticated party can reach the database interface. VulnCheck is the CNA, and the weakness is mapped to CWE-306 (Missing Authentication for Critical Function).
Impact
The description states that the exposure gives unrestricted read and write access to the whole Vvveb database. The record names three categories of data: administrator password hashes, customer personally identifiable information, and order data. Write access would allow data manipulation, and the description links this scenario to account takeover.
- Confidentiality: high, according to the CVSS 3.1 vector reported by VulnCheck.
- Integrity: high, according to the same vector.
- Availability: high, according to the same vector.
Affected products and versions
The record describes Vvveb versions before 1.0.8.2 as affected. The structured affected list in the record is empty, so the exact range should be confirmed against the upstream advisory. The record also references the 1.0.8.2 release tag and a commit, but it does not describe the commit contents beyond the linked pages.
Exploitation status
The record shows the vulnerability is not listed in the CISA KEV catalog, so no active exploitation in the wild is recorded here. The EPSS probability is 0.00641 (percentile 0.49332), which is a statistical estimate of exploitation likelihood and not evidence of attacks. No exploitation is confirmed in the sources consulted for this analysis.
Remediation and mitigation
- Upgrade Vvveb to version 1.0.8.2 or later, since the description indicates that earlier versions are affected.
- Review the docker-compose-apache.yaml file and remove or rotate any hard-coded database credentials, replacing them with secrets managed outside the repository.
- Do not expose the phpMyAdmin container to untrusted networks. Restrict it to administrative hosts or remove it from production deployments.
- Rotate administrator passwords and assess whether customer or order data may have been accessed while the database interface was exposed.
The record does not provide a complete list of secure configuration changes, so verify details against the upstream release notes and the GitHub advisory.
Detection guidance
- Review web server and container logs for access to the phpMyAdmin interface from unexpected sources.
- Audit database activity for unusual administrative logins, schema changes, or bulk reads of user and order tables.
- Check whether your Docker Compose deployments include the bundled phpMyAdmin service with default or embedded credentials.
- Compare administrator accounts and password hashes against trusted records to identify unauthorized changes.
Limitations of the available information
The record has no title, no structured affected or fixed version data, and no CVSS detail beyond the scores supplied by VulnCheck. The EPSS date in the record (2026-10-13) should be verified against the source before reliance. This analysis does not independently verify the exposure path; it relies on the description and the linked references.
Frequently asked questions
Is CVE-2026-41930 being actively exploited?
The record shows the vulnerability is not listed in the CISA KEV catalog, so this analysis does not report active exploitation. No exploitation is confirmed in the sources consulted.
Which Vvveb version addresses this issue?
The description says versions before 1.0.8.2 are affected, which indicates that 1.0.8.2 is the first version without this issue. The record has no structured fixed-version list, so confirm the details in the release notes.
What data could be exposed?
According to the description, exposure could include administrator password hashes, customer personal information and order data, and write access could allow data manipulation.
This analysis was drafted with AI assistance from verified source data and automatically checked against it.