CVE-2026-52827

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 przed wersją 2.63.0 zawiera podatność nieprawidłowej autoryzacji w punktach końcowych dostępu do zespołów, która pozwala uwierzytelnionym użytkownikom z uprawnieniami do edycji zespołów i dostępem tylko do odczytu na przyznanie dostępu zespołom do klientów, projektów lub aktywności. Atakujący mogą wykorzystać niewystarczające sprawdzanie uprawnień, wysyłając żądania POST do punktów końcowych dostępu do zespołów, aby modyfikować listy kontroli dostępu dla encji, których nie powinni móc modyfikować.

Kimai w wersjach od 2.61.0 do przed 2.63.0 nie wyłącza preferencji umowy o pracę dostępnych tylko dla administratorów dla użytkowników z niskimi uprawnieniami w punkcie końcowym PATCH /api/users/{id}/preferences. Chociaż interfejs webowy blokuje te pola umowy o pracę za uprawnieniem admina contract_other_profile, subskrybent WorkContractPreferenceSubscriber (wprowadzony w 2.61.0) rejestruje preferencje jako włączone bez sprawdzania uprawnień, więc uwierzytelniony zwykły użytkownik może użyć API do modyfikacji własnych danych umowy o pracę dostępnych tylko dla administratorów. Problem naprawiono w wersji 2.63.0 poprzez zastosowanie tego samego sprawdzenia uprawnień do punktu końcowego API.

W Kimai przed wersją 2.58.0 oficjalny obraz Docker ustawia APP_SECRET na publiczną wartość change_this_to_something_unique w Dockerfile, a .docker/entrypoint.sh nie zastępuje ani nie odrzuca tej wartości, zanim Symfony użyje jej jako kernel.secret. Nieuwierzytelniony atakujący, który dotrze do wdrożenia bez nadpisania APP_SECRET, zna nazwę użytkownika, poprawnie odgadnie identyfikator konta powiązany z tą nazwą i wybierze konto bez aktywnego uwierzytelniania dwuskładnikowego, może sfałszować artefakty uwierzytelniania chronione HMAC, w tym ciasteczka KIMAI_REMEMBER i linki logowania, aby uzyskać dostęp do konta bez hasła. Zaktualizowany entrypoint generuje i utrwala losowy sekret, gdy nie istnieje bezpieczna wartość dostarczona przez operatora.

Kimai to aplikacja open source do śledzenia czasu pracy. W wersjach przed 2.58.0 metody ExportController::createExportTemplate() i ExportController::editExportTemplate() dziedziczą jedynie uprawnienie create_export na poziomie klasy, które ROLE_TEAMLEAD otrzymuje domyślnie, i pomijają uprawnienie create_export_template wymagane przez trasy API i interfejs użytkownika. Lider zespołu może bezpośrednio uzyskać dostęp do webowych tras tworzenia i edycji szablonów eksportu, aby tworzyć lub modyfikować globalne rekordy ExportTemplate oznaczone jako dostępne dla wszystkich użytkowników, zmieniając kolumny eksportu, renderer, format i dane wyjściowe używane przez innych użytkowników i administratorów.

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.