Kurzfassung

Die Schwachstelle CVE-2026-52824 betrifft Kimai in Docker-Installationen vor Version 2.58.0. Der CVSS-Basiswert liegt bei 9.1 und damit im kritischen Bereich. Unter bestimmten Bedingungen kann ein Angreifer ohne Anmeldung Authentifizierungsdaten fälschen und so auf Benutzerkonten zugreifen, wenn der Standardwert für APP_SECRET unverändert geblieben ist.

Was ist passiert?

In der offiziellen Docker-Auslieferung von Kimai war APP_SECRET vor Version 2.58.0 auf einen öffentlich bekannten Standardwert gesetzt. Wenn Betreiber diesen Wert beim Deployment nicht ersetzt haben, verwendet die Anwendung denselben vorhersehbaren Geheimwert für sicherheitsrelevante Funktionen.

Dadurch lassen sich signierte Anmeldeartefakte fälschen. Genannt werden insbesondere dauerhafte Anmelde-Cookies sowie Login-Links. Ein Passwort des Zielkontos ist dafür nicht erforderlich.

Behoben ist das Problem laut NVD ab Kimai 2.58.0. Die aktualisierte Startlogik erzeugt demnach einen zufälligen geheimen Wert und speichert ihn, falls kein sicherer, vom Betreiber gesetzter Wert vorhanden ist.

Technische Details

Der CVSS-Wert beträgt 9.1 nach CVSS 4.0. Dieser Wert beschreibt die technische Schwere der Schwachstelle, nicht automatisch eine bereits beobachtete Ausnutzung in freier Wildbahn.

Der Vektor zeigt einen Angriff über das Netzwerk, ohne vorherige Authentifizierung und ohne Nutzerinteraktion; zugleich ist der Angriff nicht trivial, weil der Angreifer zusätzliche Bedingungen erfüllen muss, etwa einen Benutzernamen kennen, die zugehörige Konto-ID richtig erraten und ein Konto ohne aktive Zwei-Faktor-Authentifizierung treffen.

Im Kern liegt das Problem in einem vorhersehbaren Geheimnis für HMAC-geschützte Authentifizierungsmechanismen. Bleibt APP_SECRET auf dem bekannten Standardwert, kann ein externer Angreifer gültig wirkende Anmeldeinformationen erzeugen. Das gefährdet vor allem Vertraulichkeit und Integrität von Konten; auf die Verfügbarkeit zielt die Schwachstelle laut CVSS nicht direkt.

Wer ist betroffen?

Betroffen sind Kimai-Installationen vor Version 2.58.0, die über das offizielle Docker-Image betrieben werden und bei denen APP_SECRET nicht auf einen individuellen, geheimen Wert geändert wurde.

Praktisch relevant ist das vor allem für selbst gehostete Umgebungen in Unternehmen, Agenturen, öffentlichen Einrichtungen und bei Dienstleistern im DACH-Raum, die Kimai schnell per Container ausgerollt haben. Nicht jede Kimai-Instanz ist automatisch verwundbar: Entscheidend ist, ob der Standardwert tatsächlich aktiv blieb.

Zusätzliche Voraussetzungen schränken den Angriff ein. Der Angreifer muss die Instanz erreichen können, einen Benutzernamen kennen und ein Zielkonto ohne aktivierte Zwei-Faktor-Authentifizierung finden. Für öffentlich erreichbare Zeiterfassungsportale ist das Risiko deutlich höher als für rein intern zugängliche Systeme.

Empfohlene Maßnahmen

Erstens: Aktualisieren Sie Kimai zügig auf Version 2.58.0 oder neuer. Wer Container verwendet, sollte nicht nur das Image austauschen, sondern auch die laufende Konfiguration prüfen.

Zweitens: Kontrollieren Sie sofort den gesetzten Wert von APP_SECRET. Falls dort jemals der bekannte Standardwert verwendet wurde, behandeln Sie die Instanz als potenziell kompromittiert. Setzen Sie einen neuen, zufälligen geheimen Wert und dokumentieren Sie die Änderung sauber im Deployment.

Drittens: Erzwingen Sie für betroffene Benutzer neue Anmeldungen. Da Remember-Me-Cookies und Login-Links betroffen sein können, sollten bestehende Sitzungen und vergleichbare Authentifizierungsartefakte ungültig gemacht werden. Prüfen Sie außerdem, ob Kimai oder die umgebende Infrastruktur Anzeichen ungewöhnlicher Kontoanmeldungen zeigt.

Viertens: Aktivieren Sie, wo möglich, Zwei-Faktor-Authentifizierung für alle privilegierten und idealerweise für alle regulären Konten. Die beschriebene Angriffskette setzt laut den bekannten Informationen voraus, dass beim Zielkonto keine aktive 2FA greift.

Fünftens: Beschränken Sie die Erreichbarkeit. Wenn Ihre Kimai-Instanz nicht öffentlich zugänglich sein muss, setzen Sie Reverse-Proxy-Regeln, VPN-Zugang oder IP-Filter davor. Das reduziert die praktische Angriffsfläche sofort.

Ein gesondertes Hersteller-Advisory mit Patch-Hinweisen wurde hier nicht übergeben.

Einschätzung von CyberSecurity-News.de

Die technische Schwere ist hoch, aber die operative Relevanz hängt stark von der Betriebsform ab. Für Organisationen, die Kimai per Docker öffentlich erreichbar betreiben und Standardwerte bei Secrets nicht konsequent vermeiden, ist das Thema akut. Für sauber gehärtete Installationen mit individuellem APP_SECRET, 2FA und eingeschränkter Erreichbarkeit sinkt das Risiko deutlich.

Positiv ist, dass die Problembeschreibung ungewöhnlich konkret ausfällt und die Fehlerursache klar benannt ist. Weniger hilfreich ist, dass viele Admins bei Container-Deployments davon ausgehen, sichere Defaults bereits mitzuliefern. Genau hier zeigt der Fall, wie riskant öffentlich bekannte Standard-Geheimnisse in produktiven Images sind.

Unklar bleibt ohne zusätzliche Herstellerinformationen, wie breit fehlerhafte Deployments tatsächlich verbreitet sind und ob bereits Missbrauch beobachtet wurde. NVD nennt einen CVSS-Wert, aber keine Hinweise auf aktive Ausnutzung.

Fazit

Wenn Sie Kimai per Docker betreiben, sollten Sie jetzt zuerst die Version und den Wert von APP_SECRET prüfen. Läuft noch eine Fassung vor 2.58.0 oder wurde der Standardwert nie ersetzt, hat das Update Priorität, gefolgt von Secret-Rotation, Sitzungsbereinigung und der Aktivierung von Zwei-Faktor-Authentifizierung.

Quellenangabe

Weiterführende technische Informationen finden Sie beim NVD-Eintrag zu CVE-2026-52824.