Description

Kimai versions before 2.56.0 fail to restrict the config() Twig function in sandboxed invoice and export templates, allowing administrators to access arbitrary configuration keys. Attackers with admin privileges can upload malicious templates to exfiltrate server-wide secrets including LDAP bind passwords and SAML private keys into invoice or export documents accessible to lower-privileged users.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-26T05:18:27.380Z",
  "pubdate": "2026-08-26T05:18:27.380Z",
  "executiveSummary": "Kimai versions prior to 2.56.0 contain a vulnerability in the Twig template sandboxing mechanism, specifically involving the config() function.\nThis vulnerability allows authenticated administrators to bypass intended template security restrictions, enabling them to query and extract sensitive system-wide configuration data.\nThe attack vector involves uploading malicious invoice or export templates that utilize the unrestricted config() function to access restricted application settings.\nSuccessful exploitation results in the exfiltration of high-value secrets, such as LDAP bind passwords and SAML private keys.\nThese extracted credentials are subsequently embedded into generated invoice or export documents, which may then be accessed by lower-privileged users, leading to unauthorized information disclosure and potential lateral movement or privilege escalation within the broader organizational infrastructure.\nThe risk is categorized as high, as it exploits an inherent trust in template-based administrative actions to compromise internal security parameters.",
  "technicalDetails": "The vulnerability originates from an incomplete security boundary in the Twig template rendering engine within Kimai versions before 2.56.0. While the system implements sandboxing for invoice and export templates to isolate rendering operations, the config() function remained accessible and lacked the necessary filtering or sanitization required to restrict access to sensitive system configuration keys.\nThe root cause is a failure in the function-level access control policy within the Twig sandboxing logic. By default, template engines in security-sensitive environments should enforce strict allow-lists for accessible functions and object properties. In this instance, the config() function allowed the retrieval of arbitrary values from the application configuration object, effectively treating the template engine as a trusted entity capable of accessing internal configuration state that should be restricted to backend processes.\nThe attack flow follows a structured path: First, an attacker must possess administrative privileges, which are required to upload or modify invoice and export templates. Once an administrative session is established, the attacker crafts a malicious Twig template designed to invoke the config() function with specific keys corresponding to sensitive secrets (e.g., 'ldap_bind_password' or 'saml_private_key').\nUpon saving the malicious template, the attacker triggers an invoice or export generation task. During the rendering phase, the Twig engine executes the unauthorized config() calls, injecting the resulting plaintext secrets directly into the output document buffer. Because the resulting document is designed to be accessible to other users or system exports, the exfiltrated sensitive data is effectively exfiltrated from the secure configuration store to a document that can be retrieved by non-administrative users. This bypasses the traditional separation of concerns where configuration secrets are typically handled by the application server and are not accessible via templating languages used for end-user documents. The impact is significant as it provides a direct mechanism for credential harvesting without requiring direct access to the underlying server file system or environment variables."
}