Skip to content

GHSA-m492-gv72-xvxj CVE-2026-80196

Kimai Password Reset Link Remains Valid After Password Change

High Packagist
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.48%
Chance of exploitation in the next 30 days. Higher than 41.17% of scored vulnerabilities.
Known exploited
No
Not in CISA's catalog
Weakness
CWE-640 Weak Password Recovery Mechanism for Forgotten Password
Fix
2.58.0
Upgrade kimai/kimai to this version or later

Description

Summary

The LoginLink signature used for password reset URLs covers only the user's id — it does not include the password hash. After a user clicks a reset link and successfully changes their password, the same link remains valid for up to 2 additional uses within a 1-hour window. Anyone who intercepts or caches the original link can log in as the user even after the password has been changed.

Details

config/packages/security.yaml:73-78 configures the login link:

login_link:
    check_route: link_login_check
    signature_properties: ['id']
    lifetime: 900
    max_uses: 3

The HMAC signature covers only id, not password, username, or email. The effective lifetime for password reset links is extended to 3600 seconds by PasswordResetController.php:106-119 via getPasswordResetRetryLifetime().

After the first successful use (where the user sets a new password), the __pw_reset__ session flag is cleared by WizardController.php:105. Subsequent uses of the same link bypass the forced-password-reset wizard and grant a normal authenticated session.

Symfony's LoginLinkHandler::consumeLoginLink decrements a per-link counter but allows up to 3 total uses. Re-issuing a new link does not invalidate the old one.

The same vulnerability affects UserLoginLinkCommand.php:77, which generates admin-on-demand login links with the same signature scheme.

PoC

Step 1 — Generate a password reset link:

docker exec <kimai_container> bin/console kimai:user:login-link <username>

Step 2 — Use the link to log in and change the password.

Step 3 — Open the same link in a different browser or incognito session.

The link logs the attacker in as a fully authenticated user, despite the password having been changed in Step 2.

Step 4 — The link works a third time (3 total uses within 1 hour).

Impact

A password reset link that leaks through any of the following channels remains a valid authentication credential even after the legitimate user has changed their password: corporate mail-relay scanners that pre-click links (Microsoft Defender ATP, Mimecast, Barracuda), shared inboxes, browser history sync across devices, HTTP referrer headers, or proxy/WAF logs. The user believes they have secured their account by setting a new password, but the leaked link still grants full access for up to 2 additional uses within the hour.

Solution

Login links now also use the password hash for generating the signature, which will immediately expire the link after the user changed the password.

Read https://www.kimai.org/en/security/ghsa-m492-gv72-xvxj for more information.

Affected versions

Packagist

PackageVulnerableFixed in
kimai/kimai
< 2.58.0
2.58.0

How to fix

Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.

kimai/kimai Packagist → 2.58.0

composer
composer require kimai/kimai:^2.58.0

Severity breakdown

CVSS 4.0 0.0

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:U

Attack vector
Network
Attack complexity
Low
Attack requirements
None
Privileges required
None
User interaction
Active
Confidentiality (vulnerable system)
None
Integrity (vulnerable system)
Low
Availability (vulnerable system)
None
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
None
Availability (subsequent systems)
None
Exploit maturity
Unreported

CVSS 3.1 7.5

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Weakness

CWE-640: Weak Password Recovery Mechanism for Forgotten Password

The product contains a mechanism for users to recover or change their passwords without knowing the original password, but the mechanism is weak.

How to prevent it
  • Architecture and Design: Make sure that all input supplied by the user to the password recovery mechanism is thoroughly filtered and validated.
  • Architecture and Design: Do not use standard weak security questions and use several security questions.
  • Architecture and Design: Make sure that there is throttling on the number of incorrect answers to a security question. Disable the password recovery functionality after a certain (small) number of incorrect guesses.
  • Architecture and Design: Require that the user properly answers the security question prior to resetting their password and sending the new password to the e-mail address of record.
  • Architecture and Design: Never allow the user to control what e-mail address the new password will be sent to in the password recovery mechanism.
  • Architecture and Design: Assign a new temporary password rather than revealing the original password.

References

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy it's related
GHSA-rw46-qg69-vg6h
Kimai: ExportTemplate CRUD Missing Authorization Check Allows Unauthorized TEAMLEAD Access
Medium Also affects kimai/kimai
GHSA-v8hx-4vx8-wc96
Kimai: Pre-2FA KIMAI_SESSION cookie grants full authenticated REST API access, bypassing TOTP
High Also affects kimai/kimai
GHSA-2xgg-2x8h-8xw4
Kimai: Improper Authorization in Project, Customer, and Activity Rate Edit Endpoints Allows Cross-Scope Rate Manipulation
Medium Also affects kimai/kimai
GHSA-xv4r-4885-gwpg
Kimai has Improper Authorization in Team Member and Team Activity Assignment APIs Which Allows Expansion of Team Scope Beyond Authorized Visibility
Medium Also affects kimai/kimai
GHSA-jr9p-4h4j-6c58
Kimai: Default APP_SECRET in Docker Image Enables Cookie Forgery and Account Takeover
Critical Also affects kimai/kimai
GHSA-r8vr-m544-qh4h
Kimai: Login CSRF in the Timesheet Stop and Restart API Endpoints Allows Unauthorized State Changes
Medium Also affects kimai/kimai
GHSA-c6w6-57jj-62vh
Improper Authorization in Kimai Timesheet Restart and Duplicate Allows New Timesheets After Project Access Revocation
Medium Also affects kimai/kimai
GHSA-3q6q-26vg-v97x
Kimai: Improper Authorization Through Activity Creation with Preset Project Allows Creation Under Unauthorized Projects
Medium Also affects kimai/kimai
Is this in your code?

MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.

Check your repos with MergeHarbor