CVE-2026-108648 in JeecgBoot
Summary
by MITRE • 10/11/2026
JeecgBoot through 3.9.5 contains a missing authorization vulnerability in the GET /sys/api/getDynamicDbSourceByCode endpoint of SystemApiController, which lacks Shiro permission or role annotations. Any authenticated low-privileged user can supply datasource codes in the dbSourceCode parameter to retrieve JDBC URLs, usernames and decrypted cleartext database passwords.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/11/2026
The vulnerability identified in JeecgBoot versions up to 3.9.5 represents a critical failure in access control mechanisms within the SystemApiController component. Specifically, the endpoint GET /sys/api/getDynamicDbSourceByCode is designed to retrieve dynamic database source configurations based on a provided code identifier. However, this API method lacks the necessary security annotations required by Apache Shiro, such as RequiresPermissions or RequiresRoles. In typical enterprise Java applications utilizing Spring Boot and Shiro for authentication and authorization, these annotations serve as gatekeepers that validate whether the currently authenticated user possesses the specific privileges needed to access sensitive resources. The absence of these checks means that the application does not verify if the requester has administrative rights or any elevated permissions before processing the request and returning data.
This missing authorization flaw allows any authenticated user with low-privileged roles, such as standard end-users or basic operators, to exploit this endpoint for unauthorized information disclosure. By supplying arbitrary values in the dbSourceCode parameter, an attacker can trigger the backend logic that queries the database configuration storage. The system responds by returning detailed connection parameters associated with the specified datasource code. This includes sensitive operational data such as JDBC URLs, which reveal internal network topology and database server addresses, usernames used for application-to-database authentication, and most critically, decrypted cleartext database passwords. In many implementations, these credentials are stored in configuration files or databases without adequate encryption at rest, making them immediately usable by an attacker who intercepts the response.
The operational impact of this vulnerability is severe, as it effectively bridges the gap between a low-privileged user account and full administrative control over the underlying database infrastructure. With access to cleartext database passwords and connection strings, an attacker can directly connect to the backend databases using standard client tools or automated scripts. This enables activities such as data exfiltration of sensitive customer information, intellectual property theft, modification or deletion of critical business records, and potentially pivoting into other systems if the database server is accessible from external networks. Furthermore, knowledge of internal JDBC URLs can aid in further reconnaissance efforts against the organization's network infrastructure, facilitating more targeted attacks against specific services running on those hosts.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-538 Insertion of Sensitive Information into Log File or Other External Entity if logs are involved, though primarily it is an access control bypass leading to sensitive data exposure. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1078 Valid Accounts, as the attacker leverages legitimate credentials with insufficient privileges to gain unauthorized access, and potentially T1539 Steal Web Session Cookie if session hijacking is combined, but primarily it falls under data exfiltration techniques enabled by broken object level authorization. The root cause lies in the development oversight where API endpoints were exposed without implementing role-based access control checks appropriate for their sensitivity level.
To mitigate this vulnerability, immediate remediation steps should focus on enforcing strict access controls at the application layer. Developers must add Shiro permission annotations to the getDynamicDbSourceByCode method and any other sensitive administrative endpoints in SystemApiController. These annotations should restrict access exclusively to users with specific high-privilege roles, such as system administrators or security operators. Additionally, it is advisable to implement a centralized authorization filter that validates permissions for all API requests before they reach controller methods, reducing the risk of individual developer errors. Beyond code changes, organizations should audit their configuration management practices to ensure database credentials are not stored in cleartext within application configurations but instead use secure vaults or environment variables with restricted access. Regular security testing and static analysis tools configured to detect missing authorization annotations can help prevent similar issues in future releases.