CVE-2026-63431 in Horilla
Summary
by MITRE • 09/26/2026
Horilla is an HR and CRM software. In 1.5.0-85 and earlier, payroll/views/component_views.py does not consistently authorize access in allowances_deductions_tab, view_single_allowance, and view_single_deduction before loading records selected by emp_id, allowance_id, or deduction_id. An authenticated employee can substitute those identifiers to read another employee's salary structure, allowance and deduction amounts, personal loan disbursements, and repayment schedules without owning the record or holding payroll-view permissions. No complete fixed version is available as of this review.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified in Horilla HR and CRM software versions 1.5.0-85 and earlier represents a critical failure in access control mechanisms within the payroll module. Specifically, the flaw resides in the file payroll/views/component_views.py, where functions such as allowances_deductions_tab, view_single_allowance, and view_single_deduction fail to enforce proper authorization checks before processing requests. This architectural deficiency allows for insecure direct object references, a common vulnerability pattern classified under CWE-639: Insecure Direct Object Reference. The core issue is that the application relies on client-supplied identifiers—specifically emp_id, allowance_id, and deduction_id—to retrieve sensitive financial data without verifying whether the authenticated user requesting access has legitimate ownership of these records or holds the necessary payroll-view permissions.
From a technical perspective, this vulnerability enables horizontal privilege escalation for any authenticated employee within the system. By manipulating the input parameters sent to the vulnerable endpoints, an attacker can substitute their own employee identifier with that of another colleague. Since the backend logic does not validate if the requesting user is authorized to view the data associated with the provided identifiers, it proceeds to load and return the requested records. This lack of server-side validation means that the application trusts client-supplied input implicitly regarding access rights, a fundamental security anti-pattern that undermines the integrity of role-based access control models implemented at higher levels or in other parts of the system.
The operational impact of this vulnerability is severe due to the sensitivity of the data exposed. An attacker can read another employee's complete salary structure, including base pay and variable components. Furthermore, they gain visibility into specific allowance amounts and deduction details, which often contain personal financial information such as tax contributions or insurance premiums. The exposure extends further to include personal loan disbursements and repayment schedules, revealing deeply private financial obligations of colleagues. This level of data leakage not only violates employee privacy expectations but also exposes the organization to significant legal and regulatory risks under data protection laws such as GDPR or CCPA, which mandate strict controls over personally identifiable information and sensitive financial records.
This vulnerability aligns with several entries in the MITRE ATT&CK framework, particularly T1078: Valid Accounts, where an attacker uses legitimate credentials to access resources they are not authorized for, and potentially T1530: Data from Cloud Storage if such data is considered stored assets within the application database. The absence of a complete fixed version as of the review date exacerbates the risk profile, leaving organizations using these versions exposed indefinitely unless manual mitigations are applied.
To mitigate this vulnerability in the interim, developers must implement strict server-side authorization checks for all endpoints involved in payroll data retrieval. This involves verifying that the authenticated user's identity matches the emp_id associated with the requested resource or confirming that the user possesses explicit permissions to view records belonging to other employees if such cross-viewing is a legitimate business requirement. Input validation should also be enforced to ensure that identifiers correspond to valid, existing objects within the database before any processing occurs. Additionally, implementing principle of least privilege ensures that users only have access to data strictly necessary for their role. Until an official patch is released by Horilla, organizations should consider restricting network-level access to these specific endpoints or disabling payroll features if not actively used, while closely monitoring logs for unusual patterns in employee ID substitution attempts.