CVE-2026-104468 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains an insufficient session expiration vulnerability that allows attackers to reuse old password reset links because tokens lack expiry timestamps. Attackers who obtain an unused reset URL from mailboxes, logs, backups, or browser history can submit a new password through checkEmailKey() and take over accounts.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The security flaw identified in YesWiki versions prior to 4.6.7 represents a critical failure in session management and token lifecycle control, specifically categorized under CWE-613: Insufficient Session Expiration. This vulnerability stems from the architectural design of the password reset mechanism, where authentication tokens generated for account recovery lack explicit expiration timestamps or validity periods. In secure systems, such tokens are typically bound to strict time windows to ensure that they cannot be reused indefinitely after their initial generation. The absence of this temporal constraint means that a token remains valid until it is explicitly consumed by a successful password change operation, creating an extended window of opportunity for malicious actors to intercept and exploit these credentials.
The operational impact of this vulnerability allows attackers who have gained access to unused reset URLs through various vectors such as email server logs, local browser history, or system backups to perform unauthorized account takeovers. The attack vector relies on the attacker obtaining a valid but unsubmitted password reset link from any persistent storage medium where it was previously generated by legitimate users. Once obtained, the attacker can submit this old token via the checkEmailKey() function to set a new password for the associated user account. This process bypasses standard multi-factor authentication or re-verification steps because the system treats the presence of a valid token as sufficient proof of identity, regardless of when that token was originally issued.
This type of vulnerability is often exploited in conjunction with other attacks such as Cross-Site Scripting (CSS) to steal tokens from browser history or through log file access if server-side logs are improperly secured. From the perspective of the MITRE ATT&CK framework, this behavior aligns with T1078: Valid Accounts and potentially T1528: Steal Application Access Token, as it involves leveraging valid but stale credentials to gain unauthorized access. The lack of token expiration effectively turns a one-time use mechanism into a persistent backdoor that remains active until manually revoked or the user changes their password through other means.
To mitigate this vulnerability, developers must implement strict time-based expiration for all authentication and recovery tokens. It is recommended that reset links be configured to expire within a short timeframe, typically between fifteen minutes and one hour, depending on organizational security policies. Additionally, implementing token binding to specific user sessions or IP addresses can further reduce the risk of reuse from different contexts. Regular audits of session management practices should include verifying that all generated tokens have defined lifecycles and are invalidated immediately upon use or expiration. Upgrading to YesWiki version 4.6.7 or later resolves this issue by enforcing proper token expiry mechanisms, thereby closing the gap that allowed for indefinite token reuse.