Kimai CVE-2026-49992
MEDIUMSeverity by source
Network-reachable GET endpoint; no attacker privileges needed; user interaction required (victim must visit malicious page); integrity impact is low as only authorization structure is modified, not data exfiltrated or destroyed.
Estimated by vuln.today — no official severity rating has been published for this CVE yet.
Lifecycle Timeline
2DescriptionCVE.org
Summary
Kimai 2.56.0 contains authenticated cross-site request forgery issues in its default team creation shortcuts for projects, customers, and activities. These endpoints are exposed through GET routes and directly create or reuse a Team, add the current user as teamlead, and bind the target object to that team.
As a result, an attacker can trick a logged-in user with the required permissions into visiting a malicious page and cause unauthorized changes to team, teamlead, and object-binding relationships. This is a real authorization-structure modification issue rather than a harmless UI shortcut.
Details
The issue affects at least the following routes:
GET /en/admin/project/{id}/create_teamGET /en/admin/customer/{id}/create_teamGET /en/admin/activity/{id}/create_team
Each of these routes is a GET endpoint, yet each performs persistent writes that alter authorization structure:
- create or reuse a
Team - add the current user as
teamlead - bind the target
Project,Customer, orActivityto that team
*A PoC was provided, but removed for security reasons.*
Impact
This vulnerability allows an attacker to remotely alter permission topology while the victim is logged in. A successful exploit can create or reuse a team, assign the victim as its teamlead, and bind a project, customer, or activity to that team without intentional user action.
The pre-requisite is, that the logged-in user already has access to manage permissions of the object in question.
Because these routes modify authorization structure rather than a simple personal preference, the business impact can extend into visibility rules, assignment scope, team-based access control, reporting, and later privilege-expansion chains. This makes the issue materially more serious than a low-value cosmetic CSRF.
Solution
- The routes have been moved to API
POSTendpoints
See https://www.kimai.org/en/security/ghsa-pgcc-vfmc-7cw5
AnalysisAI
CSRF vulnerabilities in Kimai 2.56.0 through 2.57.0 allow an unauthenticated attacker to manipulate the authorization topology of the time-tracking application by tricking a privileged logged-in user into visiting a malicious page. The three affected GET endpoints - for projects, customers, and activities - perform persistent writes: creating or reusing a Team, assigning the victim as teamlead, and binding the target object to that team. No public exploit is currently available at time of analysis, though a PoC was submitted to the vendor and subsequently removed; the fix (moving routes to POST endpoints) shipped in version 2.58.0.
Technical ContextAI
Kimai is an open-source PHP time-tracking application distributed via Composer (pkg:composer/kimai/kimai). The root cause is CWE-352: the application exposes state-changing operations - team creation, teamlead assignment, and object binding - via HTTP GET routes, which are inherently CSRF-unsafe because browsers automatically issue GET requests via image tags, iframes, or hyperlinks without CSRF token validation. The three affected routes (/en/admin/project/{id}/create_team, /en/admin/customer/{id}/create_team, /en/admin/activity/{id}/create_team) are admin-facing shortcuts that were designed for convenience but inadvertently bypass the CSRF protections applied to POST/PUT routes. Because the writes alter Kimai's internal authorization model - which governs team membership, teamlead rights, and object visibility - the impact is structural rather than cosmetic.
RemediationAI
Upgrade Kimai to version 2.58.0 or later, which resolves the vulnerability by migrating the three affected team-creation shortcuts from GET routes to POST API endpoints, making them subject to standard CSRF protection. The vendor advisory is at https://www.kimai.org/en/security/ghsa-pgcc-vfmc-7cw5. If an immediate upgrade is not feasible, a targeted compensating control is to restrict access to the three affected admin URL patterns (/en/admin/*/create_team) at the web server or reverse-proxy layer (e.g., via nginx location deny rules or Apache Require directives), accepting the trade-off that the convenience shortcuts will be unavailable to all users until the upgrade. Alternatively, enforcing strict Referer or Origin header validation at the application layer for those routes can block cross-origin GET requests, though this may cause issues for users behind privacy-stripping proxies.
Same weakness CWE-352 – Cross-Site Request Forgery (CSRF)
View allShare
External POC / Exploit Code
Leaving vuln.today
GHSA-pgcc-vfmc-7cw5