CVE-2026-104469 in YesWiki
Summary
by MITRE • 10/02/2026
YesWiki before 4.6.7 contains a session fixation vulnerability that allows attackers to hijack authenticated sessions because login does not regenerate the PHP session ID. Attackers who set or learn a victim's pre-authentication YesWiki-* session cookie can reuse it after login to access private content and perform actions with the victim's privileges.
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 versions of YesWiki prior to 4.6.7 represents a critical failure in session management protocols, specifically classified under CWE-384 as Session Fixation. This vulnerability stems from an implementation oversight where the application fails to generate a new session identifier upon successful user authentication. In secure web applications, it is standard practice to invalidate any existing session token and issue a fresh one after login to prevent attackers from leveraging pre-authentication identifiers established by malicious actors or through other means such as cross-site scripting attacks. By omitting this regeneration step, YesWiki allows the persistence of the original session ID throughout the authentication lifecycle, creating a direct pathway for unauthorized access.
The operational mechanics of this exploit rely on the attacker's ability to set or obtain a specific PHP session cookie before the victim logs in. Once an attacker has secured a valid session identifier associated with the application, they can wait for their target user to authenticate using that same browser context or by manipulating cookies if cross-site scripting vulnerabilities are also present. Upon successful login, the server accepts the pre-existing session ID as legitimate and binds it to the authenticated user's privileges. Consequently, the attacker retains control over this session identifier even after the victim has gained elevated access rights, effectively hijacking the authenticated session without needing to steal credentials or bypass authentication mechanisms directly.
The impact of this vulnerability is severe, allowing attackers to fully compromise the confidentiality and integrity of user accounts within the YesWiki environment. An adversary can impersonate legitimate users by reusing their pre-authentication session cookies post-login, thereby gaining access to private content that should be restricted to authorized personnel only. Furthermore, because the hijacked session carries the full privilege level of the victim, attackers can perform administrative actions or modify wiki pages as if they were the authenticated user. This undermines the fundamental trust model of the application and exposes sensitive organizational data to unauthorized disclosure or manipulation.
To mitigate this risk, organizations running YesWiki must immediately upgrade to version 4.6.7 or later where the session regeneration logic has been corrected. For environments unable to patch instantly due to operational constraints, a temporary workaround involves implementing custom middleware or modifying application code to explicitly destroy and regenerate PHP sessions upon successful authentication events. This ensures that any pre-existing session identifiers are invalidated before new privileges are assigned. Additionally, enforcing secure cookie attributes such as HttpOnly and Secure flags can reduce the risk of initial session token theft via cross-site scripting, although it does not fully address the fixation flaw itself. Continuous monitoring for anomalous login patterns from unexpected IP addresses or user agents may also aid in detecting active exploitation attempts aligned with ATT&CK technique T1078 regarding valid accounts misuse.