Skip to main content

Kimai CVE-2026-49992

MEDIUM
Cross-Site Request Forgery (CSRF) (CWE-352)
2026-07-13 https://github.com/kimai/kimai GHSA-pgcc-vfmc-7cw5
Share

Severity by source

vuln.today AI
4.3 MEDIUM

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.

3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N

Estimated by vuln.today — no official severity rating has been published for this CVE yet.

Lifecycle Timeline

2
Source Code Evidence Fetched
Jul 14, 2026 - 00:16 vuln.today
Analysis Generated
Jul 14, 2026 - 00:16 vuln.today

DescriptionCVE.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_team
  • GET /en/admin/customer/{id}/create_team
  • GET /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, or Activity to 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 POST endpoints

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.

Share

CVE-2026-49992 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy