Description

diboot-core's POST /common/load-related-data endpoint resolves caller-supplied field names to any @TableField column of any entity and returns those values for all rows, with no field or entity allowlist. The only guard, relatedDataSecurityCheck(), returns true unconditionally, so any authenticated user (including a zero-role account) can read @JsonIgnore-annotated secret fields such as IamAccount.authSecret and IamAccount.secretSalt for every account, or arbitrary secret fields of any other entity. Shiro's two-iteration MD5 with an 8-character salt is trivially crackable offline, so the disclosed admin password hashes convert to full administrative takeover. The endpoint is not example code; the official diboot-admin-ui frontend requires it, so deployments following the vendor's recommended integration expose it. The mechanism was renamed relatedData* to attachMore* on the development branch, but attachMoreSecurityCheck() also returns true unconditionally.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-08-06T22:18:26.077Z",
  "pubdate": "2026-08-06T22:18:26.077Z",
  "executiveSummary": "The diboot-core library suffers from an authorization bypass and arbitrary data exposure vulnerability within the POST /common/load-related-data endpoint. This vulnerability allows any authenticated user, including zero-role accounts, to query and retrieve sensitive fields—including @JsonIgnore-annotated properties like IamAccount.authSecret and IamAccount.secretSalt—from any database entity mapped with @TableField. The root cause stems from the relatedDataSecurityCheck() function (and its renamed variant attachMoreSecurityCheck() on development branches) returning true unconditionally without enforcing entity or field allowlists. Because the official diboot-admin-ui frontend natively relies on this endpoint, standard deployments are exposed out of the box. Attackers can exploit this capability to extract cryptographic password hashes and other confidential information across all system records. The risk implications are severe, as exposed Shiro-managed MD5 password hashes utilizing an 8-character salt can be cracked offline with minimal computational resources. Consequently, low-privileged users can leverage this vulnerability to execute credential cracking attacks, resulting in full administrative account takeover and complete compromise of the underlying application data.",
  "technicalDetails": "The vulnerability resides in the request handling logic of the POST /common/load-related-data endpoint provided by diboot-core, which dynamically resolves caller-supplied field names to arbitrary @TableField columns across any application entity. The vulnerable component fails to implement input validation, property filtering, or context-aware access controls. Instead of restricting queries to predefined, safe business objects and columns, the endpoint delegates security validation to the relatedDataSecurityCheck() method. This authorization check is fundamentally flawed as it returns true unconditionally for all invocation attempts.\nAuthentication and privilege requirements for exploitation are minimal; any authenticated user, including accounts assigned zero roles or lowest-privilege operational profiles, can successfully issue malicious POST requests to the endpoint. Network exposure is broad, as the endpoint is integrated directly into standard deployments via the official diboot-admin-ui frontend.\nThe attack flow proceeds as follows: First, an authenticated low-privileged user identifies the target entity and sensitive database columns, such as IamAccount.authSecret and IamAccount.secretSalt. Second, the attacker crafts a POST request targeting /common/load-related-data, supplying the targeted entity name and sensitive field identifiers in the payload parameters. Third, because relatedDataSecurityCheck() bypasses all authorization checks, the backend executes the dynamic query against the database without validating whether the caller possesses permissions to access the requested attributes, even bypassing internal object serialization restrictions such as @JsonIgnore annotations.\nFourth, the endpoint processes all table rows and returns the raw sensitive values in the HTTP response. Post-exploitation impact is catastrophic in environments utilizing weak hashing implementations. Specifically, when Apache Shiro's two-iteration MD5 hashing mechanism paired with an 8-character salt is deployed, the retrieved administrative password hashes are trivially crackable via brute-force or dictionary-based offline cracking tools. Successful offline cracking yields plaintext administrative credentials, enabling attackers to immediately escalate privileges and achieve full administrative takeover of the system."
}