How severe is GHSA-m492-gv72-xvxj?

No CVSS score has been assigned to GHSA-m492-gv72-xvxj yet. Review the advisory details and affected package list to assess your exposure.

Which packages are affected by GHSA-m492-gv72-xvxj?

GHSA-m492-gv72-xvxj affects the following packages: kimai/kimai (Packagist). Ecosystems affected: Packagist.

How do I fix GHSA-m492-gv72-xvxj?

Update kimai/kimai to 2.58.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m492-gv72-xvxj is resolved across your whole dependency graph.

How do I detect GHSA-m492-gv72-xvxj in my Packagist dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for kimai/kimai. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

How do I mitigate GHSA-m492-gv72-xvxj if there is no patch (or I can't update yet)?

If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

How does O3 Security protect against GHSA-m492-gv72-xvxj?

O3 pinpoints whether GHSA-m492-gv72-xvxj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Is GHSA-m492-gv72-xvxj actively exploited in the wild?

No public exploit code has been indexed for GHSA-m492-gv72-xvxj yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

When was GHSA-m492-gv72-xvxj published, and has it been updated?

GHSA-m492-gv72-xvxj was published on July 1, 2026 and was last updated on July 1, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

🐘 Packagist

GHSA-m492-gv72-xvxj

Kimai Password Reset Link Remains Valid After Password Change

Published

Jul 1, 2026

Updated

Jul 1, 2026

Affected

1 pkg

Patched

1 / 1

Exploits

None indexed

Blast Radius

1 pkg affected

🐘kimai/kimai

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

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 Packages

1 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
🐘Packagist	`kimai/kimai`	all versions	2.58.0

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for kimai/kimai. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update kimai/kimai to 2.58.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m492-gv72-xvxj is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-m492-gv72-xvxj is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-m492-gv72-xvxj. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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: ```yaml login_link: check_route: link_login_check signature_properties: ['id'] lifetime: 900 max_use

O3 Security · Impact-Aware SCA

Is GHSA-m492-gv72-xvxj in your dependencies?

O3 detects GHSA-m492-gv72-xvxj across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works