Description

JeecgBoot through 3.9.5 contains a missing authorization vulnerability that allows low-privileged authenticated users to modify any department by calling PUT /sys/user/doUpdateDepartInfo. Attackers can supply a department id to rename or re-parent it and replace or remove its department heads without ownership or tenant checks.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-10-11T15:16:54.060Z",
  "pubdate": "2026-10-11T15:16:54.060Z",
  "executiveSummary": "JeecgBoot through version 3.9.5 contains a critical missing authorization vulnerability (Broken Access Control) within its department management functionality.\nThe flaw allows low-privileged authenticated users to execute unauthorized modifications to any department record by invoking the PUT /sys/user/doUpdateDepartInfo endpoint.\nThe vulnerability stems from a lack of server-side ownership and tenant validation, permitting attackers to rename, re-parent, or manipulate the leadership structure of arbitrary departments.\nThis impact extends to multi-tenant environments where an attacker can modify data across different organizational boundaries.\nExploitation requires active authentication but bypasses intended privilege levels, posing a significant risk to organizational integrity and data compartmentalization.\nThe flaw allows unauthorized users to modify organizational hierarchy, potentially leading to privilege escalation through the assignment or removal of department heads.",
  "technicalDetails": "The vulnerability resides in the backend request handling for the /sys/user/doUpdateDepartInfo endpoint within JeecgBoot, affecting all versions up to and including 3.9.5.\nRoot cause analysis indicates that the controller handling the PUT request fails to implement sufficient authorization checks to verify if the authenticated user possesses the necessary permissions to perform department modifications.\nFurthermore, the implementation fails to perform mandatory multi-tenant isolation, allowing requests to proceed regardless of whether the target department ID belongs to the attacker's assigned organization or scope.\nExploitation is achieved through a crafted HTTP PUT request to /sys/user/doUpdateDepartInfo. An attacker, despite having only low-privileged access, can submit a JSON payload containing a target department identifier (id).\nBy manipulating the parameters in the request, the attacker can influence the state of the backend database. Specifically, the attacker can force the application to perform administrative actions such as renaming the department, modifying the parent-child relationship (re-parenting), or performing destructive operations on the department head assignments (e.g., swapping or deleting existing personnel).\nBecause the system trusts the incoming request parameters without verifying the user's authorization context against the resource's ownership, the application logic executes the update operation directly in the database.\nThe lack of tenant-level filtering ensures that this vulnerability is not restricted to a single organizational unit, but theoretically impacts the entire global instance of the JeecgBoot deployment.\nThe impact of a successful attack includes unauthorized structural changes to the organization, potential disruption of departmental workflows, and administrative privilege escalation by assigning the attacker or a malicious actor as the head of a department. This effectively allows an attacker to manipulate the organizational hierarchy, which may have downstream effects on access control lists (ACLs) or role-based access control (RBAC) configurations if these rely on department-based attributes."
}