hosp_order EUVD-2026-85544

Requires that the hard-coded database credentials in ssm_pro/src/main/resources/jdbc.properties (readable in the public source repository) remain unchanged in a live deployment AND that the backing database is reachable over the network by the attacker. Exploitation is limited by high attack complexity (CVSS AC:H, 'difficult' per VulDB): operators who rotate credentials at deployment, restrict the database to localhost/private network, or firewall the DB port neutralize the flaw. No authentication against the application itself is needed to obtain the credentials from the repo (PR:N), but no special application feature or configuration mode is required to trigger it - the exposure is inherent to the committed config file.

This is a low real-world priority despite being remotely reachable. The CVSS 4.0 base score is only 2.9, driven by AC:H (high complexity) and uniformly Low sub-impacts (VC:L/VI:L/VA:L) - VulDB itself notes exploitability is 'difficult.' The flaw is CWE-798 hard-coded database credentials embedded in a jdbc.properties file committed to a public source repository; the credentials are exposed to anyone reading the repo, but weaponizing them requires the target's backend database to be network-reachable and still running the unchanged credentials, which is why complexity is rated high. A public POC exists (referenced as GitHub issue #119, an issue report rather than a working exploit), so 'publicly available exploit code exists' - but this must NOT be conflated with active exploitation: there is no CISA KEV listing and no EPSS score provided. SSVC framework data is not supplied. The single reporting source is VulDB and the project has not responded, so patch status and even affected version boundaries are unresolved (rolling release). Net: a genuine but low-severity secrets-in-source-control hygiene issue in an obscure project, not an urgent widespread threat.

An attacker browses the public sfturing/hosp_order GitHub repository and extracts the plaintext database username and password hard-coded in ssm_pro/src/main/resources/jdbc.properties. If a deployed instance exposes its backing database to the network with those same unchanged credentials, the attacker authenticates directly to the database to read or tamper with data. A POC/exploit reference has been published, though exploitation complexity is rated high because it depends on a reachable database and unrotated credentials.