CVE-2026-80194 in Kimai
Summary
by MITRE • 08/26/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Kimai versions prior to 2.64.0 represents a critical failure in access control logic within the application's routing architecture. Specifically, this flaw resides in the ProjectViewController class, affecting the report_project_view_export route which is responsible for generating and delivering project overview exports. The root cause of this insecurity stems from an incorrect implementation of authorization guards. In the framework used by Kimai, security checks are often attached to specific methods or controllers. In this instance, the necessary authorization logic was applied only to the sibling __invoke method rather than being enforced at the class level. This architectural oversight means that while one entry point for viewing project data is properly secured, the export route bypasses these protections entirely because it does not inherit the parent's security context. Consequently, any user who has successfully authenticated into the system can access this endpoint without possessing the specific project_reporting permission required to view sensitive financial and operational details.
The operational impact of this missing authorization vulnerability is significant due to the volume and sensitivity of data exposed through the export function. An attacker with a standard ROLE_USER account, which typically grants basic access rights but excludes administrative or reporting privileges, can download comprehensive project overviews. The exported dataset includes highly sensitive information such as customer names, specific project identifiers, currency types used for billing, budget classifications, and aggregate financial totals across all customers associated with the organization. This constitutes a severe breach of confidentiality, allowing unauthorized personnel to map out business relationships, understand resource allocation strategies, and assess the financial scale of various client engagements. Although actual line-item financial figures are protected within the export template itself, the exposure of high-level aggregates and customer metadata provides adversaries with valuable intelligence for social engineering attacks or further reconnaissance against the target organization.
From a classification perspective, this vulnerability aligns directly with CWE-285 Improper Authorization, as the application fails to enforce proper access controls on an action that requires specific privileges. Furthermore, in terms of tactical mapping within the MITRE ATT&CK framework, this flaw facilitates unauthorized data exfiltration and can be leveraged during the Collection phase for gathering organizational intelligence or potentially aiding in Reconnaissance activities by revealing internal project structures and client lists. The lack of granular permission checks on the export route creates a blind spot that undermines the principle of least privilege enforced elsewhere in the application.
To mitigate this vulnerability, it is imperative to upgrade Kimai to version 2.64.0 or later where these authorization guards have been correctly applied at the class level or explicitly attached to all relevant routes including exports. For organizations unable to immediately patch their systems due to operational constraints, temporary mitigations should include restricting access to the application via network-level controls such as firewalls or reverse proxies that limit exposure to trusted IP ranges only. Additionally, implementing strict monitoring and alerting on export-related API endpoints can help detect anomalous download patterns indicative of exploitation attempts until a permanent code fix is deployed. Ensuring that all controller methods inherit appropriate security contexts from their parent classes during development will prevent similar authorization bypasses in future updates.