### 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
### 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
Update kimai/kimai to 2.58.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanKimai: Login CSRF in Default Team Creation Endpoints Allows Unauthorized Team and Permission Structure Changes affects kimai/kimai (composer). Severity is medium. ### 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
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| kimai/kimaicomposer | <=2.57.0 | 2.58.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate kimai/kimai to 2.58.0 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanKimai: Login CSRF in Default Team Creation Endpoints Allows Unauthorized Team and Permission Structure Changes affects kimai/kimai (composer). Severity is medium. ### 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
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| kimai/kimaicomposer | <=2.57.0 | 2.58.0 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard