CVE-2026-63432 in Horilla
Summary
by MITRE • 09/26/2026
Horilla is an HR and CRM software. From 1.0.0 until 1.6.0 and 2.0.0, the get_mail_preview handlers in recruitment/views/actions.py and employee/not_in_out_dashboard.py render a user-controlled body at /recruitment/get-mail-preview/ and /employee/get-employee-mail-preview with the full request object in the Django template context. An authenticated user with a valid CSRF token can use template attribute traversal to read request.user.password, request.META, and related-user attributes, exposing password hashes, personal data, and server request metadata. Django template restrictions prevent arbitrary code execution through this primitive, so the demonstrated impact is information disclosure and possible offline password cracking or account compromise. This issue is fixed in versions 1.6.0 and 2.0.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/26/2026
The vulnerability identified within Horilla HR and CRM software represents a critical server-side template injection flaw that facilitates unauthorized data exposure through attribute traversal techniques. In the affected version range, specifically from release 1.0.0 up to versions 1.6.0 and 2.0.0, specific view handlers responsible for rendering email previews contain a fundamental logic error in how they process user input within Django template contexts. The endpoints /recruitment/get-mail-preview/ and /employee/get-employee-mail-preview are designed to display preview content based on request parameters; however, the implementation inadvertently includes the entire HTTP request object directly into the template context without sufficient sanitization or restriction of accessible attributes. This architectural oversight allows an authenticated attacker who possesses a valid Cross-Site Request Forgery token to manipulate the rendering process by injecting malicious template syntax that traverses object properties in ways not intended by the application developers.
The technical mechanism exploited here relies on Django's template language capabilities, which allow for attribute lookup and method invocation on objects passed into the context. By leveraging this feature, an attacker can construct a payload that accesses sensitive attributes of the request.user object, such as password hashes stored via hashers like PBKDF2 or bcrypt. Additionally, the vulnerability permits access to the request.META dictionary, which contains valuable server-side metadata including environment variables, session identifiers, and potentially internal network information. The exploitation also extends to accessing related-user attributes, thereby exposing personal data associated with other employees within the system. This capability transforms a seemingly benign email preview function into a powerful vector for extracting sensitive organizational intelligence that should remain strictly confidential.
From an operational impact perspective, this vulnerability leads directly to significant information disclosure and potential account compromise through offline password cracking attacks. The exposure of user password hashes allows attackers to perform brute-force or dictionary-based attacks against the stored credentials without triggering immediate detection mechanisms associated with repeated login failures. Furthermore, the leakage of personal data violates privacy regulations such as GDPR in many jurisdictions and undermines employee trust by exposing sensitive HR records. While Django's template engine imposes certain restrictions that prevent direct arbitrary code execution via this specific primitive, the ability to read internal state variables effectively neutralizes confidentiality controls implemented at the application layer. The requirement for a valid CSRF token indicates that while authentication is necessary, it does not mitigate the risk of cross-site request forgery if proper anti-CSRF measures are bypassed or if the attacker can social-engineer an authenticated user into triggering the malicious payload.
This vulnerability aligns with CWE-94 Improper Control of Generation of Code (Code Injection) and more specifically CWE-78 Improper Neutralization of Special Elements used in an OS Command, although in this context it manifests as template injection leading to information disclosure under CWE-200 Exposure of Sensitive Information to an Unauthorized Actor. In terms of the MITRE ATT&CK framework, this activity corresponds to T1530 Data from Local System Extraction and potentially T1078 Valid Accounts if used for lateral movement after credential cracking. The exploitation path also reflects aspects of T1552 Unsecured Credentials as it involves accessing stored password hashes directly rather than intercepting them in transit.
Mitigation strategies must prioritize immediate patching to the fixed versions 1.6.0 and 2.0.0 where these template context issues have been resolved by developers who likely implemented stricter filtering or removed direct access to sensitive request attributes from the template scope. For organizations unable to upgrade immediately, implementing a Web Application Firewall rule set that detects common Django template injection patterns such as double curly braces followed by specific attribute names can provide temporary protection. Additionally, ensuring that CSRF tokens are tightly coupled with session validation and rotating all user passwords proactively is essential given the high likelihood of hash exposure in deployed instances. Regular security audits focusing on how request objects are passed to templating engines should be conducted to prevent similar architectural flaws in future development cycles.