CVE-2026-80201 in Kimai
Summary
by MITRE • 08/26/2026
Kimai before 2.53.0 fails to block sensitive User methods in the Twig invoice template sandbox, allowing admins to call getApiToken() and getPlainApiToken() methods. Attackers with template creation permissions can embed these method calls in invoice templates to leak hashed API tokens in rendered invoice output.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Kimai versions prior to 2.53.0 represents a critical failure in the security controls surrounding its Twig templating engine sandboxing mechanism. Specifically, the application fails to properly restrict access to sensitive user-related methods within the context of invoice template rendering. This flaw allows administrators or users with permission to create and edit templates to bypass intended isolation boundaries. The core technical issue lies in the insufficient filtering of method calls during the execution of Twig templates used for generating invoices. While sandboxing is designed to limit what code can be executed, this implementation did not adequately blacklist or restrict access to specific high-privilege methods associated with user authentication data.
The primary impact of this vulnerability involves the unauthorized disclosure of sensitive cryptographic material. Attackers who possess template creation permissions can inject calls to the getApiToken() and getPlainApiToken() methods into their custom invoice templates. When an administrator views or processes these invoices, the Twig engine executes these method calls within a context that has access to user session data. Consequently, the rendered output of the invoice includes the hashed API token associated with the viewing admin's account. This leakage occurs because the sandbox environment did not effectively isolate the template execution from sensitive application state variables related to authentication credentials.
From an operational perspective, this vulnerability poses significant risks beyond simple information disclosure. The exposure of a user's API token can facilitate further unauthorized access if the token is used for programmatic interactions with the Kimai system or integrated third-party services that trust these tokens. Even though the leaked token may be hashed in some contexts, depending on how it is stored and transmitted, it could potentially be exploited to impersonate the victim user within systems that accept such tokens for authentication. This undermines the integrity of access controls and compromises the confidentiality of administrative accounts, which typically hold elevated privileges over time tracking data, project configurations, and billing information.
This vulnerability aligns with CWE-749: Exposure of Sensitive Information to an Unauthorized Actor, as it results in the unintended leakage of sensitive authentication credentials. Furthermore, it relates to CWE-611: Improper Restriction of XML External Entity Reference if considered through the lens of template injection mechanisms that allow execution of restricted functions, though more accurately it falls under improper access control within a sandboxed environment. In terms of MITRE ATT&CK framework mapping, this behavior corresponds to Tactic 10: Collection and Technique T1005: Data from Local System, specifically involving the exfiltration of authentication credentials stored locally or in session memory via application logic exploitation rather than direct file system access.
To mitigate this vulnerability, organizations running Kimai must immediately upgrade to version 2.53.0 or later, where these sandbox restrictions have been tightened to prevent access to sensitive user methods like getApiToken() and getPlainApiToken(). Until the upgrade is performed, administrators should strictly limit template creation permissions to only those users who absolutely require them, thereby reducing the attack surface. Additionally, implementing strict input validation on any custom templates deployed in production environments can help detect attempts to inject unauthorized method calls. Regular audits of user roles and permissions are also recommended to ensure that no unnecessary privileges are granted for template management functions.