Description

Frappe HR (hrms) before 16.11.0, including all 14.x and 15.x releases through 15.64.3, contains a missing authorization vulnerability in the whitelisted expire_allocation method that allows authenticated users to expire any leave allocation. Attackers without HR roles can name another employee's Leave Allocation in a POST request to zero its allocated leaves and wipe that employee's remaining leave balance.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-10-11T13:17:17.490Z",
  "pubdate": "2026-10-11T13:17:17.490Z",
  "executiveSummary": "The Frappe HR (hrms) application is susceptible to a missing authorization vulnerability within the 'expire_allocation' method, which is marked as a whitelisted API endpoint. This flaw permits authenticated users, regardless of their role or permission level, to invoke the function against arbitrary 'Leave Allocation' records. By manipulating the input parameters of a POST request, an attacker can prematurely terminate any employee's leave allocation, effectively zeroing out their accrued leave balance. The vulnerability impacts all 14.x and 15.x versions up to 15.64.3, as well as versions prior to 16.11.0. The primary risk involves unauthorized data modification and operational disruption regarding human resources records. Exploitation requires valid application authentication but does not necessitate high-level privileges such as 'HR User' or 'HR Manager', making it accessible to any standard authenticated user within the system environment.",
  "technicalDetails": "The vulnerability resides in the 'expire_allocation' method within the Frappe HR (hrms) module. The method is explicitly whitelisted for API access, allowing it to be called via POST requests from the client side. The root cause of this security defect is the absence of server-side authorization checks (permission validation) before the method processes the input and executes the state-changing operation on the database.\nThe application fails to verify whether the authenticated user initiating the request possesses the necessary 'HR' permissions to modify leave records belonging to other employees. Because the method accepts a reference to a specific 'Leave Allocation' document, an attacker can perform an Insecure Direct Object Reference (IDOR) style attack. By supplying the name or identifier of a 'Leave Allocation' record belonging to a victim, the attacker bypasses intended business logic constraints.\nThe attack flow follows a predictable pattern: 1) The attacker obtains the identifier for the target 'Leave Allocation' document, which is often predictable or discoverable via standard list view API responses accessible to standard users. 2) The attacker crafts a POST request targeting the 'expire_allocation' endpoint, inserting the target's allocation name into the request body parameters. 3) The server, failing to validate user permissions, invokes the backend logic to update the status of the specified record to 'Expired' and updates the related leave balances to zero. 4) The 'Leave Allocation' database record is immediately updated, effectively wiping the victim's remaining leave balance without their knowledge or consent.\nThis vulnerability is particularly severe because the function performs a destructive write operation without confirming authorization, violating the principle of least privilege. The impact is a total loss of leave integrity for any user in the system, which can be leveraged for unauthorized payroll manipulation or organizational disruption. The lack of granular, role-based access control (RBAC) at the method level serves as the fundamental failure point for the component in all affected versions (14.x, 15.x up to 15.64.3, and pre-16.11.0)."
}