Jeecgboot
Monthly
SQL injection in JeecgBoot before 3.9.5 allows authenticated low-privilege users to bypass the SqlInjectionUtil keyword blocklist by inserting newline characters into dictionary and online report SQL fragments, then send newline-separated payloads to endpoints such as /sys/dict/getDictItems to perform boolean- or time-based blind extraction of database contents, including administrator password hashes from sys_user. The assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, so the primary precondition is an authenticated session rather than user interaction or a non-default configuration. Vendor-released patch: 3.9.5; no public exploit identified at time of analysis and no CISA KEV entry was provided.
Authenticated users of any privilege level on JeecgBoot through 3.9.5 can rewrite DingTalk, WeCom, or Feishu third-party integration settings - client id, client secret, agent id and corp id - through the unprotected editThirdAppConfig handler, redirecting directory synchronisation and messaging to attacker-controlled applications or breaking the integrations outright. The defect is a missing authorization check (CWE-862) in ThirdAppController.java with an assessed integrity impact (CVSS 3.1 base 7.1, PR:L, I:H), and publicly available exploit code exists, though no confirmed active exploitation (CISA KEV) is reported. Real-world impact is context-dependent: instances with no configured third-party IM/directory integration expose little to steal or disrupt through this endpoint.
Authenticated low-privileged users of JeecgBoot through 3.9.5 can retrieve any other user's stored password ciphertext through the GET /sys/api/getUserByName endpoint, which lacks authorization checks. Because the platform exposes its hard-coded AES-CBC encryption key via /sys/getEncryptedString, an attacker holding only a basic account can decrypt the returned password values locally and then subject administrator credentials to offline guessing. Publicly available exploit code exists, and exploitation requires a valid low-privileged account (PR:L) with network reachability, making this a genuine but moderate-priority credential-disclosure issue rather than an unauthenticated critical flaw; no CISA KEV entry indicates confirmed active exploitation at time of analysis.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user enumerate record IDs through the unguarded /airag/app/queryById endpoint and then read MCP (Model Context Protocol) server configurations - including endpoint URLs, HTTP headers and outbound authentication tokens - because the permission check in AiragMcpController.queryById is commented out. Exploitation requires a valid JeecgBoot session at any privilege level (CVSS v4.0 PR:L, assessed CVSS 3.1 PR:L) and a deployment that actually uses the AiRAG/MCP feature with stored MCP records; a stock install without configured MCP servers exposes nothing sensitive. Publicly available exploit code exists, though the issue is a moderate-priority information-disclosure flaw (high confidentiality impact, no integrity or availability impact) rather than a remote-takeover bug, and no CISA KEV entry indicates confirmed active exploitation.
Tenant ownership takeover in JeecgBoot through 3.9.5 lets any authenticated user - regardless of privilege level - reassign a tenant's owner by sending userId and tenantId to POST /sys/tenant/changeOwenUserTenant, stripping the legitimate owner and potentially installing the attacker or an accomplice as the new owner. The root cause is a missing authorization check (CWE-862) on the multi-tenant owner-change handler, rated CVSS 7.1 (CVSS:4.0 PR:L, UI:N, integrity-only impact), and publicly available exploit code exists. Exploitation is not drive-by: it requires a valid account on the target and a deployment where the multi-tenant feature is enabled, making this an access-control-bounded integrity risk rather than anonymous remote compromise.
Privilege escalation in JeecgBoot through 3.9.5 lets any authenticated user approve their own pending tenant administrator application and obtain tenant-admin ('tenant pack') permissions across any tenant. The SysTenantController passApply handler performs no authorization check, so a low-privilege account can file an application via doApplyTenantPackUser and then approve it with a PUT to /sys/tenant/passApply, reaching high confidentiality and integrity impact without user interaction or elevated privileges (assessed CVSS 3.1 8.1, PR:L). Publicly available exploit code exists - a Python proof-of-concept for tenant ownership and pack approval is published on GitHub and referenced by VulnCheck - but no CISA KEV entry has been reported, so confirmed active exploitation cannot be asserted.
Database credential disclosure in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to retrieve JDBC connection URLs, database usernames, and decrypted cleartext database passwords from the GET /sys/api/getDynamicDbSourceByCode endpoint of SystemApiController. The handler carries no Shiro permission or role annotations, so a basic application account is sufficient; the only practical hurdles are obtaining any valid session and knowing or enumerating a valid dbSourceCode value, and exposure requires that dynamic datasources be configured on the instance. Publicly available exploit code exists, and the impact is confidentiality-only (CVSS 3.1 6.5 / CVSS 4.0 7.1, PR:L), with no evidence of confirmed active exploitation at time of analysis.
Missing authorization in the saveDeptRolePermission endpoint of JeecgBoot's SysDepartPermissionController lets any authenticated user - regardless of privilege level - rewrite department role permissions, granting themselves arbitrary menu and button permissions or stripping permissions from other accounts. The flaw affects JeecgBoot through 3.9.5 and requires only a valid low-privilege session (PR:L in the CVSS vector), with no user interaction and no special configuration; publicly available exploit code exists, though there is no confirmation of active exploitation in the wild. The independent assessment rates this a genuine, actionable priority: the sole realistic barrier for an attacker is obtaining one low-privilege credential, so internet-exposed instances that permit self-registration are at direct risk.
JeecgBoot through 3.9.5 ships a system log controller whose batch-delete handler performs no authorization check, so any authenticated user - including the lowest-privileged account - can send a DELETE request with the ids parameter set to the special value 'allclear' and wipe the entire sys_log audit table for every user. The result is silent, organization-wide destruction of audit trail evidence rather than data theft, code execution, or privilege escalation, which keeps the real-world impact bounded. Publicly available exploit code exists (a Python PoC script referenced by VulnCheck), and CISA KEV does not list this CVE as confirmed actively exploited (CISA KEV); the vulnerability is confirmed exploited only in the reported PoC sense, not in observed campaigns. CVSS scores of 7.1 (vendor v4.0 and our assessed v3.1) reflect high integrity impact on the log table with low availability impact and no confidentiality impact.
Unauthenticated access to JimuReport's report folder template listing endpoint exposes all report definitions, share tokens, embedded SQL statements, and live query data to any remote attacker. The CWE-306 root cause - missing authentication for a critical function - means the disclosure requires no credentials, no user interaction, and no special tooling. With a CVSS 4.0 score of 8.7 and a network-accessible, zero-complexity attack path, this represents a high-priority information disclosure risk for any JimuReport deployment reachable from an untrusted network. No public exploit or CISA KEV listing has been identified at time of analysis, though the vulnerability is fully disclosed via VulnCheck advisory and a public GitHub issue.
Broken access control in JeecgBoot through 3.9.2 lets authenticated low-privilege users reach the OpenApiAuthController and OpenApiPermissionController endpoints, which are missing Shiro authorization annotations, to fully manage OpenAPI AK/SK credentials. Because the list endpoint returns secret keys in plaintext, any logged-in user can harvest every Access Key/Secret Key pair and then create, modify, or delete them, enabling credential theft and unauthorized invocation of the OpenAPI surface. Publicly available exploit code exists and the issue was reported by VulnCheck, though it is not listed in CISA KEV.
Unauthenticated report data exfiltration in JimuReport (JeecgBoot) through version 2.5.0 lets remote attackers export the full contents of any report via the POST /jmreport/auto/export endpoint. Because the handler carries the @JimuNoLoginRequired annotation, JimuReportTokenInterceptor skips all authentication and the export service never checks the auto-export configuration flag, so any guessed report id is rendered and streamed back. Publicly available exploit code exists; the disclosure comes from VulnCheck and the CVSS 4.0 base score is 8.7 (High), driven by high confidentiality impact with no privileges or user interaction required.
Authenticated SQL injection in JeecgBoot 3.9.5 allows a low-privilege user who can reach the JimuReport Table Dictionary API endpoint /jeecg-boot/jmreport/form/getTableDictList to manipulate the searchSql argument and alter SQL queries, with low impact to confidentiality, integrity, and availability. The flaw is remote and requires no user interaction, but exploitation is gated by a valid low-privilege session; the disclosure states the exploit has been made available to the public. The supplied intelligence does not include a CISA KEV entry or confirmed active exploitation.
SQL injection in JeecgBoot 3.9.5's JimuBI component allows unauthenticated remote attackers to manipulate the 'params' argument of the /jeecg-boot/drag/onlDragDatasetHead/getAllChartData endpoint and influence backend database queries. The CVSS 4.0 base score is 6.9 with low confidentiality, integrity and availability impact, and the independent assessment rates this as a moderate priority rather than critical. The reporter states exploit code has been released publicly, but no CISA KEV entry is provided and confirmed active exploitation is not established.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user retrieve other users' profile details - real names, usernames, emails, phone numbers, birthdays, employee numbers, department paths and posts - by supplying arbitrary userId values to the SysUserController getUserDetailByUserId handler. Exploitation requires only a low-privileged account (CVSS PR:L, no admin rights, no user interaction, no special configuration), and publicly available exploit code exists, so any deployment that permits self-registration or hosts many low-trust accounts is meaningfully exposed. This is a moderate-priority information-disclosure issue rather than a critical one; there is no confirmation of active exploitation and CVSS 4.0 scores it 5.3 (VC:L only, no integrity or availability impact), with the practical limiting factor being that the flaw is reachable only post-authentication.
Authenticated low-privileged users can export department role metadata from JeecgBoot through 3.9.5 because the SysDepartRoleController exportXls handler omits an authorization check. This low-severity information-disclosure issue is limited to read-only exposure of sys_depart_role records such as role names, codes, descriptions, and creating users; publicly available exploit code exists, but no CISA KEV entry is indicated in the provided data. Exploitation requires a valid session with only the default minimal role, and instances that do not allow self-registration or untrusted account creation materially reduce exposure.
JeecgBoot through 3.9.5 allows any authenticated low-privileged user to export the entire sys_comment table by calling the /sys/comment/exportXls endpoint because the SysCommentController handler lacks an authorization check. This exposes comment text and user IDs on records the attacker cannot normally access, but the impact is limited to information disclosure (no write or availability effect). Publicly available exploit code exists, and authentication as a low-privileged user is required (PR:L); the issue is a modest-priority one, not a top-tier emergency.
Any authenticated user of JeecgBoot through 3.9.5 can pull account records belonging to other users by supplying arbitrary userId values to the SysUserController queryChildrenByUsername handler, which performs no authorization check (CWE-862). Exposed data includes names, emails, phone numbers, employee numbers, department assignments, and staff lists for departments the targeted user heads, so the impact is confined to confidentiality of profile and organizational data with no write or availability effect. Publicly available exploit code exists, and the assessed risk is moderate rather than critical: the attacker must already hold a valid low-privileged session, and no public exploit activity has been confirmed.
JeecgBoot through 3.9.5 is vulnerable to a missing authorization flaw (CWE-862) in the SysMessageController delete handler, allowing any authenticated low-privileged user to delete arbitrary message records by sending a DELETE request with an attacker-chosen id. The vulnerability is present in default deployments and requires only a valid low-privilege account; publicly available exploit code exists, though no confirmed active exploitation (not in CISA KEV) has been observed. Impact is limited to integrity and availability of sys_sms rows-no data disclosure or code execution-yielding a medium-severity CVSS 4.0 base score of 5.3 (assessed CVSS 3.1: 5.3, PR:L).
Deletion of message templates in JeecgBoot through 3.9.5 is possible for any authenticated user, even the lowest-privileged account, because the SysMessageTemplateController delete handler omits an authorization check. Attackers can first enumerate template IDs from the unguarded list endpoint, then delete shipped notification templates, causing system notices and workflow reminders to fail. This integrity/availability issue has a CVSS score of 5.3 (medium) and publicly available exploit code exists, though active exploitation has not been confirmed.
Missing authorization in the JeecgBoot SysPositionController removeUserPosition handler (versions through 3.9.5) allows any authenticated low-privileged user to delete user-to-position mappings in the sys_user_position table by sending DELETE requests with arbitrary userId and positionId values. The attacker gains no confidentiality or code execution, but can silently unbind users from their positions, and the deletions are performed without logging, which hampers detection and attribution. Publicly available exploit code exists (a Python PoC referenced by VulnCheck) and the issue is tracked as CWE-862; no CISA KEV listing indicating confirmed active exploitation was provided. Independently assessed as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L (assessed score consistent with the reported 5.3 base), this is a genuine-but-moderate priority issue requiring a valid authenticated account rather than a critical emergency.
Information disclosure in JeecgBoot through 3.9.5 allows any authenticated low-privileged user in a multi-tenant deployment to query the getTenantPackInfo handler with another tenant's tenantId and fixed packCode values such as superAdmin, accountAdmin, or appAdmin, exposing administrator usernames, real names, phone numbers, and departments. The flaw is a CWE-862 missing authorization check in SysTenantController; it is read-only PII exposure that requires a valid account and knowledge or enumeration of a target tenantId, with CVSS 5.3 and an independent assessment of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. Publicly available exploit code exists, but there is no confirmed active exploitation (not in CISA KEV), making this a genuine but modest-severity cross-tenant information-disclosure issue.
Authenticated users can rename and replace dictionaries in low-code applications on JeecgBoot through 3.9.5 because the PUT /sys/dict/editDictByLowAppId endpoint lacks an authorization check. Any registered low-privilege user can obtain a target dictionary's low_app_id from GET /sys/dict/list and then pass it via the lowAppId parameter or X-Low-App-ID header to modify that dictionary's name and items. Publicly available exploit code exists, but no active exploitation has been confirmed (not in CISA KEV). The impact is limited to integrity manipulation as assessed at CVSS 5.3 (CWE-862).
Authenticated users of JeecgBoot through 3.9.5 can read other users' stored AI chat variables through an insecure direct object reference in AiragBaseApiController's /airag/api/getChatVariable endpoint, which trusts a caller-supplied username parameter instead of the authenticated principal. Exploitation requires a valid JeecgBoot account (CVSS 4.0 PR:L) and a deployment that actively uses the AIRAG chat feature with chat variables persisted in Redis, and the attacker must know or enumerate the target appId, victim username, and variable name; impact is confined to confidentiality of chat memory values with no write, integrity, or code-execution effect, and installations not using AIRAG are not exposed. Publicly available exploit code exists (a PoC is published on GitHub), but there is no evidence of confirmed active exploitation, and the moderate CVSS score of 5.3 reflects the authentication prerequisite and limited read-only impact.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated, low-privileged user to read the AI application configurations of other users by invoking the AiragAppController queryById handler with arbitrary application ids. The companion /airag/app/listDict endpoint lacks its own access control and can be walked to enumerate valid application ids, each of which then discloses system prompts, memory prompts, model ids, knowledge base ids, and plugin bindings belonging to other users. Publicly available exploit code exists (a Python proof-of-concept), and the issue is not listed in CISA KEV as actively exploited; with the assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (5.3), this is a genuine but moderate-severity, read-only information-disclosure problem rather than a critical priority.
Missing authorization checks in JeecgBoot's AiragPromptsController (all releases through 3.9.5) let any authenticated user, even one at the lowest privilege level, delete AI prompt templates belonging to other users by calling DELETE /airag/prompts/delete. Because the companion GET /airag/prompts/list endpoint performs no authorization at all, an attacker can first enumerate valid prompt template IDs and then trigger a logical (soft) deletion, making those templates unavailable to every user on the instance. Publicly available exploit code exists, but there is no indication of confirmed active exploitation; the assessed impact is confined to integrity and availability of prompt-template objects (CVSS 3.1 base 5.3, PR:L, AV:N), with no confidentiality exposure and no system-level compromise, making this a genuine but low-to-moderate priority issue.
Missing authorization in the putCancelQuit handler of SysUserController in JeecgBoot through version 3.9.5 lets any authenticated low-privileged user supply arbitrary user ids together with a tenantId parameter or X-Tenant-Id header and reverse user resignations, restoring ended, pending, or refused tenant memberships to normal. Publicly available exploit code exists (a Python PoC is published on GitHub), and the flaw is confirmed reachable by any logged-in account rather than anonymously. Impact is limited to tenant-membership integrity with no confidentiality or availability effect, making this a genuine-but-moderate access-control issue rather than a top-tier priority; no public exploit identified at time of analysis as actively exploited, and KEV status is not indicated.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user - including a low-privileged one - to add arbitrary accounts to administrator-maintained user groups by sending a POST request containing target user ids and a groupId to the SysUserController addSysUserGroup handler, which performs no permission check. Impact is integrity-only at moderate severity: attacker-controlled group membership changes, with no confidentiality or availability effect on the platform itself. Publicly available exploit code exists, and there is no CISA KEV listing, so confirmed active exploitation in the wild has not been observed at time of analysis.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user - regardless of privilege level - to reassign or remove department heads by sending a PUT request to /sys/user/changeDepartChargePerson with arbitrary user, department, and status values. Attackers must already hold a valid low-privilege account (CVSS PR:L) and network reachability to the endpoint, so this is an authenticated authorization flaw (CWE-862) rather than a pre-auth or remote-code issue; the impact is limited to integrity of department-head assignments (CVSS 4.0 base 5.3, assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) and the department-scoped data visibility that follows. Publicly available exploit code exists (a Python PoC published on GitHub and referenced by VulnCheck), but there is no CISA KEV entry indicating confirmed active exploitation; no vendor-released patch version is identified in the available data.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, including one holding only a basic low-privileged role, to rename, re-parent, or strip the department heads from any department via a PUT request to /sys/user/doUpdateDepartInfo. The endpoint applies no ownership or tenant checks, so an attacker with a valid session - obtainable through self-registration or any default user role - can tamper with organizational structure across tenants without any elevated privilege. Publicly available exploit code exists (a Python PoC published on GitHub), and the vendor has not released a confirmed fixed version at time of analysis; the flaw is rated moderate (CVSS 3.1 base 5.3, integrity-only impact) and there is no public evidence of active exploitation.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated account - including the lowest-privileged user - to reassign users between departments and overwrite their positions by sending PUT requests to /sys/user/batchEditUsers with arbitrary user and department IDs. Because the SysUserController batchEditUsers handler performs no permission check, an attacker can move administrators into attacker-chosen departments and tamper with organizational metadata, but the assessed impact is integrity-only (CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N; vendor-scored CVSS 4.0 5.3) with no data disclosure or service disruption. Publicly available exploit code exists in a public GitHub repository, though the issue is not confirmed actively exploited (CISA KEV), and the authentication prerequisite keeps overall risk moderate rather than emergency-grade.
Missing authorization in the saveDatarule handler of JeecgBoot's SysDepartRoleController (all versions through 3.9.5) allows any authenticated low-privileged user to overwrite department-role data-rule mappings, widening row-level data access or altering query filtering for roles they do not legitimately administer. The flaw is reachable over the network with only ordinary authenticated access (PR:L, no user interaction) by posting crafted permissionId, roleId and dataRuleIds values to the save-datarule endpoint; impact is limited to confidentiality and integrity of data-rule scope, not code execution or account takeover, which is consistent with the moderate 5.3 score. Publicly available exploit code exists (a Python PoC is published alongside the CVE), though no CISA KEV entry or active-exploitation confirmation was provided, and the realistic risk is highest in deployments where low-privileged or self-registered accounts are widely available.
An authorization weakness in JeecgBoot through 3.9.5 lets any authenticated low-privileged user overwrite role-level data rules through the SysRoleController saveDatarule handler, clearing row-level filters so records normally hidden from that role become readable, or changing the filtering applied to other roles. Exploitation requires network reachability to the saveDatarule endpoint and a valid low-privileged session (PR:L) with no user interaction, and publicly available exploit code exists in the form of a Python PoC (poc_role_datarule_write.py) that posts permissionId, roleId and dataRuleIds values. Impact is bounded to data-rule and row-level filter manipulation with low confidentiality and integrity loss rather than code execution or administrative takeover, giving a moderate assessed severity (CVSS 3.1 5.3); risk concentrates on deployments that issue low-trust accounts or expose the application to many users.
JeecgBoot versions through 3.9.5 expose the POST /sys/api/sendSysAnnouncement endpoint without any authorization check, allowing any authenticated low-privilege user to craft and broadcast system announcements with attacker-controlled title, content, fromUser and toUser values to arbitrary recipients over WebSocket, WeCom, DingTalk and Feishu. The flaw is a missing-authorization issue (CWE-862) rated 5.3 in CVSS 4.0 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N per the independent assessment), and its practical impact is limited to forged, potentially phishing-style or misinformation messages rather than data theft or code execution. A public proof-of-concept script targeting the endpoint exists, making exploitation straightforward for anyone holding a valid low-privilege account, though there is no indication of confirmed active exploitation (CISA KEV is not referenced) and no EPSS score was supplied.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user publish templated system announcements to arbitrary recipients via POST /sys/api/sendBusTemplateAnnouncement. A low-privileged attacker can supply templateCode, toUser and a forged fromUser to push spoofed notifications through WebSocket, DingTalk, WeCom, Feishu and UniPush channels, an integrity-only impact (CVSS 5.3, CWE-862) that requires a valid session but no user interaction. Publicly available exploit code exists, though no active exploitation has been confirmed (the issue is not listed in CISA KEV).
JeecgBoot through 3.9.5 contains a missing-authorization flaw in SystemApiController's getUserRoleSetById handler that lets any authenticated low-privileged user read other users' assigned role codes by supplying an arbitrary userId. The endpoint skips the system:user:queryUserRole permission check, so an attacker can enumerate role assignments and identify administrator accounts without that permission; publicly available exploit code exists. Impact is limited to information disclosure (no modification or direct account takeover), and the issue is rated moderate with a CVSS 5.3 input vector requiring a valid session.
JeecgBoot through 3.9.5 contains a missing authorization flaw in the sys/api queryUserAuths handler that lets any authenticated user retrieve the complete permission set of an arbitrary account by supplying an attacker-chosen userId parameter. This allows low-privileged attackers to map out administrator accounts and their permissions, though it does not permit modification or service disruption (CVSS 4.0 score 5.3; independent assessment CVSS 3.1 score 5.3). Publicly available exploit code exists (no CISA KEV confirmation), and exploitation requires a valid authenticated session at any privilege level.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated, low-privileged user send spoofed template announcements by POSTing to /sys/api/sendTemplateAnnouncement with attacker-chosen sender, recipient, title, and template parameters, so the resulting messages appear to come from admin or system accounts. Rated 5.3 (medium), the issue carries only low integrity impact with no confidentiality or availability effect and no path to code execution, and it requires the attacker to already hold a valid JeecgBoot session. Publicly available exploit code exists (VulnCheck-reported POC plus a GitHub PoC script), though there is no indication of confirmed active exploitation.
JeecgBoot through 3.9.5 allows any authenticated low-privileged user to send spoofed system announcements via the /sys/api/sendBusAnnouncement endpoint because SystemApiController does not enforce the required permission check. An attacker can forge the sender, recipients, title, and content to impersonate administrators or the system, enabling phishing against other users. No code execution, data disclosure, or service disruption is possible, and publicly available exploit code exists; this is a low-severity authorization flaw rather than a remotely exploitable unauthenticated compromise.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated low-privileged user read arbitrary users' role codes by sending GET requests to /sys/api/queryUserRoles with an arbitrary username parameter, allowing role-assignment discovery and identification of administrator accounts. The issue is tracked as CWE-862 (missing authorization) with an assessed CVSS of 5.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:N/C:L/I:N/A:N), requiring only a valid JeecgBoot account of any privilege level; impact is confined to information disclosure rather than write or execution capability. Publicly available exploit code exists for this endpoint, but there is no indication of confirmed active exploitation (CISA KEV); the endpoint is exploitable in default deployments with no special configuration, making the authentication requirement the primary limiting factor.
Missing authorization in the JeecgBoot SysAnnouncementController downLoadFiles handler lets any authenticated low-privileged user retrieve a ZIP of announcement attachments by supplying a valid announcement id, exposing files from unpublished announcements or announcements addressed only to other users. The flaw affects JeecgBoot through version 3.9.5 (CPE cpe:2.3:a:jeecgboot:jeecgboot:*), requires a valid non-admin account and knowledge or enumeration of an announcement id, and yields only confidentiality impact with no write, execution, or availability effect. Publicly available exploit code exists (a Python PoC script published on GitHub) but there is no confirmed active exploitation (not listed in CISA KEV), so this is a medium-severity information-disclosure issue rather than a critical priority.
Missing authorization in the SysAnnouncementController editIzTop handler of JeecgBoot through 3.9.5 allows any authenticated user at a low privilege level to pin or unpin system-wide announcements by sending a POST or PUT request carrying an arbitrary announcement id. The root cause is a pure access-control failure (CWE-862), not a memory or injection flaw, so the practical impact is limited to tampering with the pinned-notice banner displayed to all users, with no data disclosure, code execution, or service disruption. Publicly available exploit code exists and the issue was reported by VulnCheck, but the assessed severity is modest (CVSS 3.1 score 5.3, PR:L) because an attacker must already hold valid credentials and the resulting integrity change is low.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to read OpenAPI gateway definitions they are not entitled to see, exposing internal origin URLs, virtual paths, IP whitelists, and header and parameter templates. The flaw (CWE-862) lives in the OpenApiController queryById handler, which fails to enforce the openapi permission, so a simple GET /openapi/queryById with a valid entry id returns configuration metadata. It is a moderate-severity issue (CVSS 5.3, PR:L, confidentiality-only impact) for which publicly available exploit code exists, but there is no indication of confirmed active exploitation and the CVE is not in CISA KEV.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user - including low-privileged accounts - download every user's stored AI prompts by calling the /airag/prompts/exportXls endpoint. The response is an Excel workbook exposing prompt content, model IDs, and parameters belonging to all users, a moderate-severity information disclosure rather than a critical code-execution issue. Publicly available exploit code exists (a PoC script targets this handler), though there is no confirmed evidence of active exploitation (no CISA KEV listing), and exploitation is gated solely on possession of any valid low-privilege session.
JeecgBoot through 3.9.5 contains an authorization bypass (CWE-639) in the AIRAG video-generation module, where an authenticated low-privileged user can read other users' AI video-generation history by supplying an arbitrary userId to the getVideoRecords handler in VideoGenerationController. Publicly available exploit code exists, and the disclosed records include prompts, task IDs, video URLs, and cover URLs; however, there is no write access or broader compromise, and exploitation requires the AIRAG video feature to be deployed and the attacker to already hold a valid account. The issue is a moderate-severity information-disclosure bug (CVSS 4.0 5.3; independent CVSS 3.1 assessment 5.3) rather than a top-tier priority.
Missing authorization in JeecgBoot's AIRAG prompts module (through version 3.9.5) lets any authenticated, low-privileged user invoke the promptExperiment handler in AiragPromptsController and launch AI prompt evaluation runs against prompt templates and datasets that belong to other users. Because the handler performs no ownership or permission check on the supplied prompt-template and dataset IDs, an attacker who can enumerate or guess those identifiers can write result rows into the airag_ext_data table and alter dataset status, an integrity-only impact with no confidentiality or availability loss. Exploitation requires a valid low-privileged account plus an instance where the AIRAG module is deployed with a working LLM backend; publicly available exploit code exists, but there is no confirmed active exploitation (no CISA KEV listing) and the issue is rated moderate rather than critical.
Missing authorization in JeecgBoot's AiRAG knowledge module lets low-privileged authenticated users read document text chunks from knowledge bases they do not own. The embeddingSearch handler in AiragKnowledgeController (GET /airag/knowledge/embedding/search) lacks Shiro permission annotations, so any valid account can pass arbitrary knowledge base IDs and retrieve indexed content belonging to other users or tenants. Exploitation is remote and requires authentication (CVSS:4.0 PR:L, assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), impact is limited to confidentiality, and publicly available exploit code exists (a Python PoC targeting the data plane); no confirmed active exploitation has been reported. This is a genuine but moderate-severity issue, not a top-tier emergency.
Permanent deletion of other users' recycled AI prompt templates is possible in JeecgBoot through 3.9.5 because the AiragPromptsController deleteRecycleBin handler performs no authorization check. Any authenticated user - including the lowest-privileged account, since the assessed vector is PR:L - can issue a DELETE request carrying arbitrary prompt-template IDs and purge recycle-bin entries that belong to administrators or other tenants; no admin role, user interaction, or special configuration is needed beyond the AIRAG module being present. Publicly available exploit code exists (a PoC script targeting this endpoint), though there is no confirmed active exploitation (not in CISA KEV). Our independent assessment rates this as medium severity (CVSS:3.1 5.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) and a low-real-world-priority issue: integrity-only impact confined to deletion of soft-deleted template records, with no confidentiality exposure, no code execution, and fully unauthenticated outsiders unable to exploit it.
Missing authorization in JeecgBoot through 3.9.5 allows a low-privileged authenticated user to undo administrator deletions of AI prompt templates by sending crafted PUT requests to the /airag/prompts/revertRecycleBin endpoint with chosen template IDs, clearing the deleted flag and returning them to active use. Because the endpoint performs no permission check, any account with a valid session - not just an administrator - can restore recycled content; publicly available exploit code exists, though exploitation still requires credentials (CVSS PR:L) and knowledge of valid deleted-template IDs, and the impact is limited to an integrity change on prompt template records with no confidentiality or availability effect. Per our independent assessment this is a genuinely low-severity, low-priority issue: it is not exploitable by unauthenticated attackers, requires no user interaction, and cannot be used to read data, escalate privileges, or disrupt the platform.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, regardless of role, to delete administrator-created AI prompt templates through the deleteBatch handler of AiragPromptsController. The unguarded list endpoint lets a low-privileged attacker enumerate prompt IDs and feed them to deleteBatch, destroying templates belonging to admins or other tenants; exploitation requires only a valid account (CVSS vector PR:L) and no user interaction or elevated role. Publicly available exploit code exists (a PoC script targeting the deleteBatch endpoint has been published), but there is no confirmation of active exploitation in the wild, and the practical risk is concentrated in multi-tenant or self-registering deployments where low-privileged accounts coexist with administrator content.
Tampering with AI prompt templates in JeecgBoot through 3.9.5 is possible for any authenticated user due to missing authorization in the AiragPromptsController edit handler. A low-privileged attacker can send PUT or POST requests to /airag/prompts/edit with a target template id to overwrite prompt text and model parameters created by administrators or other users, resulting in integrity-only impact. Publicly available exploit code exists, though no active exploitation has been confirmed; CVSS 5.3 (medium).
JeecgBoot versions through 3.9.5 contain a missing authorization flaw in the AiragPromptsController that lets any authenticated user read AI prompt templates belonging to other users, including administrators. Attackers can enumerate prompt IDs through the unguarded /airag/prompts/list endpoint and then retrieve each template's text, model parameters, and creator details via queryById, resulting in unauthorized information disclosure. Publicly available exploit code exists, but the issue requires a valid account and the AIRAG module to be deployed, making it a modest-severity confidentiality risk rather than a critical one.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated, low-privileged user delete pending tenant-administrator applications belonging to other tenants via the SysTenantController deleteApply handler, which also sends rejection notifications to the affected applicants. Publicly available exploit code exists, though exploitation requires a valid low-privileged account plus valid or enumerable tenantId, packId and userId values for a pending application. Impact is limited to integrity of the tenant-onboarding workflow with no data disclosure or service outage, making this a genuine but moderate issue rather than a top-priority one.
Missing authorization in JeecgBoot 3.9.5 and earlier allows any authenticated low-privileged user to remove arbitrary users from any tenant's product pack by sending attacker-controlled userId and packId values to PUT /sys/tenant/deleteTenantPackUser, silently revoking assigned permissions such as tenant administrator access. Exploitation requires only a valid low-privileged account (PR:L per the assessed CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) on an instance running in multi-tenant mode with tenant product packs configured, and publicly available exploit code exists, though there is no confirmed active exploitation (CISA KEV). The impact is confined to integrity and availability of permission assignments - no confidentiality exposure and no code execution - making this a genuine but moderate-priority issue rather than a top-tier emergency.
Missing authorization in JeecgBoot (all versions through 3.9.5) lets any authenticated, low-privileged user alter tenant administrator application status for arbitrary tenants by sending a PUT request to /sys/tenant/updateApplyStatus with a tenant id they do not own. The endpoint performs no ownership or role check on the supplied identifier, so an ordinary account - including one obtained through self-registration - can toggle the applyStatus field and thereby enable or disable tenant-admin applications across the entire instance. Publicly available exploit code exists (a Python PoC is published in a public GitHub repository), though this is not confirmed as actively exploited in the wild; EPSS and KEV data were not provided, and the independent assessment rates this as a moderate-severity broken access control issue with limited blast radius, since impact is confined to status toggling rather than full tenant takeover.
An authenticated low-privileged user on JeecgBoot through 3.9.5 can query any tenant's product-pack configuration by calling the SysTenantController listPackByTenantUserId handler with attacker-chosen tenantId and userId parameters, because that handler performs no authorization check on the caller's ownership of the requested tenant. The result is read-only disclosure - tenant pack settings plus the identities of users who are tenant administrators - which is useful for reconnaissance and privilege-mapping but causes no data modification or service disruption (CVSS 5.3 / CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N). Publicly available exploit code exists in a GitHub proof-of-concept repository, and exploitation is meaningful only in multi-tenant deployments where other tenants exist to enumerate; there is no confirmation of active exploitation (CISA KEV) at time of analysis.
Missing authorization in JeecgBoot's SysTenantController queryTenantAuthInfo handler (all versions through 3.9.5) allows any authenticated, low-privileged user to enumerate small integer tenant IDs and read other tenants' full sys_tenant records, including house numbers used as tenant join codes and company profile fields. Exploitation requires a valid authenticated account (CVSS vector PR:L) on a multi-tenant deployment where other tenants' records exist; publicly available exploit code exists, but there is no confirmation of active exploitation. The impact is limited to read-only information disclosure (CVSS 5.3, assessed as C:L/I:N/A:N), making this a moderate access-control issue rather than a high-urgency flaw.
Information disclosure in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to read tenant administrator applications for any tenant by iterating the tenantId parameter on the /sys/tenant/getTenantPackApplyUsers endpoint. Public exploit code exists, but exploitation requires a valid account and a multi-tenant deployment with pending applicants; the impact is limited to read-only disclosure of applicant PII (usernames, real names, phone numbers, departments) with no write or availability effect. This medium-severity issue is confirmed by an independent assessment as an information-disclosure flaw, not a critical priority.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated low-privileged user read scheduled-job records - class names, cron expressions, job parameters and status - by issuing GET /sys/quartzJob/queryById with a job id, data otherwise reserved for administrators. Publicly available exploit code exists (no CISA KEV entry), and the issue carries a CVSS 5.3 score with an independently assessed vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, so impact is confined to confidentiality of job metadata with no write, code-execution or denial-of-service capability. Treat this as a genuine but bounded-severity issue at low-to-moderate priority: exploitation requires a valid low-privileged account against a network-reachable instance and yields only information disclosure that may assist further attacks.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to read object storage file records via the OssFileController queryById handler (GET /sys/oss/file/queryById), exposing original file names and direct storage URLs of other users' uploads. Publicly available exploit code exists, though the issue requires a valid authenticated account and knowledge of a target record ID, which appears enumerable. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) indicates modest confidentiality impact, and no active exploitation (CISA KEV) is confirmed.
JeecgBoot through 3.9.5 exposes an authorization gap in the OpenApiController.queryPageList handler, letting any authenticated user - including a low-privileged one - retrieve the OpenAPI registry listing via GET /openapi/list and read virtual paths, internal origin URLs, IP whitelists, and header/parameter templates meant for administrators. Exploitation requires only a valid, non-admin JeecgBoot session (CVSS PR:L) and publicly available exploit code exists, though no active exploitation has been confirmed via CISA KEV; the CVSS 3.1 assessment scores it 5.3 as a read-only confidentiality disclosure with no integrity or availability impact, and EPSS data was not provided. The practical risk is moderate: the leak itself does not grant code execution, but it hands an attacker the internal routing and gateway configuration needed to plan follow-on attacks against otherwise hidden backend services.
JeecgBoot through 3.9.5 permits any authenticated low-privileged user to alter another user's avatar, including an administrator's, by sending a PUT request with an arbitrary target user ID and avatar value to the SystemApiController updateAvatar endpoint. The independent assessment rates this as a low-to-moderate priority authenticated integrity-check failure: network reachable, low privileges required, no user interaction, and only low impact to avatar data with no confidentiality or availability loss. Publicly available exploit code exists, but no CISA KEV active exploitation is indicated.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, including a low-privileged one, to read the role codes of arbitrary accounts by supplying a chosen userId to the endpoint GET /sys/api/getRolesByUserId. The flaw is a CWE-862 absence of an ownership or permission check in the getRolesByUserId handler of SystemApiController, so a valid session - not administrative rights - is the only prerequisite. Impact is limited to information disclosure useful for reconnaissance (identifying administrator accounts and mapping role assignments), with no write or availability effect; publicly available exploit code exists, and EPSS/KEV data indicate no confirmed active exploitation at time of analysis.
Missing authorization in the JeecgBoot SystemApiController.getUserPermissionSet handler (JeecgBoot through 3.9.5) lets any authenticated low-privileged user read the full permission code set of any other account, including administrators, by passing an arbitrary userId to GET /sys/api/getUserPermissionSet. The handler never verifies that the requester is entitled to read the supplied user's permissions, so exposure is limited to confidentiality of permission codes rather than modification or account takeover. Publicly available exploit code exists (a Python PoC is published alongside the VulnCheck advisory), but there is no indication of confirmed active exploitation (CISA KEV) at time of analysis; the practical barrier is the requirement for a valid login, which restricts realistic abuse to insiders, compromised accounts, or instances permitting self-registration or guest accounts. Impact is rated low on confidentiality (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) with no integrity or availability effect.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user to read arbitrary accounts' role codes by supplying a userId to the queryUserRolesById handler of SystemApiController, enabling enumeration of role assignments and identification of administrator accounts. Exploitation requires only a valid low-privilege session (CVSS 4.0 vector shows PR:L, no user interaction) and publicly available exploit code exists, while there is no evidence of confirmed active exploitation (no CISA KEV listing in the provided data). Because the flaw is limited to confidentiality with no modification or availability impact, it is a genuine but low-to-moderate priority disclosure issue rather than a critical emergency.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to bypass the system:checkRule:add permission check in the SysCheckRuleController importExcel handler and bulk-create system-wide encoding validation rules from a crafted Excel workbook. Publicly available exploit code exists (a Python PoC published on GitHub), though there is no confirmed active exploitation (CISA KEV) and no EPSS score was supplied; the CVSS v4.0 base score is 5.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) and our independent assessment rates it as a medium-severity, lower-tier priority issue rather than an urgent emergency. Exploitation requires a valid low-privileged account (PR:L), so exposure is highest where JeecgBoot is internet-facing or where self-registration or weak account provisioning is enabled; impact is confined to the integrity of validation rules, with no direct data disclosure or service outage.
Missing authorization in the SysCategoryController importExcel handler of JeecgBoot through 3.9.5 allows any authenticated user - of any privilege level - to bulk-insert arbitrary nodes into the system-wide sys_category dictionary by uploading a crafted Excel workbook. Because the endpoint lacks a role or permission check, a low-privileged account can add entries, including under existing parent nodes, tampering with a shared configuration dictionary; the impact is limited to integrity (no confidentiality or availability loss per the CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N assessment), and the primary limiter is that a valid login is required, so unauthenticated outsiders cannot exploit it. Publicly available exploit code exists and the issue is referenced by VulnCheck, but there is no indication of confirmed active exploitation (CISA KEV), and no vendor-released patch was identified at time of analysis.
Missing authorization in JeecgBoot's SysCategoryController (through version 3.9.5) lets any authenticated user, including a low-privileged one, rename, recode, or move system-wide sys_category dictionary nodes by sending POST or PUT requests with a node id to /sys/category/edit, corrupting classification values that are consumed across forms and other application features. Publicly available exploit code exists and the issue is tracked by VulnCheck, but no evidence of confirmed active exploitation (CISA KEV) was provided. With PR:L in both the vendor CVSS 4.0 vector (5.3) and the independent CVSS 3.1 assessment, impact is confined to integrity of shared reference data - no confidentiality or availability effect - and the need for a valid session plus a known or enumerable node id keeps this a moderate-priority issue rather than a high-impact one.
Authenticated users on JeecgBoot through 3.9.5 can delete arbitrary sys_category dictionary nodes through the SysCategoryController delete handler, which performs no permission check, allowing low-privileged accounts to remove entire category subtrees and break dependent forms and dictionary-backed fields. The node identifiers needed for the attack are freely exposed by the unguarded rootList and childList endpoints, so no special configuration or elevated role is required - only a valid login, meaning the practical barrier is simply obtaining any account (publicly available exploit code exists, per a linked GitHub PoC). The independent assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L - a medium-severity, authorization-only flaw whose impact is bounded to integrity and availability of dictionary data, with no confidentiality exposure and no code execution; the reported CVSS 5.3 is consistent with that view.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to destroy the platform's sys_category dictionary data by calling DELETE /sys/category/deleteBatch, an endpoint that performs the deletion without verifying the caller holds permission for that operation. The companion rootList and childList endpoints are equally unguarded, so the same user can enumerate node ids and submit them to recursively delete whole sys_category subtrees, breaking dependent forms and dictionary fields across the instance. Publicly available exploit code exists (a Python PoC that drives the console delete route), but the issue is a moderate data-loss/denial-of-function condition rather than a critical one: an account is required, impact is limited to integrity and availability of dictionary data, and there is no confidentiality exposure or code execution.
JeecgBoot versions through 3.9.5 expose an authorization gap in SysAnnouncementSendController that lets any authenticated user tamper with other users' announcement delivery records, overwriting read flags, recipient identifiers, or the linked announcement so that messages are hidden from the intended recipients. Exploitation requires a valid low-privileged account and reachability to the standard GET /sys/sysAnnouncementSend/list and PUT /sys/sysAnnouncementSend/edit endpoints, which ship enabled in default deployments; no user interaction or special configuration is needed. Publicly available exploit code exists (a PoC script published in a public GitHub repository), and VulnCheck is credited with reporting it, but there is no evidence of confirmed active exploitation (not in CISA KEV). Impact is integrity-only against message-delivery data, with no confidentiality or availability effect, giving moderate severity (CVSS 4.0 base 5.3; independently assessed as CVSS 3.1 5.3, PR:L).
Authenticated insecure direct object reference in JeecgBoot through 3.9.5 allows any logged-in user to read other users' in-application announcement messages by passing an attacker-chosen sendId to the getOne handler of SysAnnouncementSendController. Valid delivery-record identifiers are trivially harvested from the unguarded /sys/sysAnnouncementSend/list endpoint, after which getOne returns message titles, bodies, senders and recipients without any ownership check, producing a confidentiality-only impact with no write or availability effect (CVSS 4.0 base 5.3; assessed CVSS 3.1 5.3, AV:N/AC:L/PR:L/UI:N). Exploitation requires a valid low-privileged account but no special configuration or user interaction; publicly available exploit code exists in the form of a published GitHub proof-of-concept script, and there is no KEV confirmation of active exploitation, so this should be treated as a moderate-priority, exploitation-ready information-disclosure issue rather than a system-compromise flaw.
Missing authorization in the JeecgBoot SysDepartRole queryById handler (all versions through 3.9.5) lets any authenticated user - regardless of department scope - read department-role metadata such as role names, codes, descriptions, and audit fields by issuing GET /sys/sysDepartRole/queryById with an arbitrary id value. Exploitation requires only a valid low-privileged session on a reachable JeecgBoot system API, so it is not exploitable by fully unauthenticated outsiders, and publicly available exploit code exists, making the flaw trivially reproducible for anyone holding basic account credentials. The impact is limited to read-only disclosure of role metadata with no write or availability effect, consistent with the assessed CVSS 4.0 score of 5.3 (Medium) and CWE-862 (Missing Authorization).
Authenticated users of JeecgBoot through 3.9.5 can permanently delete data dictionaries and all of their items by sending DELETE requests to /sys/dict/deletePhysic/{id}, because the deletePhysic handler in SysDictController omits an authorization check (CWE-862); the hard delete bypasses the recycle bin and is irreversible. Any valid low-privilege account suffices - no administrator role, user interaction, or non-default configuration is required, only network access to the application and knowledge or enumeration of a target dictionary {id}. Publicly available exploit code exists, but there is no indication of confirmed active exploitation, and the impact is confined to integrity and availability of dictionary data (no confidentiality exposure or code execution), making this a moderate-severity insider or compromised-account threat.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to remove arbitrary users from administrator-maintained groups by sending DELETE requests with manipulated groupId and userId parameters to the SysUserController's deleteGroupUser handler. This broken-access-control flaw (CWE-862) has modest impact-only group membership integrity is affected, not code execution or data theft-and publicly available exploit code exists. Exploitation requires a valid account of any privilege level and network access to the API; no special configuration is needed, making multi-tenant deployments particularly at risk.
Missing authorization in JeecgBoot through 3.9.5 lets any low-privileged authenticated user silently remove members from administrator-maintained user groups by calling DELETE /sys/user/deleteUserGroupBatch with an arbitrary groupId and a comma-separated list of userIds. The endpoint performs no permission or tenant-isolation check before deleting rows from sys_ugroup_user, so the impact is limited to integrity tampering with group membership rather than data disclosure or denial of service; publicly available exploit code exists (a PoC script is published), and no confirmed vendor patch was identified at time of analysis. Successful exploitation requires a valid authenticated session at any privilege level (PR:L in both the reported CVSS 4.0 vector and our assessed CVSS 3.1 vector), meaning fully unauthenticated attackers cannot exploit it, and no CISA KEV listing or confirmed active exploitation is associated with this issue.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, regardless of role, to upload a crafted Excel workbook to POST /sys/sysDepart/appImportExcel and create arbitrary sys_depart records in the administrator-maintained department tree. Exploitation requires only a valid low-privilege session with network reachability to the endpoint, and publicly available exploit code exists; however, the impact is confined to integrity (CVSS 3.1 base 5.3, PR:L, I:L, C:N, A:N), with no code execution, data disclosure, or service disruption possible from this flaw alone. This is a medium-severity, lower-priority issue in practice that matters mainly where low-privilege accounts are freely provisioned.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user - regardless of privilege level (CVSS vector PR:L) - enumerate department personnel via the GET /sys/sysDepart/getDepartmentHead endpoint of SysDepartController, disclosing staff names, avatars, posts, and mobile and telephone numbers, including records explicitly marked hidden, simply by iterating the departId parameter. Publicly available exploit code exists in the form of a proof-of-concept script targeting the endpoint, but the impact is confined to confidentiality of directory/contact data at CVSS 5.3 with no write, code-execution, or availability effect, and no non-default configuration is needed to reach the vulnerable code path. This is a moderate-severity information-disclosure issue rather than an urgent, actively exploited one.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated low-privileged user delete department permission bindings through the DELETE /sys/sysDepartPermission/deleteBatch endpoint, silently stripping the menus and buttons a department can grant to its roles. Exploitation requires only a valid low-privileged session (CVSS vector PR:L) with no admin rights and no user interaction, because the companion list endpoint is also unguarded and exposes the row ids that must be submitted in the ids parameter. Publicly available exploit code exists, including a published Python PoC, and no confirmed active exploitation is reported in the available intelligence sources; with integrity and availability impact limited to permission records and no confidentiality loss, this is a moderate-risk authenticated authorization flaw rather than a critical one.
JeecgBoot through 3.9.5 exposes the POST /sys/sysDepartPermission/add endpoint without any authorization check, so any low-privileged authenticated user can create department-permission bindings and attach menu, button, and data-rule grants to arbitrary departments by supplying their own departId, permissionId, and dataRuleIds values. Because the flaw is a missing-authorization issue (CWE-862) rated 5.3 with an assessed CVSS:3.1 vector of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, impact is limited to integrity and exploitation requires a pre-existing account plus a department context whose roles will actually delegate the injected grants. Publicly available proof-of-concept exploit code exists, making the issue practically reproducible, but there is no confirmed active exploitation (CISA KEV) at time of analysis.
Low-privileged authenticated users of JeecgBoot through 3.9.5 can read department permission records they should not be authorized to see by issuing GET requests to /sys/sysDepartPermission/queryById with an arbitrary department id, exposing depart_id, permission_id and data_rule_ids values. The flaw is a missing authorization check in the SysDepartPermissionController queryById handler (CWE-862), rated 5.3 with an assessed vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, so exploitation is limited to confidentiality impact and requires only a valid account with no administrative role. Publicly available exploit code exists (a Python PoC published by VulnCheck-referenced researchers), and the issue is not listed in CISA KEV as actively exploited; EPSS data was not provided, so no exploitation-likelihood estimate can be cited.
Authenticated low-privileged users can delete department permission bindings in JeecgBoot through 3.9.5 by calling the SysDepartPermissionController delete handler, which performs no authorization check (CWE-862). Because the corresponding list endpoint is also unguarded, an attacker can enumerate the required row ids and then issue DELETE requests that strip menu and button grants from department roles, degrading the instance's RBAC configuration. Publicly available exploit code exists, and the flaw affects default deployments, but the impact is bounded to integrity/availability of permission data - no data disclosure and no privilege escalation beyond RBAC degradation - which is why the vendor score is a moderate 5.3.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, including low-privileged accounts, to overwrite department permission records through the unprotected edit (PUT) endpoint of SysDepartPermissionController, changing depart_id, permission_id and data_rule_ids values that control which menus and data rules departments may delegate. A companion list endpoint is likewise unguarded, so attackers can enumerate valid record ids before issuing the modification requests. Publicly available exploit code exists (no confirmed active exploitation), and the flaw is rated moderate - CVSS 4.0 base 5.3 with integrity-only impact - requiring only a valid authenticated account of any privilege level per the CVSS vector (PR:L).
Any authenticated JeecgBoot user - regardless of privilege level - can add, modify or clear department data-rule bindings by POSTing departId, permissionId and dataRuleIds to /sys/sysDepartPermission/datarule, because the saveDatarule handler in SysDepartPermissionController performs no authorization check, in versions through 3.9.5. Publicly available exploit code exists, but no active exploitation is confirmed (not in CISA KEV). With a CVSS 5.3 rating reflecting network reachability, low privileges required and only low integrity impact, realistic risk concentrates in multi-department or multi-tenant deployments where untrusted low-privilege accounts exist.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user read role data-rule metadata - rule names, columns, conditions, values and bound rule IDs - for arbitrary roles via GET /sys/role/datarule/{permissionId}/{roleId}. The loadDatarule handler in SysRoleController omits the authorization check that its sibling endpoints enforce, so a low-privileged account (PR:L, unauthenticated access does not work) can enumerate permissionId/roleId pairs and exfiltrate the row-level access-control policy of the whole tenant. Impact is information disclosure only (CWE-862, no write, no code execution); publicly available exploit code exists, and the CVE is not in CISA KEV.
Missing authorization in JeecgBoot's SysMessageController queryById handler (all versions through 3.9.5) lets any authenticated user, at any privilege level, read the message push records of other accounts by supplying arbitrary record IDs to GET /sys/message/sysMessage/queryById, exposing message content and receiver addresses. The impact is read-only information disclosure - no integrity or availability effect - and exploitation requires a valid low-privileged session plus knowledge or enumeration of valid message record IDs, making this a moderate-risk IDOR rather than a pre-authentication compromise path (CVSS 4.0 base 5.3; independently assessed CVSS 3.1 5.3, PR:L, C:L). Publicly available exploit code exists (a Python PoC linked from the VulnCheck advisory), but there is no confirmation of active exploitation (CISA KEV).
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user holding a low-privileged account to overwrite arbitrary message-push records by sending a PUT request to /sys/message/sysMessage/edit with any sys_sms record id in the body, changing the record's title, content, receiver address and send status without any ownership check. The flaw is confined to integrity tampering of message records - there is no confidentiality or availability impact - and exploitation requires a valid account plus network reachability to the application's REST API, so unauthenticated attacks are not possible. Publicly available exploit code exists, making the issue straightforward to reproduce, but active exploitation has not been confirmed and no vendor-released patch was identified at time of analysis.
Deletion of arbitrary message records in JeecgBoot through 3.9.5 is possible by low-privileged authenticated users due to missing authorization in the SysMessageController deleteBatch handler. Attackers can obtain record IDs from an unguarded list endpoint and submit them to deleteBatch to remove pending queued messages, disrupting notification delivery. Publicly available exploit code exists, but the vulnerability is not listed in CISA KEV, and the CVSS 4.0 score is 5.3, indicating moderate severity.
Authenticated, low-privileged users of JeecgBoot through 3.9.5 can delete arbitrary audit log records because the SysLogController delete handler performs no authorization check, allowing an attacker holding any valid login to erase traces of their activity. Log identifiers are freely obtainable from the unguarded /sys/log/list endpoint, so the attack needs no elevated role, only a session. Publicly available exploit code exists (a Python PoC for the log-delete request), and the impact is limited to integrity and availability of log data with no confidentiality exposure.
Missing authorization in the JeecgBoot SysPositionController edit handler (/sys/position/edit) lets any authenticated low-privileged account rewrite organizational position names, codes, and ranks via crafted PUT or POST requests, affecting JeecgBoot through 3.9.5. Because the position list endpoint is also unguarded, an attacker can first enumerate valid position IDs and then target them directly, so no guesswork or elevated role is required. Impact is confined to the integrity of position reference data - there is no confidentiality or availability loss and no escalation to system compromise - and the issue is correctly rated medium (CVSS 5.3); publicly available exploit code exists, while no CISA KEV active-exploitation entry is indicated.
SQL injection in JeecgBoot before 3.9.5 allows authenticated low-privilege users to bypass the SqlInjectionUtil keyword blocklist by inserting newline characters into dictionary and online report SQL fragments, then send newline-separated payloads to endpoints such as /sys/dict/getDictItems to perform boolean- or time-based blind extraction of database contents, including administrator password hashes from sys_user. The assessed CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N, so the primary precondition is an authenticated session rather than user interaction or a non-default configuration. Vendor-released patch: 3.9.5; no public exploit identified at time of analysis and no CISA KEV entry was provided.
Authenticated users of any privilege level on JeecgBoot through 3.9.5 can rewrite DingTalk, WeCom, or Feishu third-party integration settings - client id, client secret, agent id and corp id - through the unprotected editThirdAppConfig handler, redirecting directory synchronisation and messaging to attacker-controlled applications or breaking the integrations outright. The defect is a missing authorization check (CWE-862) in ThirdAppController.java with an assessed integrity impact (CVSS 3.1 base 7.1, PR:L, I:H), and publicly available exploit code exists, though no confirmed active exploitation (CISA KEV) is reported. Real-world impact is context-dependent: instances with no configured third-party IM/directory integration expose little to steal or disrupt through this endpoint.
Authenticated low-privileged users of JeecgBoot through 3.9.5 can retrieve any other user's stored password ciphertext through the GET /sys/api/getUserByName endpoint, which lacks authorization checks. Because the platform exposes its hard-coded AES-CBC encryption key via /sys/getEncryptedString, an attacker holding only a basic account can decrypt the returned password values locally and then subject administrator credentials to offline guessing. Publicly available exploit code exists, and exploitation requires a valid low-privileged account (PR:L) with network reachability, making this a genuine but moderate-priority credential-disclosure issue rather than an unauthenticated critical flaw; no CISA KEV entry indicates confirmed active exploitation at time of analysis.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user enumerate record IDs through the unguarded /airag/app/queryById endpoint and then read MCP (Model Context Protocol) server configurations - including endpoint URLs, HTTP headers and outbound authentication tokens - because the permission check in AiragMcpController.queryById is commented out. Exploitation requires a valid JeecgBoot session at any privilege level (CVSS v4.0 PR:L, assessed CVSS 3.1 PR:L) and a deployment that actually uses the AiRAG/MCP feature with stored MCP records; a stock install without configured MCP servers exposes nothing sensitive. Publicly available exploit code exists, though the issue is a moderate-priority information-disclosure flaw (high confidentiality impact, no integrity or availability impact) rather than a remote-takeover bug, and no CISA KEV entry indicates confirmed active exploitation.
Tenant ownership takeover in JeecgBoot through 3.9.5 lets any authenticated user - regardless of privilege level - reassign a tenant's owner by sending userId and tenantId to POST /sys/tenant/changeOwenUserTenant, stripping the legitimate owner and potentially installing the attacker or an accomplice as the new owner. The root cause is a missing authorization check (CWE-862) on the multi-tenant owner-change handler, rated CVSS 7.1 (CVSS:4.0 PR:L, UI:N, integrity-only impact), and publicly available exploit code exists. Exploitation is not drive-by: it requires a valid account on the target and a deployment where the multi-tenant feature is enabled, making this an access-control-bounded integrity risk rather than anonymous remote compromise.
Privilege escalation in JeecgBoot through 3.9.5 lets any authenticated user approve their own pending tenant administrator application and obtain tenant-admin ('tenant pack') permissions across any tenant. The SysTenantController passApply handler performs no authorization check, so a low-privilege account can file an application via doApplyTenantPackUser and then approve it with a PUT to /sys/tenant/passApply, reaching high confidentiality and integrity impact without user interaction or elevated privileges (assessed CVSS 3.1 8.1, PR:L). Publicly available exploit code exists - a Python proof-of-concept for tenant ownership and pack approval is published on GitHub and referenced by VulnCheck - but no CISA KEV entry has been reported, so confirmed active exploitation cannot be asserted.
Database credential disclosure in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to retrieve JDBC connection URLs, database usernames, and decrypted cleartext database passwords from the GET /sys/api/getDynamicDbSourceByCode endpoint of SystemApiController. The handler carries no Shiro permission or role annotations, so a basic application account is sufficient; the only practical hurdles are obtaining any valid session and knowing or enumerating a valid dbSourceCode value, and exposure requires that dynamic datasources be configured on the instance. Publicly available exploit code exists, and the impact is confidentiality-only (CVSS 3.1 6.5 / CVSS 4.0 7.1, PR:L), with no evidence of confirmed active exploitation at time of analysis.
Missing authorization in the saveDeptRolePermission endpoint of JeecgBoot's SysDepartPermissionController lets any authenticated user - regardless of privilege level - rewrite department role permissions, granting themselves arbitrary menu and button permissions or stripping permissions from other accounts. The flaw affects JeecgBoot through 3.9.5 and requires only a valid low-privilege session (PR:L in the CVSS vector), with no user interaction and no special configuration; publicly available exploit code exists, though there is no confirmation of active exploitation in the wild. The independent assessment rates this a genuine, actionable priority: the sole realistic barrier for an attacker is obtaining one low-privilege credential, so internet-exposed instances that permit self-registration are at direct risk.
JeecgBoot through 3.9.5 ships a system log controller whose batch-delete handler performs no authorization check, so any authenticated user - including the lowest-privileged account - can send a DELETE request with the ids parameter set to the special value 'allclear' and wipe the entire sys_log audit table for every user. The result is silent, organization-wide destruction of audit trail evidence rather than data theft, code execution, or privilege escalation, which keeps the real-world impact bounded. Publicly available exploit code exists (a Python PoC script referenced by VulnCheck), and CISA KEV does not list this CVE as confirmed actively exploited (CISA KEV); the vulnerability is confirmed exploited only in the reported PoC sense, not in observed campaigns. CVSS scores of 7.1 (vendor v4.0 and our assessed v3.1) reflect high integrity impact on the log table with low availability impact and no confidentiality impact.
Unauthenticated access to JimuReport's report folder template listing endpoint exposes all report definitions, share tokens, embedded SQL statements, and live query data to any remote attacker. The CWE-306 root cause - missing authentication for a critical function - means the disclosure requires no credentials, no user interaction, and no special tooling. With a CVSS 4.0 score of 8.7 and a network-accessible, zero-complexity attack path, this represents a high-priority information disclosure risk for any JimuReport deployment reachable from an untrusted network. No public exploit or CISA KEV listing has been identified at time of analysis, though the vulnerability is fully disclosed via VulnCheck advisory and a public GitHub issue.
Broken access control in JeecgBoot through 3.9.2 lets authenticated low-privilege users reach the OpenApiAuthController and OpenApiPermissionController endpoints, which are missing Shiro authorization annotations, to fully manage OpenAPI AK/SK credentials. Because the list endpoint returns secret keys in plaintext, any logged-in user can harvest every Access Key/Secret Key pair and then create, modify, or delete them, enabling credential theft and unauthorized invocation of the OpenAPI surface. Publicly available exploit code exists and the issue was reported by VulnCheck, though it is not listed in CISA KEV.
Unauthenticated report data exfiltration in JimuReport (JeecgBoot) through version 2.5.0 lets remote attackers export the full contents of any report via the POST /jmreport/auto/export endpoint. Because the handler carries the @JimuNoLoginRequired annotation, JimuReportTokenInterceptor skips all authentication and the export service never checks the auto-export configuration flag, so any guessed report id is rendered and streamed back. Publicly available exploit code exists; the disclosure comes from VulnCheck and the CVSS 4.0 base score is 8.7 (High), driven by high confidentiality impact with no privileges or user interaction required.
Authenticated SQL injection in JeecgBoot 3.9.5 allows a low-privilege user who can reach the JimuReport Table Dictionary API endpoint /jeecg-boot/jmreport/form/getTableDictList to manipulate the searchSql argument and alter SQL queries, with low impact to confidentiality, integrity, and availability. The flaw is remote and requires no user interaction, but exploitation is gated by a valid low-privilege session; the disclosure states the exploit has been made available to the public. The supplied intelligence does not include a CISA KEV entry or confirmed active exploitation.
SQL injection in JeecgBoot 3.9.5's JimuBI component allows unauthenticated remote attackers to manipulate the 'params' argument of the /jeecg-boot/drag/onlDragDatasetHead/getAllChartData endpoint and influence backend database queries. The CVSS 4.0 base score is 6.9 with low confidentiality, integrity and availability impact, and the independent assessment rates this as a moderate priority rather than critical. The reporter states exploit code has been released publicly, but no CISA KEV entry is provided and confirmed active exploitation is not established.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user retrieve other users' profile details - real names, usernames, emails, phone numbers, birthdays, employee numbers, department paths and posts - by supplying arbitrary userId values to the SysUserController getUserDetailByUserId handler. Exploitation requires only a low-privileged account (CVSS PR:L, no admin rights, no user interaction, no special configuration), and publicly available exploit code exists, so any deployment that permits self-registration or hosts many low-trust accounts is meaningfully exposed. This is a moderate-priority information-disclosure issue rather than a critical one; there is no confirmation of active exploitation and CVSS 4.0 scores it 5.3 (VC:L only, no integrity or availability impact), with the practical limiting factor being that the flaw is reachable only post-authentication.
Authenticated low-privileged users can export department role metadata from JeecgBoot through 3.9.5 because the SysDepartRoleController exportXls handler omits an authorization check. This low-severity information-disclosure issue is limited to read-only exposure of sys_depart_role records such as role names, codes, descriptions, and creating users; publicly available exploit code exists, but no CISA KEV entry is indicated in the provided data. Exploitation requires a valid session with only the default minimal role, and instances that do not allow self-registration or untrusted account creation materially reduce exposure.
JeecgBoot through 3.9.5 allows any authenticated low-privileged user to export the entire sys_comment table by calling the /sys/comment/exportXls endpoint because the SysCommentController handler lacks an authorization check. This exposes comment text and user IDs on records the attacker cannot normally access, but the impact is limited to information disclosure (no write or availability effect). Publicly available exploit code exists, and authentication as a low-privileged user is required (PR:L); the issue is a modest-priority one, not a top-tier emergency.
Any authenticated user of JeecgBoot through 3.9.5 can pull account records belonging to other users by supplying arbitrary userId values to the SysUserController queryChildrenByUsername handler, which performs no authorization check (CWE-862). Exposed data includes names, emails, phone numbers, employee numbers, department assignments, and staff lists for departments the targeted user heads, so the impact is confined to confidentiality of profile and organizational data with no write or availability effect. Publicly available exploit code exists, and the assessed risk is moderate rather than critical: the attacker must already hold a valid low-privileged session, and no public exploit activity has been confirmed.
JeecgBoot through 3.9.5 is vulnerable to a missing authorization flaw (CWE-862) in the SysMessageController delete handler, allowing any authenticated low-privileged user to delete arbitrary message records by sending a DELETE request with an attacker-chosen id. The vulnerability is present in default deployments and requires only a valid low-privilege account; publicly available exploit code exists, though no confirmed active exploitation (not in CISA KEV) has been observed. Impact is limited to integrity and availability of sys_sms rows-no data disclosure or code execution-yielding a medium-severity CVSS 4.0 base score of 5.3 (assessed CVSS 3.1: 5.3, PR:L).
Deletion of message templates in JeecgBoot through 3.9.5 is possible for any authenticated user, even the lowest-privileged account, because the SysMessageTemplateController delete handler omits an authorization check. Attackers can first enumerate template IDs from the unguarded list endpoint, then delete shipped notification templates, causing system notices and workflow reminders to fail. This integrity/availability issue has a CVSS score of 5.3 (medium) and publicly available exploit code exists, though active exploitation has not been confirmed.
Missing authorization in the JeecgBoot SysPositionController removeUserPosition handler (versions through 3.9.5) allows any authenticated low-privileged user to delete user-to-position mappings in the sys_user_position table by sending DELETE requests with arbitrary userId and positionId values. The attacker gains no confidentiality or code execution, but can silently unbind users from their positions, and the deletions are performed without logging, which hampers detection and attribution. Publicly available exploit code exists (a Python PoC referenced by VulnCheck) and the issue is tracked as CWE-862; no CISA KEV listing indicating confirmed active exploitation was provided. Independently assessed as CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L (assessed score consistent with the reported 5.3 base), this is a genuine-but-moderate priority issue requiring a valid authenticated account rather than a critical emergency.
Information disclosure in JeecgBoot through 3.9.5 allows any authenticated low-privileged user in a multi-tenant deployment to query the getTenantPackInfo handler with another tenant's tenantId and fixed packCode values such as superAdmin, accountAdmin, or appAdmin, exposing administrator usernames, real names, phone numbers, and departments. The flaw is a CWE-862 missing authorization check in SysTenantController; it is read-only PII exposure that requires a valid account and knowledge or enumeration of a target tenantId, with CVSS 5.3 and an independent assessment of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N. Publicly available exploit code exists, but there is no confirmed active exploitation (not in CISA KEV), making this a genuine but modest-severity cross-tenant information-disclosure issue.
Authenticated users can rename and replace dictionaries in low-code applications on JeecgBoot through 3.9.5 because the PUT /sys/dict/editDictByLowAppId endpoint lacks an authorization check. Any registered low-privilege user can obtain a target dictionary's low_app_id from GET /sys/dict/list and then pass it via the lowAppId parameter or X-Low-App-ID header to modify that dictionary's name and items. Publicly available exploit code exists, but no active exploitation has been confirmed (not in CISA KEV). The impact is limited to integrity manipulation as assessed at CVSS 5.3 (CWE-862).
Authenticated users of JeecgBoot through 3.9.5 can read other users' stored AI chat variables through an insecure direct object reference in AiragBaseApiController's /airag/api/getChatVariable endpoint, which trusts a caller-supplied username parameter instead of the authenticated principal. Exploitation requires a valid JeecgBoot account (CVSS 4.0 PR:L) and a deployment that actively uses the AIRAG chat feature with chat variables persisted in Redis, and the attacker must know or enumerate the target appId, victim username, and variable name; impact is confined to confidentiality of chat memory values with no write, integrity, or code-execution effect, and installations not using AIRAG are not exposed. Publicly available exploit code exists (a PoC is published on GitHub), but there is no evidence of confirmed active exploitation, and the moderate CVSS score of 5.3 reflects the authentication prerequisite and limited read-only impact.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated, low-privileged user to read the AI application configurations of other users by invoking the AiragAppController queryById handler with arbitrary application ids. The companion /airag/app/listDict endpoint lacks its own access control and can be walked to enumerate valid application ids, each of which then discloses system prompts, memory prompts, model ids, knowledge base ids, and plugin bindings belonging to other users. Publicly available exploit code exists (a Python proof-of-concept), and the issue is not listed in CISA KEV as actively exploited; with the assessed vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N (5.3), this is a genuine but moderate-severity, read-only information-disclosure problem rather than a critical priority.
Missing authorization checks in JeecgBoot's AiragPromptsController (all releases through 3.9.5) let any authenticated user, even one at the lowest privilege level, delete AI prompt templates belonging to other users by calling DELETE /airag/prompts/delete. Because the companion GET /airag/prompts/list endpoint performs no authorization at all, an attacker can first enumerate valid prompt template IDs and then trigger a logical (soft) deletion, making those templates unavailable to every user on the instance. Publicly available exploit code exists, but there is no indication of confirmed active exploitation; the assessed impact is confined to integrity and availability of prompt-template objects (CVSS 3.1 base 5.3, PR:L, AV:N), with no confidentiality exposure and no system-level compromise, making this a genuine but low-to-moderate priority issue.
Missing authorization in the putCancelQuit handler of SysUserController in JeecgBoot through version 3.9.5 lets any authenticated low-privileged user supply arbitrary user ids together with a tenantId parameter or X-Tenant-Id header and reverse user resignations, restoring ended, pending, or refused tenant memberships to normal. Publicly available exploit code exists (a Python PoC is published on GitHub), and the flaw is confirmed reachable by any logged-in account rather than anonymously. Impact is limited to tenant-membership integrity with no confidentiality or availability effect, making this a genuine-but-moderate access-control issue rather than a top-tier priority; no public exploit identified at time of analysis as actively exploited, and KEV status is not indicated.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user - including a low-privileged one - to add arbitrary accounts to administrator-maintained user groups by sending a POST request containing target user ids and a groupId to the SysUserController addSysUserGroup handler, which performs no permission check. Impact is integrity-only at moderate severity: attacker-controlled group membership changes, with no confidentiality or availability effect on the platform itself. Publicly available exploit code exists, and there is no CISA KEV listing, so confirmed active exploitation in the wild has not been observed at time of analysis.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user - regardless of privilege level - to reassign or remove department heads by sending a PUT request to /sys/user/changeDepartChargePerson with arbitrary user, department, and status values. Attackers must already hold a valid low-privilege account (CVSS PR:L) and network reachability to the endpoint, so this is an authenticated authorization flaw (CWE-862) rather than a pre-auth or remote-code issue; the impact is limited to integrity of department-head assignments (CVSS 4.0 base 5.3, assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) and the department-scoped data visibility that follows. Publicly available exploit code exists (a Python PoC published on GitHub and referenced by VulnCheck), but there is no CISA KEV entry indicating confirmed active exploitation; no vendor-released patch version is identified in the available data.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, including one holding only a basic low-privileged role, to rename, re-parent, or strip the department heads from any department via a PUT request to /sys/user/doUpdateDepartInfo. The endpoint applies no ownership or tenant checks, so an attacker with a valid session - obtainable through self-registration or any default user role - can tamper with organizational structure across tenants without any elevated privilege. Publicly available exploit code exists (a Python PoC published on GitHub), and the vendor has not released a confirmed fixed version at time of analysis; the flaw is rated moderate (CVSS 3.1 base 5.3, integrity-only impact) and there is no public evidence of active exploitation.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated account - including the lowest-privileged user - to reassign users between departments and overwrite their positions by sending PUT requests to /sys/user/batchEditUsers with arbitrary user and department IDs. Because the SysUserController batchEditUsers handler performs no permission check, an attacker can move administrators into attacker-chosen departments and tamper with organizational metadata, but the assessed impact is integrity-only (CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N; vendor-scored CVSS 4.0 5.3) with no data disclosure or service disruption. Publicly available exploit code exists in a public GitHub repository, though the issue is not confirmed actively exploited (CISA KEV), and the authentication prerequisite keeps overall risk moderate rather than emergency-grade.
Missing authorization in the saveDatarule handler of JeecgBoot's SysDepartRoleController (all versions through 3.9.5) allows any authenticated low-privileged user to overwrite department-role data-rule mappings, widening row-level data access or altering query filtering for roles they do not legitimately administer. The flaw is reachable over the network with only ordinary authenticated access (PR:L, no user interaction) by posting crafted permissionId, roleId and dataRuleIds values to the save-datarule endpoint; impact is limited to confidentiality and integrity of data-rule scope, not code execution or account takeover, which is consistent with the moderate 5.3 score. Publicly available exploit code exists (a Python PoC is published alongside the CVE), though no CISA KEV entry or active-exploitation confirmation was provided, and the realistic risk is highest in deployments where low-privileged or self-registered accounts are widely available.
An authorization weakness in JeecgBoot through 3.9.5 lets any authenticated low-privileged user overwrite role-level data rules through the SysRoleController saveDatarule handler, clearing row-level filters so records normally hidden from that role become readable, or changing the filtering applied to other roles. Exploitation requires network reachability to the saveDatarule endpoint and a valid low-privileged session (PR:L) with no user interaction, and publicly available exploit code exists in the form of a Python PoC (poc_role_datarule_write.py) that posts permissionId, roleId and dataRuleIds values. Impact is bounded to data-rule and row-level filter manipulation with low confidentiality and integrity loss rather than code execution or administrative takeover, giving a moderate assessed severity (CVSS 3.1 5.3); risk concentrates on deployments that issue low-trust accounts or expose the application to many users.
JeecgBoot versions through 3.9.5 expose the POST /sys/api/sendSysAnnouncement endpoint without any authorization check, allowing any authenticated low-privilege user to craft and broadcast system announcements with attacker-controlled title, content, fromUser and toUser values to arbitrary recipients over WebSocket, WeCom, DingTalk and Feishu. The flaw is a missing-authorization issue (CWE-862) rated 5.3 in CVSS 4.0 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N per the independent assessment), and its practical impact is limited to forged, potentially phishing-style or misinformation messages rather than data theft or code execution. A public proof-of-concept script targeting the endpoint exists, making exploitation straightforward for anyone holding a valid low-privilege account, though there is no indication of confirmed active exploitation (CISA KEV is not referenced) and no EPSS score was supplied.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user publish templated system announcements to arbitrary recipients via POST /sys/api/sendBusTemplateAnnouncement. A low-privileged attacker can supply templateCode, toUser and a forged fromUser to push spoofed notifications through WebSocket, DingTalk, WeCom, Feishu and UniPush channels, an integrity-only impact (CVSS 5.3, CWE-862) that requires a valid session but no user interaction. Publicly available exploit code exists, though no active exploitation has been confirmed (the issue is not listed in CISA KEV).
JeecgBoot through 3.9.5 contains a missing-authorization flaw in SystemApiController's getUserRoleSetById handler that lets any authenticated low-privileged user read other users' assigned role codes by supplying an arbitrary userId. The endpoint skips the system:user:queryUserRole permission check, so an attacker can enumerate role assignments and identify administrator accounts without that permission; publicly available exploit code exists. Impact is limited to information disclosure (no modification or direct account takeover), and the issue is rated moderate with a CVSS 5.3 input vector requiring a valid session.
JeecgBoot through 3.9.5 contains a missing authorization flaw in the sys/api queryUserAuths handler that lets any authenticated user retrieve the complete permission set of an arbitrary account by supplying an attacker-chosen userId parameter. This allows low-privileged attackers to map out administrator accounts and their permissions, though it does not permit modification or service disruption (CVSS 4.0 score 5.3; independent assessment CVSS 3.1 score 5.3). Publicly available exploit code exists (no CISA KEV confirmation), and exploitation requires a valid authenticated session at any privilege level.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated, low-privileged user send spoofed template announcements by POSTing to /sys/api/sendTemplateAnnouncement with attacker-chosen sender, recipient, title, and template parameters, so the resulting messages appear to come from admin or system accounts. Rated 5.3 (medium), the issue carries only low integrity impact with no confidentiality or availability effect and no path to code execution, and it requires the attacker to already hold a valid JeecgBoot session. Publicly available exploit code exists (VulnCheck-reported POC plus a GitHub PoC script), though there is no indication of confirmed active exploitation.
JeecgBoot through 3.9.5 allows any authenticated low-privileged user to send spoofed system announcements via the /sys/api/sendBusAnnouncement endpoint because SystemApiController does not enforce the required permission check. An attacker can forge the sender, recipients, title, and content to impersonate administrators or the system, enabling phishing against other users. No code execution, data disclosure, or service disruption is possible, and publicly available exploit code exists; this is a low-severity authorization flaw rather than a remotely exploitable unauthenticated compromise.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated low-privileged user read arbitrary users' role codes by sending GET requests to /sys/api/queryUserRoles with an arbitrary username parameter, allowing role-assignment discovery and identification of administrator accounts. The issue is tracked as CWE-862 (missing authorization) with an assessed CVSS of 5.3 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:N/C:L/I:N/A:N), requiring only a valid JeecgBoot account of any privilege level; impact is confined to information disclosure rather than write or execution capability. Publicly available exploit code exists for this endpoint, but there is no indication of confirmed active exploitation (CISA KEV); the endpoint is exploitable in default deployments with no special configuration, making the authentication requirement the primary limiting factor.
Missing authorization in the JeecgBoot SysAnnouncementController downLoadFiles handler lets any authenticated low-privileged user retrieve a ZIP of announcement attachments by supplying a valid announcement id, exposing files from unpublished announcements or announcements addressed only to other users. The flaw affects JeecgBoot through version 3.9.5 (CPE cpe:2.3:a:jeecgboot:jeecgboot:*), requires a valid non-admin account and knowledge or enumeration of an announcement id, and yields only confidentiality impact with no write, execution, or availability effect. Publicly available exploit code exists (a Python PoC script published on GitHub) but there is no confirmed active exploitation (not listed in CISA KEV), so this is a medium-severity information-disclosure issue rather than a critical priority.
Missing authorization in the SysAnnouncementController editIzTop handler of JeecgBoot through 3.9.5 allows any authenticated user at a low privilege level to pin or unpin system-wide announcements by sending a POST or PUT request carrying an arbitrary announcement id. The root cause is a pure access-control failure (CWE-862), not a memory or injection flaw, so the practical impact is limited to tampering with the pinned-notice banner displayed to all users, with no data disclosure, code execution, or service disruption. Publicly available exploit code exists and the issue was reported by VulnCheck, but the assessed severity is modest (CVSS 3.1 score 5.3, PR:L) because an attacker must already hold valid credentials and the resulting integrity change is low.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to read OpenAPI gateway definitions they are not entitled to see, exposing internal origin URLs, virtual paths, IP whitelists, and header and parameter templates. The flaw (CWE-862) lives in the OpenApiController queryById handler, which fails to enforce the openapi permission, so a simple GET /openapi/queryById with a valid entry id returns configuration metadata. It is a moderate-severity issue (CVSS 5.3, PR:L, confidentiality-only impact) for which publicly available exploit code exists, but there is no indication of confirmed active exploitation and the CVE is not in CISA KEV.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user - including low-privileged accounts - download every user's stored AI prompts by calling the /airag/prompts/exportXls endpoint. The response is an Excel workbook exposing prompt content, model IDs, and parameters belonging to all users, a moderate-severity information disclosure rather than a critical code-execution issue. Publicly available exploit code exists (a PoC script targets this handler), though there is no confirmed evidence of active exploitation (no CISA KEV listing), and exploitation is gated solely on possession of any valid low-privilege session.
JeecgBoot through 3.9.5 contains an authorization bypass (CWE-639) in the AIRAG video-generation module, where an authenticated low-privileged user can read other users' AI video-generation history by supplying an arbitrary userId to the getVideoRecords handler in VideoGenerationController. Publicly available exploit code exists, and the disclosed records include prompts, task IDs, video URLs, and cover URLs; however, there is no write access or broader compromise, and exploitation requires the AIRAG video feature to be deployed and the attacker to already hold a valid account. The issue is a moderate-severity information-disclosure bug (CVSS 4.0 5.3; independent CVSS 3.1 assessment 5.3) rather than a top-tier priority.
Missing authorization in JeecgBoot's AIRAG prompts module (through version 3.9.5) lets any authenticated, low-privileged user invoke the promptExperiment handler in AiragPromptsController and launch AI prompt evaluation runs against prompt templates and datasets that belong to other users. Because the handler performs no ownership or permission check on the supplied prompt-template and dataset IDs, an attacker who can enumerate or guess those identifiers can write result rows into the airag_ext_data table and alter dataset status, an integrity-only impact with no confidentiality or availability loss. Exploitation requires a valid low-privileged account plus an instance where the AIRAG module is deployed with a working LLM backend; publicly available exploit code exists, but there is no confirmed active exploitation (no CISA KEV listing) and the issue is rated moderate rather than critical.
Missing authorization in JeecgBoot's AiRAG knowledge module lets low-privileged authenticated users read document text chunks from knowledge bases they do not own. The embeddingSearch handler in AiragKnowledgeController (GET /airag/knowledge/embedding/search) lacks Shiro permission annotations, so any valid account can pass arbitrary knowledge base IDs and retrieve indexed content belonging to other users or tenants. Exploitation is remote and requires authentication (CVSS:4.0 PR:L, assessed CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N), impact is limited to confidentiality, and publicly available exploit code exists (a Python PoC targeting the data plane); no confirmed active exploitation has been reported. This is a genuine but moderate-severity issue, not a top-tier emergency.
Permanent deletion of other users' recycled AI prompt templates is possible in JeecgBoot through 3.9.5 because the AiragPromptsController deleteRecycleBin handler performs no authorization check. Any authenticated user - including the lowest-privileged account, since the assessed vector is PR:L - can issue a DELETE request carrying arbitrary prompt-template IDs and purge recycle-bin entries that belong to administrators or other tenants; no admin role, user interaction, or special configuration is needed beyond the AIRAG module being present. Publicly available exploit code exists (a PoC script targeting this endpoint), though there is no confirmed active exploitation (not in CISA KEV). Our independent assessment rates this as medium severity (CVSS:3.1 5.3, AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) and a low-real-world-priority issue: integrity-only impact confined to deletion of soft-deleted template records, with no confidentiality exposure, no code execution, and fully unauthenticated outsiders unable to exploit it.
Missing authorization in JeecgBoot through 3.9.5 allows a low-privileged authenticated user to undo administrator deletions of AI prompt templates by sending crafted PUT requests to the /airag/prompts/revertRecycleBin endpoint with chosen template IDs, clearing the deleted flag and returning them to active use. Because the endpoint performs no permission check, any account with a valid session - not just an administrator - can restore recycled content; publicly available exploit code exists, though exploitation still requires credentials (CVSS PR:L) and knowledge of valid deleted-template IDs, and the impact is limited to an integrity change on prompt template records with no confidentiality or availability effect. Per our independent assessment this is a genuinely low-severity, low-priority issue: it is not exploitable by unauthenticated attackers, requires no user interaction, and cannot be used to read data, escalate privileges, or disrupt the platform.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, regardless of role, to delete administrator-created AI prompt templates through the deleteBatch handler of AiragPromptsController. The unguarded list endpoint lets a low-privileged attacker enumerate prompt IDs and feed them to deleteBatch, destroying templates belonging to admins or other tenants; exploitation requires only a valid account (CVSS vector PR:L) and no user interaction or elevated role. Publicly available exploit code exists (a PoC script targeting the deleteBatch endpoint has been published), but there is no confirmation of active exploitation in the wild, and the practical risk is concentrated in multi-tenant or self-registering deployments where low-privileged accounts coexist with administrator content.
Tampering with AI prompt templates in JeecgBoot through 3.9.5 is possible for any authenticated user due to missing authorization in the AiragPromptsController edit handler. A low-privileged attacker can send PUT or POST requests to /airag/prompts/edit with a target template id to overwrite prompt text and model parameters created by administrators or other users, resulting in integrity-only impact. Publicly available exploit code exists, though no active exploitation has been confirmed; CVSS 5.3 (medium).
JeecgBoot versions through 3.9.5 contain a missing authorization flaw in the AiragPromptsController that lets any authenticated user read AI prompt templates belonging to other users, including administrators. Attackers can enumerate prompt IDs through the unguarded /airag/prompts/list endpoint and then retrieve each template's text, model parameters, and creator details via queryById, resulting in unauthorized information disclosure. Publicly available exploit code exists, but the issue requires a valid account and the AIRAG module to be deployed, making it a modest-severity confidentiality risk rather than a critical one.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated, low-privileged user delete pending tenant-administrator applications belonging to other tenants via the SysTenantController deleteApply handler, which also sends rejection notifications to the affected applicants. Publicly available exploit code exists, though exploitation requires a valid low-privileged account plus valid or enumerable tenantId, packId and userId values for a pending application. Impact is limited to integrity of the tenant-onboarding workflow with no data disclosure or service outage, making this a genuine but moderate issue rather than a top-priority one.
Missing authorization in JeecgBoot 3.9.5 and earlier allows any authenticated low-privileged user to remove arbitrary users from any tenant's product pack by sending attacker-controlled userId and packId values to PUT /sys/tenant/deleteTenantPackUser, silently revoking assigned permissions such as tenant administrator access. Exploitation requires only a valid low-privileged account (PR:L per the assessed CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) on an instance running in multi-tenant mode with tenant product packs configured, and publicly available exploit code exists, though there is no confirmed active exploitation (CISA KEV). The impact is confined to integrity and availability of permission assignments - no confidentiality exposure and no code execution - making this a genuine but moderate-priority issue rather than a top-tier emergency.
Missing authorization in JeecgBoot (all versions through 3.9.5) lets any authenticated, low-privileged user alter tenant administrator application status for arbitrary tenants by sending a PUT request to /sys/tenant/updateApplyStatus with a tenant id they do not own. The endpoint performs no ownership or role check on the supplied identifier, so an ordinary account - including one obtained through self-registration - can toggle the applyStatus field and thereby enable or disable tenant-admin applications across the entire instance. Publicly available exploit code exists (a Python PoC is published in a public GitHub repository), though this is not confirmed as actively exploited in the wild; EPSS and KEV data were not provided, and the independent assessment rates this as a moderate-severity broken access control issue with limited blast radius, since impact is confined to status toggling rather than full tenant takeover.
An authenticated low-privileged user on JeecgBoot through 3.9.5 can query any tenant's product-pack configuration by calling the SysTenantController listPackByTenantUserId handler with attacker-chosen tenantId and userId parameters, because that handler performs no authorization check on the caller's ownership of the requested tenant. The result is read-only disclosure - tenant pack settings plus the identities of users who are tenant administrators - which is useful for reconnaissance and privilege-mapping but causes no data modification or service disruption (CVSS 5.3 / CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N). Publicly available exploit code exists in a GitHub proof-of-concept repository, and exploitation is meaningful only in multi-tenant deployments where other tenants exist to enumerate; there is no confirmation of active exploitation (CISA KEV) at time of analysis.
Missing authorization in JeecgBoot's SysTenantController queryTenantAuthInfo handler (all versions through 3.9.5) allows any authenticated, low-privileged user to enumerate small integer tenant IDs and read other tenants' full sys_tenant records, including house numbers used as tenant join codes and company profile fields. Exploitation requires a valid authenticated account (CVSS vector PR:L) on a multi-tenant deployment where other tenants' records exist; publicly available exploit code exists, but there is no confirmation of active exploitation. The impact is limited to read-only information disclosure (CVSS 5.3, assessed as C:L/I:N/A:N), making this a moderate access-control issue rather than a high-urgency flaw.
Information disclosure in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to read tenant administrator applications for any tenant by iterating the tenantId parameter on the /sys/tenant/getTenantPackApplyUsers endpoint. Public exploit code exists, but exploitation requires a valid account and a multi-tenant deployment with pending applicants; the impact is limited to read-only disclosure of applicant PII (usernames, real names, phone numbers, departments) with no write or availability effect. This medium-severity issue is confirmed by an independent assessment as an information-disclosure flaw, not a critical priority.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated low-privileged user read scheduled-job records - class names, cron expressions, job parameters and status - by issuing GET /sys/quartzJob/queryById with a job id, data otherwise reserved for administrators. Publicly available exploit code exists (no CISA KEV entry), and the issue carries a CVSS 5.3 score with an independently assessed vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, so impact is confined to confidentiality of job metadata with no write, code-execution or denial-of-service capability. Treat this as a genuine but bounded-severity issue at low-to-moderate priority: exploitation requires a valid low-privileged account against a network-reachable instance and yields only information disclosure that may assist further attacks.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to read object storage file records via the OssFileController queryById handler (GET /sys/oss/file/queryById), exposing original file names and direct storage URLs of other users' uploads. Publicly available exploit code exists, though the issue requires a valid authenticated account and knowledge of a target record ID, which appears enumerable. The assessed vector (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) indicates modest confidentiality impact, and no active exploitation (CISA KEV) is confirmed.
JeecgBoot through 3.9.5 exposes an authorization gap in the OpenApiController.queryPageList handler, letting any authenticated user - including a low-privileged one - retrieve the OpenAPI registry listing via GET /openapi/list and read virtual paths, internal origin URLs, IP whitelists, and header/parameter templates meant for administrators. Exploitation requires only a valid, non-admin JeecgBoot session (CVSS PR:L) and publicly available exploit code exists, though no active exploitation has been confirmed via CISA KEV; the CVSS 3.1 assessment scores it 5.3 as a read-only confidentiality disclosure with no integrity or availability impact, and EPSS data was not provided. The practical risk is moderate: the leak itself does not grant code execution, but it hands an attacker the internal routing and gateway configuration needed to plan follow-on attacks against otherwise hidden backend services.
JeecgBoot through 3.9.5 permits any authenticated low-privileged user to alter another user's avatar, including an administrator's, by sending a PUT request with an arbitrary target user ID and avatar value to the SystemApiController updateAvatar endpoint. The independent assessment rates this as a low-to-moderate priority authenticated integrity-check failure: network reachable, low privileges required, no user interaction, and only low impact to avatar data with no confidentiality or availability loss. Publicly available exploit code exists, but no CISA KEV active exploitation is indicated.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, including a low-privileged one, to read the role codes of arbitrary accounts by supplying a chosen userId to the endpoint GET /sys/api/getRolesByUserId. The flaw is a CWE-862 absence of an ownership or permission check in the getRolesByUserId handler of SystemApiController, so a valid session - not administrative rights - is the only prerequisite. Impact is limited to information disclosure useful for reconnaissance (identifying administrator accounts and mapping role assignments), with no write or availability effect; publicly available exploit code exists, and EPSS/KEV data indicate no confirmed active exploitation at time of analysis.
Missing authorization in the JeecgBoot SystemApiController.getUserPermissionSet handler (JeecgBoot through 3.9.5) lets any authenticated low-privileged user read the full permission code set of any other account, including administrators, by passing an arbitrary userId to GET /sys/api/getUserPermissionSet. The handler never verifies that the requester is entitled to read the supplied user's permissions, so exposure is limited to confidentiality of permission codes rather than modification or account takeover. Publicly available exploit code exists (a Python PoC is published alongside the VulnCheck advisory), but there is no indication of confirmed active exploitation (CISA KEV) at time of analysis; the practical barrier is the requirement for a valid login, which restricts realistic abuse to insiders, compromised accounts, or instances permitting self-registration or guest accounts. Impact is rated low on confidentiality (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) with no integrity or availability effect.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user to read arbitrary accounts' role codes by supplying a userId to the queryUserRolesById handler of SystemApiController, enabling enumeration of role assignments and identification of administrator accounts. Exploitation requires only a valid low-privilege session (CVSS 4.0 vector shows PR:L, no user interaction) and publicly available exploit code exists, while there is no evidence of confirmed active exploitation (no CISA KEV listing in the provided data). Because the flaw is limited to confidentiality with no modification or availability impact, it is a genuine but low-to-moderate priority disclosure issue rather than a critical emergency.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to bypass the system:checkRule:add permission check in the SysCheckRuleController importExcel handler and bulk-create system-wide encoding validation rules from a crafted Excel workbook. Publicly available exploit code exists (a Python PoC published on GitHub), though there is no confirmed active exploitation (CISA KEV) and no EPSS score was supplied; the CVSS v4.0 base score is 5.3 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N) and our independent assessment rates it as a medium-severity, lower-tier priority issue rather than an urgent emergency. Exploitation requires a valid low-privileged account (PR:L), so exposure is highest where JeecgBoot is internet-facing or where self-registration or weak account provisioning is enabled; impact is confined to the integrity of validation rules, with no direct data disclosure or service outage.
Missing authorization in the SysCategoryController importExcel handler of JeecgBoot through 3.9.5 allows any authenticated user - of any privilege level - to bulk-insert arbitrary nodes into the system-wide sys_category dictionary by uploading a crafted Excel workbook. Because the endpoint lacks a role or permission check, a low-privileged account can add entries, including under existing parent nodes, tampering with a shared configuration dictionary; the impact is limited to integrity (no confidentiality or availability loss per the CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N assessment), and the primary limiter is that a valid login is required, so unauthenticated outsiders cannot exploit it. Publicly available exploit code exists and the issue is referenced by VulnCheck, but there is no indication of confirmed active exploitation (CISA KEV), and no vendor-released patch was identified at time of analysis.
Missing authorization in JeecgBoot's SysCategoryController (through version 3.9.5) lets any authenticated user, including a low-privileged one, rename, recode, or move system-wide sys_category dictionary nodes by sending POST or PUT requests with a node id to /sys/category/edit, corrupting classification values that are consumed across forms and other application features. Publicly available exploit code exists and the issue is tracked by VulnCheck, but no evidence of confirmed active exploitation (CISA KEV) was provided. With PR:L in both the vendor CVSS 4.0 vector (5.3) and the independent CVSS 3.1 assessment, impact is confined to integrity of shared reference data - no confidentiality or availability effect - and the need for a valid session plus a known or enumerable node id keeps this a moderate-priority issue rather than a high-impact one.
Authenticated users on JeecgBoot through 3.9.5 can delete arbitrary sys_category dictionary nodes through the SysCategoryController delete handler, which performs no permission check, allowing low-privileged accounts to remove entire category subtrees and break dependent forms and dictionary-backed fields. The node identifiers needed for the attack are freely exposed by the unguarded rootList and childList endpoints, so no special configuration or elevated role is required - only a valid login, meaning the practical barrier is simply obtaining any account (publicly available exploit code exists, per a linked GitHub PoC). The independent assessment rates this CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L - a medium-severity, authorization-only flaw whose impact is bounded to integrity and availability of dictionary data, with no confidentiality exposure and no code execution; the reported CVSS 5.3 is consistent with that view.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to destroy the platform's sys_category dictionary data by calling DELETE /sys/category/deleteBatch, an endpoint that performs the deletion without verifying the caller holds permission for that operation. The companion rootList and childList endpoints are equally unguarded, so the same user can enumerate node ids and submit them to recursively delete whole sys_category subtrees, breaking dependent forms and dictionary fields across the instance. Publicly available exploit code exists (a Python PoC that drives the console delete route), but the issue is a moderate data-loss/denial-of-function condition rather than a critical one: an account is required, impact is limited to integrity and availability of dictionary data, and there is no confidentiality exposure or code execution.
JeecgBoot versions through 3.9.5 expose an authorization gap in SysAnnouncementSendController that lets any authenticated user tamper with other users' announcement delivery records, overwriting read flags, recipient identifiers, or the linked announcement so that messages are hidden from the intended recipients. Exploitation requires a valid low-privileged account and reachability to the standard GET /sys/sysAnnouncementSend/list and PUT /sys/sysAnnouncementSend/edit endpoints, which ship enabled in default deployments; no user interaction or special configuration is needed. Publicly available exploit code exists (a PoC script published in a public GitHub repository), and VulnCheck is credited with reporting it, but there is no evidence of confirmed active exploitation (not in CISA KEV). Impact is integrity-only against message-delivery data, with no confidentiality or availability effect, giving moderate severity (CVSS 4.0 base 5.3; independently assessed as CVSS 3.1 5.3, PR:L).
Authenticated insecure direct object reference in JeecgBoot through 3.9.5 allows any logged-in user to read other users' in-application announcement messages by passing an attacker-chosen sendId to the getOne handler of SysAnnouncementSendController. Valid delivery-record identifiers are trivially harvested from the unguarded /sys/sysAnnouncementSend/list endpoint, after which getOne returns message titles, bodies, senders and recipients without any ownership check, producing a confidentiality-only impact with no write or availability effect (CVSS 4.0 base 5.3; assessed CVSS 3.1 5.3, AV:N/AC:L/PR:L/UI:N). Exploitation requires a valid low-privileged account but no special configuration or user interaction; publicly available exploit code exists in the form of a published GitHub proof-of-concept script, and there is no KEV confirmation of active exploitation, so this should be treated as a moderate-priority, exploitation-ready information-disclosure issue rather than a system-compromise flaw.
Missing authorization in the JeecgBoot SysDepartRole queryById handler (all versions through 3.9.5) lets any authenticated user - regardless of department scope - read department-role metadata such as role names, codes, descriptions, and audit fields by issuing GET /sys/sysDepartRole/queryById with an arbitrary id value. Exploitation requires only a valid low-privileged session on a reachable JeecgBoot system API, so it is not exploitable by fully unauthenticated outsiders, and publicly available exploit code exists, making the flaw trivially reproducible for anyone holding basic account credentials. The impact is limited to read-only disclosure of role metadata with no write or availability effect, consistent with the assessed CVSS 4.0 score of 5.3 (Medium) and CWE-862 (Missing Authorization).
Authenticated users of JeecgBoot through 3.9.5 can permanently delete data dictionaries and all of their items by sending DELETE requests to /sys/dict/deletePhysic/{id}, because the deletePhysic handler in SysDictController omits an authorization check (CWE-862); the hard delete bypasses the recycle bin and is irreversible. Any valid low-privilege account suffices - no administrator role, user interaction, or non-default configuration is required, only network access to the application and knowledge or enumeration of a target dictionary {id}. Publicly available exploit code exists, but there is no indication of confirmed active exploitation, and the impact is confined to integrity and availability of dictionary data (no confidentiality exposure or code execution), making this a moderate-severity insider or compromised-account threat.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to remove arbitrary users from administrator-maintained groups by sending DELETE requests with manipulated groupId and userId parameters to the SysUserController's deleteGroupUser handler. This broken-access-control flaw (CWE-862) has modest impact-only group membership integrity is affected, not code execution or data theft-and publicly available exploit code exists. Exploitation requires a valid account of any privilege level and network access to the API; no special configuration is needed, making multi-tenant deployments particularly at risk.
Missing authorization in JeecgBoot through 3.9.5 lets any low-privileged authenticated user silently remove members from administrator-maintained user groups by calling DELETE /sys/user/deleteUserGroupBatch with an arbitrary groupId and a comma-separated list of userIds. The endpoint performs no permission or tenant-isolation check before deleting rows from sys_ugroup_user, so the impact is limited to integrity tampering with group membership rather than data disclosure or denial of service; publicly available exploit code exists (a PoC script is published), and no confirmed vendor patch was identified at time of analysis. Successful exploitation requires a valid authenticated session at any privilege level (PR:L in both the reported CVSS 4.0 vector and our assessed CVSS 3.1 vector), meaning fully unauthenticated attackers cannot exploit it, and no CISA KEV listing or confirmed active exploitation is associated with this issue.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, regardless of role, to upload a crafted Excel workbook to POST /sys/sysDepart/appImportExcel and create arbitrary sys_depart records in the administrator-maintained department tree. Exploitation requires only a valid low-privilege session with network reachability to the endpoint, and publicly available exploit code exists; however, the impact is confined to integrity (CVSS 3.1 base 5.3, PR:L, I:L, C:N, A:N), with no code execution, data disclosure, or service disruption possible from this flaw alone. This is a medium-severity, lower-priority issue in practice that matters mainly where low-privilege accounts are freely provisioned.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user - regardless of privilege level (CVSS vector PR:L) - enumerate department personnel via the GET /sys/sysDepart/getDepartmentHead endpoint of SysDepartController, disclosing staff names, avatars, posts, and mobile and telephone numbers, including records explicitly marked hidden, simply by iterating the departId parameter. Publicly available exploit code exists in the form of a proof-of-concept script targeting the endpoint, but the impact is confined to confidentiality of directory/contact data at CVSS 5.3 with no write, code-execution, or availability effect, and no non-default configuration is needed to reach the vulnerable code path. This is a moderate-severity information-disclosure issue rather than an urgent, actively exploited one.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated low-privileged user delete department permission bindings through the DELETE /sys/sysDepartPermission/deleteBatch endpoint, silently stripping the menus and buttons a department can grant to its roles. Exploitation requires only a valid low-privileged session (CVSS vector PR:L) with no admin rights and no user interaction, because the companion list endpoint is also unguarded and exposes the row ids that must be submitted in the ids parameter. Publicly available exploit code exists, including a published Python PoC, and no confirmed active exploitation is reported in the available intelligence sources; with integrity and availability impact limited to permission records and no confidentiality loss, this is a moderate-risk authenticated authorization flaw rather than a critical one.
JeecgBoot through 3.9.5 exposes the POST /sys/sysDepartPermission/add endpoint without any authorization check, so any low-privileged authenticated user can create department-permission bindings and attach menu, button, and data-rule grants to arbitrary departments by supplying their own departId, permissionId, and dataRuleIds values. Because the flaw is a missing-authorization issue (CWE-862) rated 5.3 with an assessed CVSS:3.1 vector of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, impact is limited to integrity and exploitation requires a pre-existing account plus a department context whose roles will actually delegate the injected grants. Publicly available proof-of-concept exploit code exists, making the issue practically reproducible, but there is no confirmed active exploitation (CISA KEV) at time of analysis.
Low-privileged authenticated users of JeecgBoot through 3.9.5 can read department permission records they should not be authorized to see by issuing GET requests to /sys/sysDepartPermission/queryById with an arbitrary department id, exposing depart_id, permission_id and data_rule_ids values. The flaw is a missing authorization check in the SysDepartPermissionController queryById handler (CWE-862), rated 5.3 with an assessed vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N, so exploitation is limited to confidentiality impact and requires only a valid account with no administrative role. Publicly available exploit code exists (a Python PoC published by VulnCheck-referenced researchers), and the issue is not listed in CISA KEV as actively exploited; EPSS data was not provided, so no exploitation-likelihood estimate can be cited.
Authenticated low-privileged users can delete department permission bindings in JeecgBoot through 3.9.5 by calling the SysDepartPermissionController delete handler, which performs no authorization check (CWE-862). Because the corresponding list endpoint is also unguarded, an attacker can enumerate the required row ids and then issue DELETE requests that strip menu and button grants from department roles, degrading the instance's RBAC configuration. Publicly available exploit code exists, and the flaw affects default deployments, but the impact is bounded to integrity/availability of permission data - no data disclosure and no privilege escalation beyond RBAC degradation - which is why the vendor score is a moderate 5.3.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user, including low-privileged accounts, to overwrite department permission records through the unprotected edit (PUT) endpoint of SysDepartPermissionController, changing depart_id, permission_id and data_rule_ids values that control which menus and data rules departments may delegate. A companion list endpoint is likewise unguarded, so attackers can enumerate valid record ids before issuing the modification requests. Publicly available exploit code exists (no confirmed active exploitation), and the flaw is rated moderate - CVSS 4.0 base 5.3 with integrity-only impact - requiring only a valid authenticated account of any privilege level per the CVSS vector (PR:L).
Any authenticated JeecgBoot user - regardless of privilege level - can add, modify or clear department data-rule bindings by POSTing departId, permissionId and dataRuleIds to /sys/sysDepartPermission/datarule, because the saveDatarule handler in SysDepartPermissionController performs no authorization check, in versions through 3.9.5. Publicly available exploit code exists, but no active exploitation is confirmed (not in CISA KEV). With a CVSS 5.3 rating reflecting network reachability, low privileges required and only low integrity impact, realistic risk concentrates in multi-department or multi-tenant deployments where untrusted low-privilege accounts exist.
Missing authorization in JeecgBoot through 3.9.5 lets any authenticated user read role data-rule metadata - rule names, columns, conditions, values and bound rule IDs - for arbitrary roles via GET /sys/role/datarule/{permissionId}/{roleId}. The loadDatarule handler in SysRoleController omits the authorization check that its sibling endpoints enforce, so a low-privileged account (PR:L, unauthenticated access does not work) can enumerate permissionId/roleId pairs and exfiltrate the row-level access-control policy of the whole tenant. Impact is information disclosure only (CWE-862, no write, no code execution); publicly available exploit code exists, and the CVE is not in CISA KEV.
Missing authorization in JeecgBoot's SysMessageController queryById handler (all versions through 3.9.5) lets any authenticated user, at any privilege level, read the message push records of other accounts by supplying arbitrary record IDs to GET /sys/message/sysMessage/queryById, exposing message content and receiver addresses. The impact is read-only information disclosure - no integrity or availability effect - and exploitation requires a valid low-privileged session plus knowledge or enumeration of valid message record IDs, making this a moderate-risk IDOR rather than a pre-authentication compromise path (CVSS 4.0 base 5.3; independently assessed CVSS 3.1 5.3, PR:L, C:L). Publicly available exploit code exists (a Python PoC linked from the VulnCheck advisory), but there is no confirmation of active exploitation (CISA KEV).
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated user holding a low-privileged account to overwrite arbitrary message-push records by sending a PUT request to /sys/message/sysMessage/edit with any sys_sms record id in the body, changing the record's title, content, receiver address and send status without any ownership check. The flaw is confined to integrity tampering of message records - there is no confidentiality or availability impact - and exploitation requires a valid account plus network reachability to the application's REST API, so unauthenticated attacks are not possible. Publicly available exploit code exists, making the issue straightforward to reproduce, but active exploitation has not been confirmed and no vendor-released patch was identified at time of analysis.
Deletion of arbitrary message records in JeecgBoot through 3.9.5 is possible by low-privileged authenticated users due to missing authorization in the SysMessageController deleteBatch handler. Attackers can obtain record IDs from an unguarded list endpoint and submit them to deleteBatch to remove pending queued messages, disrupting notification delivery. Publicly available exploit code exists, but the vulnerability is not listed in CISA KEV, and the CVSS 4.0 score is 5.3, indicating moderate severity.
Authenticated, low-privileged users of JeecgBoot through 3.9.5 can delete arbitrary audit log records because the SysLogController delete handler performs no authorization check, allowing an attacker holding any valid login to erase traces of their activity. Log identifiers are freely obtainable from the unguarded /sys/log/list endpoint, so the attack needs no elevated role, only a session. Publicly available exploit code exists (a Python PoC for the log-delete request), and the impact is limited to integrity and availability of log data with no confidentiality exposure.
Missing authorization in the JeecgBoot SysPositionController edit handler (/sys/position/edit) lets any authenticated low-privileged account rewrite organizational position names, codes, and ranks via crafted PUT or POST requests, affecting JeecgBoot through 3.9.5. Because the position list endpoint is also unguarded, an attacker can first enumerate valid position IDs and then target them directly, so no guesswork or elevated role is required. Impact is confined to the integrity of position reference data - there is no confidentiality or availability loss and no escalation to system compromise - and the issue is correctly rated medium (CVSS 5.3); publicly available exploit code exists, while no CISA KEV active-exploitation entry is indicated.