JeecgBoot through version 3.9.2 contains a high-severity broken access control flaw tracked as CVE-2026-58377 that lets authenticated low-privilege users fully manage OpenAPI credentials. The affected /openapi/auth/* and /openapi/permission/* endpoints reportedly lack required Shiro authorization annotations, allowing create, read, update, and delete actions against stored AK/SK pairs. Reports say the credential list endpoint returns secret keys in plaintext, exposing sensitive credentials that can be stolen and reused to access the platform's OpenAPI functionality.
A related JeecgBoot issue indicates the impact extends beyond credential disclosure: the public /openapi/call/{path} handler allegedly accepts an appkey header without validating the expected secret-key signature, allowing attackers to invoke configured API routes after obtaining any key pair and potentially receive a JWT for the credential owner, including an administrator. Separately, a vulnerability report for JimuReport 2.3.4, part of the JeecgBoot ecosystem, says the POST /jmreport/auto/export endpoint can export report data without authentication because it is marked @JimuNoLoginRequired, creating additional exposure of business data, PII, and embedded credentials.

Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
3 events from the most recent confirmed update back to the earliest known activity.
CVE-2026-58377 was published for a high-severity broken access control vulnerability affecting JeecgBoot through version 3.9.2. The advisory said authenticated low-privilege users can perform full CRUD operations on OpenAPI credentials and obtain plaintext secret keys because the affected endpoints lack Shiro authorization annotations.
A GitHub issue reported that JeecgBoot's OpenAPI module lacks authorization checks on credential-management endpoints under /openapi/auth/* and /openapi/permission/*, allowing any authenticated user to read, modify, or delete AK/SK credentials. The same report said /openapi/call/{path} accepts only an appkey and does not verify the SK-based signature, enabling unauthorized API calls and possible impersonation of credential owners.
A vulnerability report disclosed that JimuReport 2.3.4 allows unauthenticated users to export report contents via POST /jmreport/auto/export because the endpoint bypasses authentication and authorization checks. The report said attackers could enumerate report IDs and retrieve ZIP archives containing potentially sensitive business data, PII, and credentials.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
4 references tracked. Mallory keeps watching after this page renders.
cvefeed.io
Open sourcevulncheck.com
Open sourcegithub.com
Open sourcegithub.com
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.