External risk intelligence

Kimai Timesheet Authorization Bypass Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-80202

Kimai is an open-source time-tracking web application commonly deployed as an internet-facing service for remote employees and teams. Because it functions as a web-based portal intended for broad user access, it is typically exposed to the network, making the API and application endpoints reachable in standard real-world deployments.

Halo Surface Signal: 4 out of 5 — likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A security vulnerability in Kimai, an open-source time-tracking application, allows any authenticated user with specific roles to access, modify, or delete timesheets belonging to any user system-wide through its API, bypassing intended team membership restrictions. This could potentially lead to unauthorized data manipulation and loss within the application.

Unauthorized access to all user timesheets.
Critical roles can manipulate or delete any timesheet.
Confirm relevance and exposure within your environment.

Attack Path

How an attacker could exploit the issue

An attacker could gain unauthorized access to manipulate timesheets by exploiting a flaw in how user permissions are checked. Starting with an account that has a team lead role, an attacker can bypass restrictions intended to limit access to only their own timesheets. This bypass allows them to interact with the system's API to view, alter, or delete timesheets belonging to any user within the application, irrespective of team affiliations.

Authenticated user with specific role.
API access to timesheet endpoints.
Unauthorized data modification or deletion.

Live Threat

Current exploitation, exposure, and threat context

Any authenticated user with specific roles could access, modify, or delete any timesheet system-wide via the API. This could occur when an authenticated user with elevated privileges, such as `ROLE_TEAMLEAD`, interacts with the API endpoints.

System-wide timesheet data at risk.
API access enables unauthorized timesheet modification.
Permanent deletion of any user's timesheets.

Operational Fix

Recommended remediation, mitigation, and detection steps

The application owner and platform team are likely responsible for addressing this vulnerability. The first practical step is to identify all instances of Kimai within your environment, confirm their exposure and business criticality, and then determine the accountable owner for each instance to plan remediation.

Application owner must address.
Verify all Kimai instances deployed.
Plan remediation based on risk.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Kimai?

Kimai is an open-source, web-based time-tracking application designed for teams to record work hours and track project progress. Organizations use it as a centralized portal for employees to log their activities, making it a critical tool for project management, payroll, and billing operations.

How does the CVE-2026-80202 vulnerability work?

This issue is an authorization bypass, categorized as CWE-863 (Incorrect Authorization). The application fails to check if a user belongs to the correct team when processing requests. As a result, authenticated users with certain elevated roles gain system-wide access, allowing them to interact with timesheet data they are not authorized to view, change, or remove.

What conditions trigger this vulnerability?

The flaw is triggered when an attacker with a specific role, such as ROLE_TEAMLEAD, uses the Kimai API to request timesheet information. Because the system does not enforce team membership, these requests succeed. Importantly, this bug does not affect standard ROLE_USER accounts, as those accounts are correctly restricted to their own data.

Is my Kimai instance at risk?

According to Halo Surface Signal, Kimai is frequently deployed as an internet-facing service to support remote work. Because the API endpoints are reachable over the network, any instance accessible from the internet faces a higher risk of exploitation. You should check if your deployment is exposed externally or if it is restricted to an internal network.

What should I do to secure my system?

Begin by identifying all Kimai installations running in your environment to understand your total footprint. Once located, verify the exposure level of each instance and coordinate with the application owners. Focus on reviewing user role assignments while planning for updates or security configurations that align with the vendor's guidance.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.