Description

Kimai before 2.64.0 contains a missing authorization vulnerability in the ProjectViewController export route (report_project_view_export). The authorization guards are attached to the sibling __invoke method rather than at the class level, so the export route inherits no authorization checks. Any authenticated user, including a plain ROLE_USER without the project_reporting permission, can download the project overview export - which returns the same dataset as the protected report - disclosing customer names, project names, currency, budget type, and aggregate totals across all customers. Actual financial figures remain protected in the export template.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.3",
  "pubDate": "2026-08-26T05:18:26.780Z",
  "pubdate": "2026-08-26T05:18:26.780Z",
  "executiveSummary": "A missing authorization vulnerability exists in the ProjectViewController of Kimai versions prior to 2.64.0. The vulnerability resides within the report_project_view_export route, which fails to enforce access control checks.\nThis flaw allows any authenticated user, regardless of their assigned role (e.g., ROLE_USER), to bypass intended security restrictions and execute the export functionality. Consequently, unauthorized actors can access and exfiltrate sensitive project metadata including customer names, project names, currency types, budget configurations, and financial aggregate totals.\nThe vulnerability represents a significant information disclosure risk. Because the access control mechanism is incorrectly scoped, the application fails to validate the necessary 'project_reporting' permissions before processing data export requests. Attackers require only standard authenticated access to the application to exploit this vulnerability. While granular financial figures are protected by the underlying template logic, the exposure of organizational structure and budget data provides substantial reconnaissance data that could facilitate further targeting or business intelligence compromise.\nOrganizations using affected versions of Kimai are at risk of unauthorized sensitive data access and should prioritize updating the application to version 2.64.0 or later to ensure that proper authorization guards are correctly implemented at the controller or method level.",
  "technicalDetails": "The root cause of this vulnerability is a design flaw in the authorization middleware implementation within the Kimai application framework. Specifically, in the ProjectViewController class, security guards and access control logic are explicitly defined within the __invoke() method rather than being applied globally at the class level or enforced through middleware for all associated routes.\nIn the Symfony-based architecture utilized by Kimai, routing definitions map specific URL patterns to controller methods. The report_project_view_export route is configured to execute functionality that generates data exports. Because the authorization guards were incorrectly scoped to the __invoke() method, the export route fails to inherit the required permission checks. When a request is made to the report_project_view_export endpoint, the application bypasses the check for the 'project_reporting' permission that is strictly required for the standard report view.\nThe exploitation flow is straightforward: 1) An attacker authenticates to the Kimai platform with a low-privileged account (ROLE_USER). 2) The attacker identifies the report_project_view_export endpoint via internal reconnaissance or web traffic analysis. 3) The attacker crafts a GET request to the vulnerable export route. 4) The application, failing to trigger the necessary authorization listener due to the scope misconfiguration, processes the request by executing the export generation logic. 5) The server returns a structured data export (such as CSV or Excel) containing the aggregated project metadata.\nThe vulnerability affects Kimai versions prior to 2.64.0. The exposure includes critical business data such as customer names, project titles, budget types, and project-wide financial aggregates. While the vulnerability does not allow for remote code execution (RCE) or direct database modification, the post-exploitation impact includes the unauthorized harvesting of client lists and budgetary health, which can be leveraged for competitive intelligence or as a precursor to more sophisticated social engineering attacks. The lack of proper authorization prevents the application from maintaining the principle of least privilege, as any authenticated user is granted access to high-value reporting data intended only for users with project management or reporting permissions."
}