Which versions of diboot-core are affected by EUVD-2026-54229?

diboot-core's /common/load-related-data endpoint contains broken access control allowing any authenticated user to exfiltrate secret credential fields (@JsonIgnore-annotated authSecret and…

How to fix or mitigate EUVD-2026-54229?

Within 24 hours: immediately restrict network access to the /common/load-related-data endpoint via reverse proxy, firewall, or WAF rules-block POST requests unless from designated administrative networks; disable the endpoint entirely via configuration if not mission-critical to diboot-admin-ui. Within 7 days: audit system logs for suspicious access patterns to this endpoint; rotate all user credentials and secrets immediately; implement behavioral monitoring and alerting for endpoint access attempts. Within 30 days: escalate to diboot maintainers for explicit patch timeline; if no patch release date is confirmed within this window, initiate security review for replacement of diboot-core with actively maintained alternatives, as unpatched access control in authentication systems creates unacceptable risk.

diboot-core EUVD-2026-54229

Q: What is the CVSS score of EUVD-2026-54229?

EUVD-2026-54229 has a CVSS 4.0 base score of 7.1 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

| CVE-2026-70557 HIGH

Authorization Bypass Through User-Controlled Key (CWE-639)

2026-08-06 disclosure@vulncheck.com

GHSA-5cj8-jrqq-crmv

Authentication Bypass

7.1

CVSS 4.0 · Vendor: vulncheck

Severity by source

Vendor (vulncheck) PRIMARY

7.1 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

6.5 MEDIUM

Network-reachable endpoint requiring only low-privilege authentication; no user interaction; direct impact is confidentiality-only (hash disclosure) with no integrity or availability impact on the vulnerable system itself.

3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (vulncheck).

CVSS VectorVendor: vulncheck

Attack Vector

Network

Attack Complexity

Low

Privileges Required

Low

User Interaction

None

Scope

Lifecycle Timeline

Analysis Generated

Aug 06, 2026 - 22:47 vuln.today

CVE Published

Aug 06, 2026 - 22:18 cve.org

HIGH 7.1

DescriptionCVE.org

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.

AnalysisAI

Broken access control in diboot-core's POST /common/load-related-data endpoint allows any authenticated user - including accounts with zero roles - to exfiltrate @JsonIgnore-annotated secret fields (authSecret, secretSalt) for every account in the system. The sole security guard, relatedDataSecurityCheck(), returns true unconditionally, making authorization enforcement completely absent. Because diboot uses Apache Shiro's two-iteration MD5 with an 8-character salt for password storage, disclosed hashes are trivially cracked offline, converting this confidentiality flaw into a full administrative takeover path. No public exploit code or CISA KEV listing is confirmed at time of analysis, but the low exploitation complexity and the fact that the endpoint is required by the official diboot-admin-ui frontend means the attack surface is present in any standard deployment.

Technical ContextAI

diboot is a Java low-code development framework built on MyBatis-Plus, maintained by dibo-software. The @TableField annotation maps entity fields to database columns, and the /common/load-related-data endpoint was designed to let the frontend dynamically load relational data by passing field names as caller-controlled input. The flaw is CWE-639 (Authorization Bypass Through User-Controlled Key): the server resolves attacker-supplied field names against any entity's column map without an allowlist, then returns all row values - including fields annotated @JsonIgnore, which are intended to be excluded from serialized API responses. The security check method relatedDataSecurityCheck() is a stub that always returns true, and the renamed successor attachMoreSecurityCheck() on the development branch carries the same defect. Apache Shiro's default credential hashing (two-round MD5, 8-character alphanumeric salt) is well-studied and breakable with commodity GPU rigs or rainbow tables, so IamAccount.authSecret exposure directly enables offline credential recovery.

RemediationAI

No vendor-released patch with a confirmed fixed version has been identified at time of analysis. The upstream development branch renamed the mechanism but did not implement a real authorization check, so upgrading to a development snapshot does not remediate this issue. As an immediate compensating control, operators should remove or disable the POST /common/load-related-data (and its attachMore* successor) endpoint at the web server or reverse-proxy layer, accepting the trade-off that diboot-admin-ui relational data loading features will break. Alternatively, network access to the endpoint should be restricted to trusted internal IP ranges only, reducing (but not eliminating) exposure. Operators should also audit all IamAccount credential hashes for signs of exfiltration and consider forcing a credential reset for all accounts, given that any prior access by a low-privilege user could have already extracted the hashes. Migration away from Shiro's MD5-based credential hashing to bcrypt or Argon2 is strongly recommended regardless of patch availability, as it neutralizes the offline cracking step. Monitor the GitHub issue (https://github.com/dibo-software/diboot/issues/104) for a confirmed patched release.