JeecgBoot EUVD-2026-96569

Requires a valid authenticated JeecgBoot account of any privilege level (PR:L) - the attacker does not need admin rights. The specific prerequisite is reachability of the SysDepartPermissionController edit (PUT) endpoint, which lacks an authorization check, combined with the companion list endpoint being unguarded so valid record ids can be enumerated. No user interaction and no special non-default configuration are stated as required; the primary limiting factor is that the attacker must first hold authenticated access to the application, so instances with no untrusted or low-trust user accounts, or not network-exposed, are materially less exposed. Affected: JeecgBoot through 3.9.5.

This is a broken-access-control (CWE-862 missing authorization) flaw in JeecgBoot's SysDepartPermissionController, rated moderate (input CVSS 4.0 base 5.3). All signals point to a real-but-not-critical issue rather than a top-priority emergency. The CVSS 4.0 vector (AV:N/AC:L/PR:L/UI:N) confirms network-reachable, low-complexity exploitation requiring a valid authenticated account, with impact limited to integrity (VI:L) and no confidentiality or availability loss (VC:N/VA:N) - consistent with the description of an authenticated user tampering with department permission records. Exploit code is publicly available (VulnCheck-reported POC), which raises practical risk, but there is NO CISA KEV listing and NO EPSS score was supplied, so there is no evidence of active exploitation and widespread automated attack probability cannot be quantified from the provided data. SSVC-style reading: exploitation is 'POC', technical impact is partial (not total), and the attacker already needs authenticated access, so this is best treated as a privilege/authorization-hardening priority on exposed multi-tenant JeecgBoot deployments rather than a drop-everything remote-takeover bug. Key missing data: no EPSS, no KEV, and no vendor patch version is provided in the input, so remediation timing cannot be anchored to a confirmed fixed release.

A low-privileged but authenticated JeecgBoot user queries the unguarded department-permission list endpoint to harvest valid record ids, then sends a crafted PUT request to the SysDepartPermissionController edit endpoint. Because the edit endpoint performs no authorization check, the attacker overwrites depart_id, permission_id, and data_rule_ids to grant their own (or another) department additional menus and data rules. A working Python POC (poc_depart_permission_edit_put.py) is publicly available, lowering the effort required.