JeecgBoot CVE-2026-108648

The attacker must hold a valid low-privileged authenticated JeecgBoot session (PR:L) - exploitation is NOT possible unauthenticated. Given that, the specific prerequisite is reaching the GET /sys/api/getDynamicDbSourceByCode endpoint of SystemApiController, which lacks Shiro permission/role annotations, and supplying a valid datasource code in the dbSourceCode parameter; the target JeecgBoot instance (through 3.9.5) must have dynamic datasources configured so that credentials exist to be returned. No user interaction, no special non-default feature toggle, and no elevated role are required beyond basic authentication. The practical limiting factors are: (1) acquiring any application account, and (2) knowing or enumerating valid dbSourceCode values; the decrypted-password disclosure is the designed behavior of the endpoint once reached.

This is a credible, actionable priority rather than a CVSS-inflated paper risk, though it sits in the moderate band. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N) describes a network-reachable, low-complexity attack requiring only low-privilege authentication, with high confidentiality impact and no integrity or availability impact - consistent with CWE-862 missing authorization leaking secrets. Reinforcing signals: a public PoC exists (AnkesKasty cve-request-poc) and the finding comes from a credible research source (VulnCheck), which lowers the barrier to opportunistic exploitation by anyone who already holds any valid account. Tempering signals: exploitation is NOT unauthenticated (PR:L), so an attacker must first obtain a low-privileged JeecgBoot credential, and the direct impact is confidentiality-only. No EPSS score was provided in the input and the CVE is NOT on CISA KEV, so there is no evidence of active or widespread in-the-wild exploitation at time of analysis - the risk is driven by PoC availability plus the high value of the leaked asset (cleartext database credentials), not by observed campaigns. Net: treat as a near-term patch priority for any multi-tenant or internet-exposed JeecgBoot instance, because the leaked DB passwords enable serious downstream lateral movement even though the base CVE scores the disclosure only.

An attacker who holds or registers any low-privileged JeecgBoot account sends a simple authenticated GET request to /sys/api/getDynamicDbSourceByCode with a guessed or enumerated dbSourceCode value, and the endpoint - missing Shiro permission/role annotations - returns the datasource's JDBC URL, username, and decrypted cleartext database password. A public proof-of-concept (poc_sys_api_credential_family.py) already automates this, so exploitation requires no custom development. The recovered credentials can then be used to connect directly to backend databases outside the application.