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.
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.
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.
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.
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.
Any authenticated user, including low-privileged accounts, can delete organizational positions in JeecgBoot 3.9.5 and earlier by exploiting a missing authorization check in the SysPositionController deleteBatch handler. Attackers harvest valid position IDs from an unguarded list endpoint and submit them as a comma-separated list, destroying sys_position records and orphaning user-position assignments. This is a moderate-severity data-destruction issue, reflected by the assessed CVSS 3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L; publicly available exploit code exists, but no active exploitation is confirmed in CISA KEV.
Missing authorization in JeecgBoot through 3.9.5 lets any low-privileged authenticated user delete SMS message templates by issuing a DELETE request to /sys/message/sysMessageTemplate/deleteBatch with comma-separated IDs harvested from the separately unguarded template list endpoint. The result is integrity and availability loss confined to the sys_sms_template table - deletion of all template rows breaks template-driven notifications such as workflow reminders - with no confidentiality exposure, making this a genuine but moderate-severity issue rather than a top-priority emergency. Publicly available exploit code exists (a PoC script deleting routes is published on GitHub), but there is no confirmation of active exploitation (not in CISA KEV), and exploitation still requires a valid authenticated session plus network reachability to the management API.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to delete AI evaluator records via the AiragExtDataController deleteBatch handler. The endpoint DELETE /airag/extData/deleteBatch accepts comma-separated IDs and lacks owner or tenant checks, enabling deletion of other users' evaluator and test-tracking records. Publicly available exploit code exists, but exploitation requires a valid low-privileged session and the AiRAG module to be enabled; this is a medium-severity broken access control issue (CWE-862) with no confidentiality or code execution impact.
Authenticated users of JeecgBoot through 3.9.5 holding only low privileges can delete other users' AI evaluator and test-tracking records by sending a DELETE request to the /airag/extData/delete endpoint with an arbitrary id value, because the AiragExtDataController delete handler performs no owner or tenant ownership check (CWE-862). The flaw is remote and network-reachable and requires a valid session (CVSS PR:L), so anonymous attackers cannot exploit it, and the impact is limited to integrity and availability of AI-RAG records rather than confidentiality loss or code execution. Publicly available exploit code exists (a Python PoC is published on GitHub), but there is no CISA KEV confirmation of active exploitation; independent assessment rates this as a genuine but moderate-severity access-control issue, with the missing tenant check acting as a risk amplifier in multi-tenant deployments where cross-tenant deletion becomes possible.
Missing authorization in JeecgBoot 3.9.5 and earlier allows any authenticated low-privileged user to publish or unpublish AI applications owned by other users by sending a POST request to /airag/app/release, enabling them to harvest share tokens that expose other tenants' AI applications to anonymous chat access or to invalidate existing share links. The defect is CWE-862, and the assessed impact is limited to low integrity and low availability with no confidentiality loss, scored 5.3 (CVSS 3.1: AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L; vendor-supplied CVSS 4.0 vector similarly shows PR:L with VI:L/VA:L). Publicly available exploit code exists, but there is no confirmation of active exploitation (no CISA KEV listing in the provided data). Because the vector requires PR:L and UI:N, the realistic threat is an insider or an attacker holding compromised low-privileged credentials with network reachability to the airag module, not an anonymous internet attacker.
Missing authorization in JeecgBoot through version 3.9.5 allows authenticated low-privileged users to delete arbitrary word templates from the shared library via the /airag/word/deleteBatch endpoint. The flaw resides in the AigcWordTemplateController's deleteBatch handler, which fails to enforce proper access controls (CWE-862), enabling an attacker with any valid account to permanently remove templates by sending a DELETE request with comma-separated IDs. Publicly available exploit code exists, and while the impact is limited to integrity and availability of templates (no confidentiality loss), it represents a medium-severity, low-priority risk for deployments exposing the AIRAG module to semi-trusted users.
Deleting word templates in JeecgBoot through 3.9.5 is not access-controlled: the AigcWordTemplateController delete handler behind DELETE /airag/word/delete accepts an id parameter from any authenticated account and permanently removes the referenced template from the shared library, including templates owned by other users. Exploitation is remote and requires only a valid low-privileged JeecgBoot login (CVSS PR:L) with the AIRAG word-template module deployed and reachable; publicly available exploit code exists, though there is no confirmation of active exploitation in the wild. Impact is confined to integrity and availability of the template library - no data disclosure, no code execution - making this a genuine but low-tier priority where exposure depends on how freely low-privileged accounts are provisioned.
Authenticated low-privileged users of JeecgBoot through 3.9.5 can delete arbitrary shared OCR prompt records via the AiOcrController deleteById handler, which performs no authorization or ownership check. Attackers first enumerate record IDs from the unguarded GET /airag/ocr/list endpoint and then repeatedly invoke the delete action, wiping records stored in Redis. Publicly available exploit code exists (GitHub PoC), and the issue is rated moderate (assessed CVSS 3.1 5.3, PR:L) because it requires a valid account and only affects availability/integrity of OCR records, with no confidentiality or code-execution impact.
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 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.
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.
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).
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.
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.
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 the AiragExtDataController exportXls handler of JeecgBoot (through 3.9.5) allows any authenticated account, regardless of role, to download every user's airag_ext_data records - AI evaluator definitions and test-tracking data - as an Excel workbook via a request to /airag/extData/exportXls. Exploitation requires a valid account of any privilege level (CVSS 3.1 AV:N/AC:L/PR:L/UI:N, scored 5.3) and only affects instances that actually deploy the airag module; publicly available exploit code exists, but there is no confirmed active exploitation (CISA KEV). Because the impact is read-only information disclosure (C:L, no integrity or availability effect), this is a moderate-priority exposure tied to the sensitivity of the exported AI evaluator and prompt data rather than a critical one.
Authenticated users of JeecgBoot through 3.9.5 can read other users' AI voice-generation history by supplying an arbitrary victim identifier in the userId parameter of GET /airag/voice/listByUser, an insecure direct object reference (CWE-639) in the airag voice controller where the endpoint trusts the client-supplied id instead of the session identity. Requirement to exploit is a valid low-privilege account (CVSS vector PR:L) plus knowledge or enumeration of another user's id, after which an attacker can retrieve submitted text-to-speech input, voice settings, timestamps, and generated audio file names and paths stored in Redis; no user interaction or elevated privilege is needed and the AI voice module must be present and in use. Impact is confidentiality-only with no write or availability effect, and publicly available exploit code exists (no confirmation of active exploitation and no KEV listing).
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 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.
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).
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.
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.
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 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.
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.
Low-privileged authenticated users of JeecgBoot through 3.9.5 can overwrite system notification templates via the PUT /sys/message/sysMessageTemplate/edit endpoint, which lacks an authorization check, allowing attacker-controlled text or links to be injected into messages delivered to other users. Publicly available exploit code exists, but exploitation requires a valid low-privileged account and enumeration of template IDs from an unguarded list endpoint; there is no confirmed active exploitation (not in CISA KEV). The impact is confined to integrity tampering of notification content, with no confidentiality or availability impact per the assessed CVSS:3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N).
Missing function-level authorization in JeecgBoot through 3.9.5 (CWE-862) allows any authenticated user holding only a low-privileged role to create arbitrary notification templates by calling POST /sys/message/sysMessageTemplate/add. Because the SysMessageTemplateController handler performs no permission check, an attacker with minimal credentials can insert templates with attacker-chosen codes and content into the shared sys_sms_template library used for system, email, SMS and IM notifications, giving an integrity-only impact on the template store rather than host or data compromise. Publicly available exploit code exists (no CISA KEV confirmation of active exploitation), and our independent assessment scores this as a medium-severity authorization flaw (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N) that is not an urgent priority.
Any low-privileged authenticated user of JeecgBoot through 3.9.5 can overwrite shared Word document templates by sending PUT or POST requests to the /airag/word/edit endpoint, because the AigcWordTemplateController edit handler performs no authorization or ownership check. The impact is limited to integrity of shared templates used by other users for document generation - no data disclosure or service disruption - with an assessed severity of CVSS 3.1 5.3 (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N). Publicly available exploit code exists (a proof-of-concept Python script published on GitHub), though there is no indication of confirmed active exploitation (no CISA KEV listing), and exploitation requires valid credentials plus a deployment where the AIRAG word-template feature is enabled and in use.
Authenticated JeecgBoot users running version 3.9.5 or earlier can delete other users' stored AI voice (text-to-speech) history by passing an arbitrary userId to the DELETE /airag/voice/deleteVoiceRecord endpoint, which trusts the client-supplied identifier instead of the caller's session identity. Victims' record IDs are easily enumerated from the ownership-unchecked GET /airag/voice/listByUser endpoint, and deletion proceeds one record per request against history held in Redis; a publicly available exploit script is referenced in the VulnCheck advisory. Impact is limited to unauthorized modification (loss) of voice records with no confidentiality or host availability impact, there is no CISA KEV listing, and any valid authenticated account, regardless of privilege level, is sufficient to exploit the flaw.
Authenticated users can delete other users' AI video generation records in JeecgBoot through 3.9.5 by exploiting an insecure direct object reference (IDOR) in the DELETE /airag/video/deleteVideoRecord endpoint, which accepts arbitrary userId values without ownership checks. Attackers can first retrieve record IDs from the unchecked GET /airag/video/listByUser endpoint, then delete victims' Redis-stored video history entries one record per request. Publicly available exploit code exists (no CISA KEV confirmation), and exploitation requires a valid authenticated account; impact is limited to integrity of video history records with no confidentiality or availability impact.
Missing authorization in JeecgBoot through 3.9.5 allows any authenticated low-privileged user to overwrite the global OCR/LLM prompt templates used by the AiRAG module by sending a PUT request to /airag/ocr/edit, writing attacker-controlled content into the shared airag:ocr Redis key and corrupting OCR output for every user of the instance. Exploitation requires only a valid low-privilege account (PR:L in the CVSS vector) and no user interaction, and publicly available exploit code exists; the issue is not listed as confirmed actively exploited (CISA KEV). The impact is confined to integrity tampering with shared prompt configuration - no data disclosure and no denial of service - which is consistent with the assessed CVSS:3.1 vector AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N and makes this a genuine but low-to-moderate priority issue.
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 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.