diboot-core’s POST /common/load-related-data endpoint allows an authenticated user to request any @TableField column from any entity. Because the only check, relatedDataSecurityCheck(), is a no‑op, the endpoint returns values for all rows without an allowlist. As a result, secret fields such as IamAccount.authSecret and IamAccount.secretSalt are exposed. These credentials use Shiro’s two‑iteration MD5 hash with an eight‑character salt, which can be cracked offline, giving an attacker full administrative control. The vulnerability is a classic example of CWE‑639, an information‑leak flaw that can lead to credential compromise.

The affected product is diboot-core. Immediate impact concerns all installations that expose the /common/load-related-data or its renamed counterpart attachMore* endpoint, which the vendor’s official admin UI requires. No specific version range is listed, so any deployment using the default integration is likely vulnerable. Administrators should verify that their instance includes diboot-core and the diboot-admin-ui frontend.

The CVSS score of 7.1 places this issue in the high severity band. No EPSS score is published, but the lack of an allowlist, combined with trivial MD5 cracking, implies a realistic compromise probability for any authenticated user. As the vulnerability is not listed in the CISA KEV catalog, there are no known widespread exploits yet, but the condition that any user can read credentials makes the risk significant. The attack vector is authenticated, but the minimal authorization requirements—any role or even a zero‑role account—make it very easy to execute.