CVE-2026-109376 in ERPNext
Summary
by MITRE • 10/13/2026
ERPNext 15.55.0 through 16.50.0 contains an incorrect authorization vulnerability in the get_timesheet_html method that lets authenticated portal users view project Timesheets. The method only checks Project read access, ignoring hide_timesheets and project membership, so attackers can retrieve timesheet names, status, time-log dates and last modifiers.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/13/2026
The identified vulnerability resides within ERPNext versions 15.55.0 through 16.50.0, specifically affecting the get_timesheet_html method which is accessible to authenticated portal users. This flaw represents a classic case of broken access control where the application fails to enforce proper authorization policies for sensitive data retrieval operations. The core technical issue stems from an incomplete security check within the backend logic that processes requests for timesheet information. While the system correctly verifies whether the requesting user has read permissions on the associated project, it completely neglects two critical security controls: the hide_timesheets configuration flag and explicit project membership requirements. This oversight allows any authenticated portal user who can access a specific project to bypass intended restrictions and retrieve detailed timesheet data regardless of their actual role or visibility settings within that project structure.
From an operational perspective, this vulnerability enables unauthorized information disclosure regarding employee work logs and billing details. Attackers with valid credentials for the ERPNext portal can exploit this flaw to extract sensitive internal metrics including specific timesheet names, current status indicators, precise time-log dates, and identities of last modifiers. This data leakage poses significant risks to organizational privacy and operational security. The exposure of who modified records and when they did so can reveal internal workflows, resource allocation patterns, and potentially identify key personnel involved in specific projects. Furthermore, the ability to view timesheet statuses may allow attackers to infer project progress or financial billing cycles without authorization, providing intelligence that could be leveraged for further social engineering attacks or competitive espionage.
The technical classification of this vulnerability aligns with CWE-284 Improper Access Control and CWE-601 URL Redirection to Untrusted Site if the timesheet data includes external links, though primarily it is an access control bypass on sensitive resources. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1530 Data from Cloud Storage Object or more accurately T1005 Data from Local System depending on how ERPNext stores and serves these timesheet records, as well as T1078 Valid Accounts since exploitation requires initial authentication. The vulnerability highlights a common pattern in web application development where developers assume that checking access at the parent object level (the project) is sufficient to secure child objects (timesheets), failing to account for granular permission settings like hide_timesheets which are designed specifically to restrict visibility of such subordinate data elements even when parent-level access exists.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective solution involves updating ERPNext to a version where this authorization logic has been corrected, ensuring that the get_timesheet_html method explicitly validates hide_timesheets flags and verifies strict project membership before returning any timesheet data. For organizations unable to patch immediately due to dependency constraints or testing requirements, temporary mitigations should include restricting portal user access levels through network-level controls such as firewalls or web application firewalls that block requests targeting the specific endpoint associated with this method. Additionally, implementing rigorous input validation and ensuring that all API endpoints undergo comprehensive security reviews against CWE-284 standards can prevent similar flaws in future development cycles. Regular penetration testing focused on horizontal privilege escalation and object-level permission checks is recommended to identify analogous vulnerabilities across other modules within the ERPNext ecosystem before they are exploited by malicious actors seeking sensitive organizational data.