CVE-2026-85238 in MISP
Summary
by MITRE • 09/03/2026
MISP contains a session fixation vulnerability in the CustomAuth authentication (a custom configuration) flow. When a user was successfully authenticated through CustomAuth, MISP stored the authenticated user identity in the existing session without first rotating the session identifier.
As a result, if an attacker can cause a victim to use a session identifier known to the attacker before authentication, that same session identifier remains valid after the victim successfully authenticates. The attacker could subsequently reuse the fixed session identifier to access the victim's authenticated MISP session, potentially gaining the privileges associated with the victim's account.
The issue occurs because __customAuthentication() wrote the authenticated user into the existing CakePHP session while the call to Session->renew() had previously been disabled. The patch restores session identifier rotation when a new authentication occurs or when the authenticated user changes, while avoiding unnecessary session renewal on every request.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/03/2026
The vulnerability identified in MISP represents a critical session fixation flaw within its CustomAuth authentication flow, which is often utilized for integrating external identity providers or custom authentication mechanisms. Session fixation attacks exploit weaknesses in how web applications manage session identifiers during the transition from an unauthenticated to an authenticated state. In this specific instance, when a user successfully authenticates through the CustomAuth module, MISP updates the session data with the new user's identity but fails to generate a fresh session identifier. This omission leaves the original session token unchanged, effectively allowing any party that previously obtained or predicted that session ID to hijack the authenticated session once the victim logs in.
The technical root cause lies in the interaction between the custom authentication logic and the underlying CakePHP framework's session management components. Specifically, the __customAuthentication function writes the authenticated user details into the existing session object without triggering a session regeneration process. This behavior was likely introduced to optimize performance by disabling Session->renew() calls during certain operations, but it inadvertently removed the standard security control that rotates session identifiers upon authentication success. By retaining the same session ID before and after login, the application fails to invalidate any potentially compromised or attacker-controlled tokens associated with that identifier.
From an operational perspective, this vulnerability poses a severe risk of unauthorized access and privilege escalation. An attacker can initiate a fixation attack by directing a victim's browser to use a known session cookie prior to authentication. Once the victim authenticates via CustomAuth, the application binds their privileged account credentials to the attacker-controlled session ID. The attacker can then replay this session identifier in subsequent requests to impersonate the victim, gaining full access to MISP features and data associated with that user's role. This is particularly dangerous in a threat intelligence sharing platform like MISP, where compromised accounts could lead to the exposure of sensitive indicators of compromise or internal network configurations.
This flaw aligns closely with CWE-384, which describes Session Fixation as a vulnerability where an attacker sets or influences a session identifier that will be used by the victim's browser after authentication. Furthermore, in terms of offensive security frameworks such as MITRE ATT&CK, this behavior facilitates Account Manipulation and Credential Access techniques, specifically those involving session hijacking through fixation rather than credential theft. The lack of session rotation is a fundamental deviation from secure coding practices recommended for handling sensitive state transitions in web applications.
To mitigate this vulnerability, it is essential to ensure that the application regenerates the session identifier immediately after successful authentication events. The patch addressing this issue restores the call to Session->renew() specifically when a new authentication occurs or when the authenticated user changes identity. This ensures that even if an attacker has pre-set a session ID, the act of logging in will invalidate it and create a new, unpredictable token for the active session. Administrators should verify that their CustomAuth configuration does not disable necessary security headers or session management functions during the authentication handshake. Additionally, implementing secure cookie attributes such as HttpOnly and Secure can provide defense-in-depth by limiting client-side script access to cookies and ensuring transmission only over encrypted channels, though these measures do not replace the need for proper session rotation upon login.