CVE-2026-52828

W aplikacji Kimai ciasteczko KIMAI_SESSION wydawane po weryfikacji hasła, ale przed ukończeniem TOTP, jest akceptowane przez każdą trasę /api, ponieważ konfiguracja security.yaml chroni API regułą IS_AUTHENTICATED, a ApiRequestMatcher kieruje istniejącą sesję przez główny firewall. Token Scheb TwoFactorToken spełnia tę regułę dostępu, a ApiVoter przyznaje dostęp API jego użytkownikowi, co pozwala atakującemu z prawidłowym hasłem konta korzystać z uwierzytelnionych operacji REST API bez podania drugiego czynnika. Problem naprawiono w wersji 2.59.0.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.57.0 żądania GET lub POST do /en/admin/project/{id}/rate/{rate}, /en/admin/customer/{id}/rate/{rate} oraz /en/admin/activity/{id}/rate/{rate} niezależnie rozwiązują autoryzowany identyfikator obiektu nadrzędnego i wybrany przez atakującego identyfikator stawki podrzędnej, nie potwierdzając, że ProjectRate, CustomerRate lub ActivityRate należy do tego obiektu nadrzędnego. Uwierzytelniony użytkownik mogący edytować jeden obiekt nadrzędny może połączyć go z rekordem stawki z nieautoryzowanego projektu, klienta lub czynności i utrwalić zmiany w konfiguracji rozliczeń w tabelach kimai2_projects_rates, kimai2_customers_rates lub kimai2_activities_rates.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.58.0 żądania POST /api/teams/{id}/members/{userId} i POST /api/teams/{id}/activities/{activityId} weryfikują, że lider zespołu może edytować zespół, ale nie weryfikują access_user dla wskazanego użytkownika ani dostępu view dla wskazanej czynności. Lider zespołu może dodać użytkowników lub czynności spoza swojego zakresu zarządzania do edytowalnego zespołu, omijając węższe wybory wymuszane przez TeamEditForm i UserRepository::getQueryBuilderForFormType(). Powstałe relacje mogą być zaufane przez RolePermissionManager::checkTeamAccessActivity() i inną logikę autoryzacji, widoczności, raportowania i przepływu pracy opartą na zespołach.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.58.0 TimesheetController udostępnia trasy GET /api/timesheets/{id}/stop i GET /api/timesheets/{id}/restart, które wykorzystują uwierzytelnioną sesję przeglądarki i wykonują operacje zmieniające stan przez żądania GET bez zabezpieczenia przed fałszowaniem żądań. Zdalny atakujący może spowodować, że zalogowany użytkownik wywoła jedną z tych tras z treści kontrolowanej przez atakującego, zatrzymując działający wpis czasu pracy lub wznawiając historyczny wpis w celu utworzenia i uruchomienia nowego wpisu bez zgody użytkownika. Nieautoryzowane zmiany mogą uszkodzić rekordy czasu, rozliczenia, raporty, zatwierdzenia i audyty.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.58.0 PATCH /api/timesheets/{id}/restart, PATCH /api/timesheets/{id}/duplicate oraz webowy przepływ duplikowania mogą utworzyć nowy rekord na podstawie posiadanego historycznego wpisu czasu pracy po odebraniu użytkownikowi dostępu do jego projektu lub czynności. TimesheetVoter ocenia uprawnienie own-timesheet przed bieżącym dostępem zespołowym, a jego logika canStart() waliduje widoczność obiektu, ale nie weryfikuje bieżącego dostępu zespołowego użytkownika do wskazanego projektu i czynności. Stary wpis działa więc jako trwała zdolność do tworzenia nowych rekordów czasu w nieautoryzowanym projekcie i czynności, uszkadzając budżety, statystyki, raporty i faktury po administracyjnym odebraniu uprawnień.

Przed wersją 2.57.0 aplikacji Kimai, żądania GET lub POST do /en/admin/activity/create/{project} i /en/admin/project/create/{customer} wymagały tylko ogólnych uprawnień create_activity lub create_project, bez weryfikacji dostępu do edycji obiektu Project lub Customer. Użytkownik znający identyfikator projektu lub klienta mógł utworzyć nowy obiekt biznesowy pod nieautoryzowanym rodzicem, zanieczyszczając konfigurację projektu lub klienta i wpływając na późniejsze wpisy czasu, stawki, raporty i rozliczenia.

Przed wersją 2.57.0 aplikacji Kimai, endpointy PATCH /api/timesheets/{id} i POST /api/timesheets akceptowały identyfikator projektu kontrolowany przez użytkownika, który omijał kryteria dostępu do zespołu. Każdy uwierzytelniony użytkownik z uprawnieniem edit_own_timesheet mógł przypisać własny wpis czasu do projektu spoza swoich zespołów, utrwalić nieautoryzowane przypisanie projektu i pobrać metadane projektu i klienta przez GET /api/timesheets/{id}?full=true.

Przed wersją 2.57.0 aplikacji Kimai, endpoint GET /api/timesheets akceptował identyfikatory użytkowników od osoby z uprawnieniem view_other_timesheet, ale nie sprawdzał, czy osoba z rolą ROLE_TEAMLEAD prowadzi zespół zawierający każdego docelowego użytkownika. Umożliwiało to liderowi zespołu pobranie opisów, danych czasowych, tagów, stawek i wewnętrznych stawek innego użytkownika, nawet jeśli GET /api/timesheets/{id} odmówiłby dostępu.

Kimai przed wersją 2.65.0 zawiera podatność obejścia autoryzacji w punkcie końcowym REST API do pobierania timesheetów, która nie egzekwuje kontroli dostępu do zespołów aktywności. Użytkownicy z uprawnieniem view_other_timesheet mogą wyświetlać timesheety używające aktywności ograniczonych do zespołów, do których nie należą, omijając zamierzoną izolację danych.

Kimai do wersji 2.65.0 zawiera podatność logiki biznesowej / nieprawidłowej autoryzacji w domyślnych punktach końcowych tworzenia zespołów. Uwierzytelniony użytkownik z uprawnieniami do zarządzania uprawnieniami projektu może utworzyć lub użyć klienta, projektu lub aktywności, których nazwa pasuje do istniejącego zespołu; ponieważ punkty końcowe POST /api/customers/{id}/team, POST /api/projects/{id}/team i POST /api/activities/{id}/team ponownie używają istniejącego zespołu o tej samej nazwie i dodają bieżącego użytkownika jako lidera zespołu bez weryfikacji, czy użytkownik jest uprawniony do zarządzania tym zespołem, atakujący uzyskuje nieautoryzowane prawa lidera (administracji) nad istniejącym zespołem. Poprawiono w wersji 2.65.0.