JeecgBoot EUVD-2026-96572

Requires a valid authenticated session as any low-privileged JeecgBoot user (PR:L) - no admin role and no user interaction are needed, matching the AV:N/AC:L/UI:N vector. The specific prerequisite is reaching the POST /sys/sysDepartPermission/add endpoint, which performs no authorization check, allowing arbitrary departId, permissionId, and dataRuleIds values to bind grants to any department. Exploitation is limited by the need for a pre-existing account and by the indirect impact: meaningful privilege escalation depends on the attacker belonging to, or controlling roles within, the targeted department so the injected menu/button/data-rule grants are actually delegated. Affects JeecgBoot versions up to and including 3.9.5 in default configuration.

This is a medium-severity, authenticated access-control flaw (CWE-862) rather than a top-tier priority. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) confirms a network-reachable, low-complexity endpoint, but PR:L means the attacker must already hold a valid low-privileged account, and the impact is limited to integrity (VC:N/VI:L/VA:N) - there is no confidentiality or availability loss, which is why the base score is only 5.3. A public POC exists (VulnCheck-reported, GitHub script), lowering the exploitation barrier, so this qualifies as 'publicly available exploit code exists' - but it is NOT in CISA KEV and there is no confirmed active exploitation. EPSS and SSVC data are NOT provided in the input, so exploitation-probability and automatability cannot be quantified - do not assume widespread opportunistic scanning. The signals are internally consistent (no CVSS-vs-description conflict): a logged-in user abuses a missing authorization check to write permission bindings. Real-world danger hinges on whether the injected department grants actually propagate to the attacker's own roles - a plausible privilege-escalation chain but one requiring a follow-on condition rather than a single-shot takeover.

A low-privileged but authenticated JeecgBoot user sends a crafted POST to /sys/sysDepartPermission/add containing an arbitrary departId plus attacker-chosen permissionId and dataRuleIds, binding high-value menu, button, and data-rule grants to a department they influence. Because the endpoint omits the authorization check, the grants are accepted and can then be delegated to that department's roles, escalating the attacker's effective privileges. A working POC script (poc_depart_permission_add.py) is publicly available, so no original exploit development is required.