Compound weakness
Log in
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
Last updated
Such a scenario is commonly observed when: A web application authenticates a user without first invalidating the existing session, thereby continuing to use the session already associated with the user. An attacker is able to force a known session identifier on a user so that, once the user authenticates, the attacker has access to the authenticated session. The application or container uses predictable session identifiers. In the generic exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to associate, and possibly authenticate, against the server using that session identifier, giving the attacker access to the user's account through the active session.
204 recorded CVEs are caused by CWE-384 (Session Fixation). The highest-severity and most recent are shown first. 32 new CWE-384 CVEs have been recorded so far in 2026 (43 in 2025).
Showing 12 of 204 recorded CWE-384 CVEs. Track new ones as they are published and get AI-written analysis and fixes.
Monitor CWE-384 vulnerabilitiesWhat can happen when CWE-384 is exploited.
Gain Privileges or Assume Identity
Affects: Access Control
Typically introduced during these phases of the software lifecycle.
Technologies
Practical mitigations for CWE-384, grouped by where in the lifecycle they apply.
Invalidate any existing session identifiers prior to authorizing a new user session.
For platforms such as ASP that do not generate new values for sessionid cookies, utilize a secondary cookie. In this approach, set a secondary cookie on the user's browser to a random value and set a session variable to the same value. If the session variable and the cookie value ever don't match, invalidate the session, and force the user to log on again.
Use an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].
Effectiveness: Moderate — An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.
Illustrative examples from MITRE showing how the weakness appears in code.
The following example shows a snippet of code from a J2EE web application where the application authenticates users with LoginContext.login() without first calling HttpSession.invalidate().
Vulnerable example
private void auth(LoginContext lc, HttpSession session) throws LoginException {The following example shows a snippet of code from a J2EE web application where the application authenticates users with a direct post to the j_security_check , which typically does not invalidate the existing session before processing the login request.
Vulnerable example
<form method="POST" action="j_security_check">Real CVEs that MITRE cites as examples of this weakness.
CAPEC attack patterns that exploit this weakness.
Common questions about CWE-384.
Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.
204 recorded CVEs are attributed to CWE-384, including CVE-2025-63224, CVE-2024-11317, CVE-2024-38513.
CWE-384 maps to OWASP Top Ten 2004: Broken Authentication and Session Management (A3) in the OWASP security taxonomy.
Invalidate any existing session identifiers prior to authorizing a new user session.
Exploiting CWE-384 can lead to: Gain Privileges or Assume Identity.
204 recorded CVEs are caused by CWE-384; none are currently in CISA's KEV catalog of actively exploited flaws.
Weakness data is sourced from the MITRE CWE catalog (v4.20). CVE associations are aggregated and kept current by RadicalNotion.AI.
Get alerted the moment a new CWE-384 vulnerability affects your stack, with AI-written analysis, severity context, and remediation guidance.