What Is Session Fixation? How Attackers Hijack User Sessions

What Is Session Fixation?

Session fixation is a web application vulnerability that lets an attacker hijack a valid user session by exploiting a failure in session identifier management. The core flaw is straightforward: when a user authenticates, the application does not assign a new session ID. This means an attacker who knows or controls the pre-authentication session identifier can use it to access the authenticated session as if they were the legitimate user.

MITRE CWE defines the weakness formally: "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." For you, the result is near-complete account takeover, often without the victim knowing anything happened.

Session fixation is distinct from session hijacking, though you may see the two confused. OWASP draws the line clearly: session fixation begins before the victim logs in, while session hijacking occurs after an active authenticated session already exists. In a fixation attack, the attacker already knows the session ID because they set it. In a hijacking attack, the attacker must capture or predict the session ID from an active session.

This distinction matters for your security controls. If your application regenerates session IDs after login, you stop fixation attacks. If it only encrypts session tokens in transit, you address hijacking but leave fixation wide open. When you understand how the attack works mechanically, you can see why this difference is so critical.

How Does Session Fixation Work?

Session fixation follows a four-step attack flow, documented by both MITRE CWE and OWASP WSTG.

• Step 1: Session Acquisition. The attacker visits the target application and receives a valid pre-authentication session ID. For example, the server might return JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1. In applications that use a permissive session acceptance mechanism, the attacker can supply an arbitrary session ID value that the application will accept without question.
• Step 2: Session Delivery. The attacker delivers the known session ID to the victim. This delivery can happen through a crafted URL, a cross-site scripting payload, an injected META tag, or HTTP response splitting. The goal is simple: make the victim's browser send the attacker-controlled session ID when accessing the target application.
• Step 3: Victim Authentication. The victim clicks the crafted link or visits the application through the attacker's delivery mechanism and logs in normally. The application validates the credentials and grants access. But it fails to regenerate the session ID upon successful login, continuing to operate with the same identifier the attacker already knows.
• Step 4: Account Takeover. The attacker sends requests to the application using the known session ID. The server treats these requests as coming from the authenticated victim. MITRE notes this provides "nearly unrestricted access to the victim's account for the lifetime of the session."

Beyond the four core steps, session fixation can be delivered through several distinct methods depending on the attacker's access and the target application's configuration.

Five Primary Attack Vectors

1. URL parameter injection is the simplest vector. The attacker embeds the session ID as a URL query parameter and delivers the link via phishing or email: https://vulnerable-app.com/login?sessionid=ATTACKER_KNOWN_ID. Burp Scanner classifies "Session token in URL" as CWE-384.
2. Cookie injection via XSS uses JavaScript that executes in the victim's browser to set the session cookie: document.cookie = "sessionid=ATTACKER_KNOWN_ID";. MITRE confirms that cross-site scripting is one of the two most common technique classes for delivering session fixation payloads.
3. META tag injection plants an HTML tag that instructs the browser to set a cookie: <meta http-equiv="Set-Cookie" content="sessionid=ATTACKER_KNOWN_ID">. OWASP notes this approach is harder to counter than JavaScript injection because "it's impossible to disable the processing of these tags in browsers."
4. HTTP response header injection exploits response splitting vulnerabilities to inject a Set-Cookie header directly into a server response, planting the controlled session ID without any client-side scripting.
5. Cross-subdomain cookie fixation exploits shared domain architectures. MITRE documents this directly: if bank.example.com and recipes.example.com share the same top-level domain, a vulnerability in the recipes application can fix a session ID that will be used across all applications on example.com. The breadth of delivery vectors explains why you still see session fixation in production systems.

Causes of Session Fixation

The root causes of session fixation are well-documented, and each one represents a gap that you and your development team can close.

Failure to Regenerate Session IDs after Authentication

This is the primary cause, cited by every authoritative source in the article. The OWASP guide states it directly: "When an application does not renew its session cookie(s) after a successful user authentication, it could be possible to find a session fixation vulnerability."

The OWASP sheet specifies that session ID regeneration is mandatory upon login, password changes, permission-level changes, and role transitions. The CVE-2022-24895 record documents that Symfony's NONE session migration strategy preserves the same session after authentication, enabling fixation attacks, and carries a HIGH severity rating.

Permissive Session ID Acceptance

The OWASP Session Management Cheat Sheet defines two mechanisms for handling session IDs. A permissive mechanism accepts any session ID value set by the user as valid and creates a new session for it. A strict mechanism only accepts session IDs previously generated by the application. If your application uses the permissive mechanism, you let attackers plant arbitrary values without first obtaining a server-issued ID.

Predictable Session Identifiers

MITRE identifies predictable session identifiers as a contributing condition, related to CWE-340 (Generation of Predictable Numbers or Identifiers). When session IDs follow patterns or use weak randomness, attackers can predict valid values without needing to acquire one from the server.

Permissive Cookie Domain Scope

Setting the Domain cookie attribute to a top-level domain, for example Domain=example.com rather than Domain=app.example.com, causes cookies to transmit across all subdomains. A vulnerability in any one subdomain becomes a fixation entry point for every application on that domain.

HTTP-to-HTTPS Transition Without Session Regeneration

OWASP WSTG-SESS-03 identifies this specific scenario: sites that issue a session identifier over HTTP and then redirect to an HTTPS login form, without reissuing the session ID upon authentication, expose the pre-authentication ID to network-level eavesdropping. The attacker captures the ID over the insecure connection and waits for the victim to authenticate. These causes rarely appear in isolation, and understanding how the standards community formally classifies them helps you communicate and prioritise remediation.

OWASP Classification of Session Fixation

Session fixation is formally classified across three authoritative standards systems: the MITRE Common Weakness Enumeration, the OWASP Top 10, and the OWASP Web Security Testing Guide. Under OWASP A07, it sits within the authentication failures category alongside related weaknesses that share the same remediation scope. Each classification serves a different audience and signals a different action.

CWE-384: Formal Weakness Identifier

MITRE CWE-384 is the primary classification for session fixation, defining the weakness as authenticating a user without invalidating the existing session identifier. Its profile in the MITRE taxonomy:

• Weakness type: Base weakness within the Session Credentials category
• Common consequences: Gain privileges or assume the victim's identity; full account takeover for the session lifetime
• Likelihood of exploit: Medium — requires delivering a known session ID to the victim before login
• Platform scope: Language-independent; applies regardless of web stack or framework
• CWE Top 25 status: Entered the Top 25 in 2019; remains an active tracked weakness in the 2023 edition

These properties make CWE-384 a consistent signal across vulnerability scanners and assessment frameworks, where it maps directly to test cases targeting session lifecycle handling.

OWASP Top 10 and Testing Standards

CWE-384 maps to A07:2025 — Authentication Failures in the OWASP Top 10. This classification carries an important implication: session fixation is treated as an authentication control failure, not a cookie misconfiguration. That distinction places it squarely inside login-flow reviews and authentication hardening work, not just cookie configuration audits.

Together, these four references give you the vocabulary, test cases, and remediation guidance to address session fixation within any existing security program. With the classification context established, it is worth examining what actually happens when the vulnerability is exploited successfully.

Impact and Risk of Session Fixation

Session fixation enables full account takeover for the lifetime of the compromised session. Once an attacker holds an authenticated session ID, they operate with every privilege the victim possesses: reading sensitive data, initiating transactions, modifying account settings, and escalating access if the victim holds administrative rights.

OWASP Classification and Severity

CWE-384 falls under OWASP A07. The A07:2025 category carries an average weighted exploitability score of 7.69, mapped to 7,147 total CVEs across tested applications. The total CVEs mapped to the A07 category also increased between the 2021 and 2025 editions, reflecting expansion rather than contraction of the attack surface.

CVSS Score Range

Confirmed session fixation CVEs span Medium to Critical. The highest-rated cases typically involve scenarios where fixation enables unauthenticated account takeover in widely deployed authentication plugins or frameworks. One important nuance for you as a practitioner: session fixation CVEs frequently show score discrepancies between NIST NVD and vendor CNAs. For example, CVE-2019-17563 (Apache Tomcat) received a CRITICAL rating from NIST but an assessment of "Low" from Apache, which described the exploitation window as "too narrow for an exploit to be practical."

Compounding Risk Factors

Session fixation is rarely a standalone risk. CVE-2024-56529 (Mailcow) shows the attack succeeds specifically when HSTS is disabled on a victim's browser. A Microsoft Research paper presented at IEEE S&P 2015 documented that cookie injection could bypass standard session regeneration defenses on real-world websites. When defense-in-depth controls fail simultaneously, a session fixation vulnerability can escalate rapidly. The question of who is vulnerable extends beyond just web applications.

How Attackers Exploit Session Fixation

Attackers exploit session fixation through scenarios that range from targeted phishing to opportunistic session poisoning.

Phishing-based URL Injection

The attacker crafts a URL containing a known session ID and delivers it via phishing or social engineering. The URL looks legitimate because it points to the real application domain. The victim clicks the link, logs in normally, and unknowingly authenticates a session the attacker controls. This is the most common scenario for URL-based session ID transmission.

Public Terminal Exploitation

MITRE CWE-384 documents a canonical scenario: an attacker creates a session from a public terminal, records the session identifier, resets the browser to the login page, and waits for the next user to authenticate. The application continues using the pre-existing session ID, giving the attacker "nearly unrestricted access to the victim's account for the lifetime of the session."

Non-Targeted Session Poisoning

CVE-2022-30769 (ZoneMinder) demonstrated an attack where an attacker could "poison a session cookie to the next logged-in user." This required no targeting of a specific individual. The poisoned session was inherited by whoever authenticated next. In shared-access environments like surveillance platforms, this pattern is particularly dangerous.

Race Condition Exploitation

CVE-2013-2067 (Apache Tomcat) revealed a FORM authentication race condition. By repeatedly sending requests for authenticated resources while a victim was completing the login form, an attacker could inject a request executed using the victim's credentials. Apache rated this as "Important" severity.

Cross-Subdomain Attacks

In multi-application architectures sharing a top-level domain, attackers exploit a low-security application to fix a session cookie scoped to the parent domain. Every other application on that domain then accepts the fixed session ID. This scenario is common in enterprise environments running multiple internal tools on a shared domain. Knowing who is affected helps you prioritize where to look for these vulnerabilities.

Who Is Affected by Session Fixation?

Session fixation affects any application that manages user sessions through identifiers and fails to regenerate them upon authentication. The CVE record and MITRE documentation point to several structurally high-risk categories.

• Web applications using URL-based session identifiers face the most direct exposure. URL-based session transmission lets attackers supply a controlled session ID through a crafted link with no additional vulnerability required.
• CMS and authentication plugin ecosystems are repeatedly affected. CVE-2024-13279 (Drupal TFA, per CISA), CVE-2010-1434 (Joomla!), CVE-2012-5391 (MediaWiki), and CVE-2019-8116 (Magento) all show that authentication modules layered onto CMS platforms introduce critical session fixation risk when session regeneration is not enforced.
• J2EE/Java EE applications have one of the most extensive documented CVE series. Apache Tomcat alone accounts for CVEs spanning from 2013 through 2025, including CVE-2013-2067, CVE-2014-0033, CVE-2015-5346, CVE-2019-17563, and CVE-2025-55668.
• Multi-application shared-domain architectures are vulnerable by design. SaaS platforms with tenant subdomains and enterprise application portfolios sharing a top-level domain face cross-subdomain fixation risk, as MITRE documents directly.
• ICS/SCADA platforms represent an emerging risk surface. CVE-2025-70973 (ScadaBR 1.12.4, disclosed March 2026) shows session fixation in industrial control system platforms, consistent with CWE-384's ICS category mappings to CWE-1364 (ICS Communications: Zone Boundary Failures) and CWE-1366 (ICS Communications: Frail Security in Protocols).
• Enterprise workflow platforms also carry documented exposure. CVE-2022-38369 (Apache IoTDB) and CVE-2022-38054 (Apache Airflow) show that workflow automation tools are not immune. The breadth of affected categories makes real-world case studies a useful lens for understanding how these vulnerabilities appear in practice.

Real-World Examples of Session Fixation

Session fixation has been confirmed across a wide range of production systems, from enterprise Java frameworks to industrial control platforms. The examples below illustrate how the same underlying flaw plays out differently depending on the environment.

Apache Tomcat FORM authentication race condition (CVE-2013-2067)

This remains the most impactful Tomcat session fixation CVE, rated "Important" by Apache. Affecting Tomcat 6.0.21 through 6.0.36 and 7.0.0 through 7.0.32, the vulnerability exploited a race condition in FORM authentication. An attacker could repeatedly send requests for authenticated resources while a victim completed the login form, injecting a request that executed using the victim's credentials. The irony is that the option to change session ID on authentication was itself added in Tomcat 6.0.21. This CVE represented a bug in Tomcat's own fixation protection.

Symfony framework CSRF token bypass (CVE-2022-24895)

Symfony versions 2.0.0 through 6.2.5 were affected by a HIGH severity vulnerability. The framework regenerated the session ID upon login but preserved the rest of the session attributes, including CSRF tokens. This partial regeneration enabled same-site attackers to bypass CSRF protection through a session fixation variant. The lesson is clear: regenerating only the session ID is not enough. Full session invalidation and reissuance is required.

ScadaBR industrial control system (CVE-2025-70973)

Disclosed in March 2026, this vulnerability in ScadaBR 1.12.4 follows the canonical session fixation pattern. The application assigns a JSESSIONID session cookie to unauthenticated users and does not regenerate the session identifier after successful authentication. A session created before login becomes authenticated once the victim logs in. This CVE is notable because it shows active session fixation risk in ICS/SCADA environments.

ZoneMinder non-targeted session poisoning (CVE-2022-30769)

ZoneMinder 1.36.12 and earlier versions allowed an attacker to poison a session cookie that would be inherited by the next user to authenticate. This required no targeting of a specific victim, making it particularly dangerous in shared-access surveillance environments where multiple operators share access to the same platform.

PHP session adoption (CVE-2011-4718)

PHP's session module was "adoptive," meaning it accepted session IDs from external sources. The PHP RFC stated that "use of session_regenerate_id() CANNOT prevent session adoption/fixation" without also enabling session.use_strict_mode. PHP 5.5.2 introduced session.use_strict_mode as the fix, but even with strict mode enabled, custom save handlers could remain vulnerable. The full historical record of these incidents shows how long this vulnerability class has persisted.

Session Fixation Timeline and History

Session fixation has been formally documented since 2002, and the CVE record shows it remains active across new and legacy codebases. The timeline below traces key disclosure events and framework-level responses.

The timeline spans over two decades with no sign of slowing. Session fixation is not a historical vulnerability. It continues to appear in new and legacy codebases alike, from enterprise frameworks to ICS platforms. If you know how to review your own applications, you can take the next step.

How to Detect Session Fixation

Session fixation is one of the more straightforward vulnerabilities to confirm: the core test requires nothing more than capturing a session identifier before login, authenticating, and comparing the value afterward. The following approaches cover manual verification, cookie attribute inspection, automated scanning, and WAF-layer identification.

Manual penetration testing (OWASP WSTG-SESS-03)

The authoritative test procedure comes from the OWASP WSTG. For you, the black-box test is straightforward.

1. Capture the pre-authentication session ID. Visit the application and record the session cookie value (e.g., JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1).
2. Authenticate while presenting the captured session ID. Submit valid credentials with the original session cookie attached.
3. Compare session ID values. If the server returns the same session ID after successful authentication, the application is vulnerable.

For applications without full HSTS adoption, WSTG-SESS-03 describes a second strategy: force all cookies not freshly issued after login into the victim's browser from a separate machine, then confirm whether those cookies grant access to the victim's session post-authentication.

Cookie Attribute Verification

Check for hardening indicators in your session cookies. The __Host- prefix provides integrity against network-based session fixation. The __Secure- prefix indicates partial hardening. Run WSTG-SESS-03 to verify HttpOnly, Secure, and SameSite attributes are properly configured.

DAST Scanning

OWASP ZAP provides both active and passive scanning modes with session management support, including handling cookies, tokens, and other mechanisms. ZAP's analysis of session and authentication enforcement helps you find broken authentication and session fixation bugs. Burp Suite Professional covers session management testing workflows, functioning as a dynamic web vulnerability scanner applicable to session management testing.

WAF-Based Identification

The OWASP sheet identifies ModSecurity combined with the OWASP Core Rule Set as providing countermeasures against session fixation attacks. This WAF-layer approach is recommended when source code is unavailable, cannot be modified, or when implementing full application-level fixes would require extensive redesign. Effective review should lead directly to prevention, and the controls required are well-defined.

How to Prevent Session Fixation

Prevention centers on one non-negotiable requirement: the application must issue a new session ID at every authentication event and reject any session identifier that was not generated by the server itself. The controls below address that requirement at the application layer, framework level, cookie configuration, and network architecture.

Application-Layer Controls

• Regenerate session IDs after authentication. This is the single most important control. OWASP WSTG-SESS-03 states the requirement clearly: "the application should always first invalidate the existing session ID before authenticating a user, and if authentication is successful, provide another session ID." Regeneration is mandatory at every privilege level change, including login, password changes, permission changes, and role transitions.
• Use strict session management. Configure your application to accept only server-generated session IDs. Reject arbitrary session ID values submitted by clients. PHP introduced session.use_strict_mode in version 5.5.2 specifically for this purpose.
• Invalidate sessions completely. CVE-2022-24895 (Symfony) proved that partial session regeneration is not sufficient. Regenerating the session ID while preserving other session attributes like CSRF tokens creates a residual vulnerability. Full session invalidation and reissuance is required.

Framework-Specific Implementation

Spring Security protects against session fixation automatically by creating a new session or changing the session ID when a user logs in. Four configurable strategies are available: changeSessionId() (recommended), migrateSession(), newSession(), and none() (not recommended).

Cookie Security Configuration

Follow NIST SP 800-63B requirements:

• Secure flag: SHALL be set (cookies only transmitted over HTTPS)
• Domain and Path: SHALL be restricted to minimum practical scope
• HttpOnly flag: SHOULD be set (prevents JavaScript access)
• SameSite=Lax or Strict: SHOULD be set (per NIST SP 800-63B v4 draft)
• __Host- prefix with Path=/: SHOULD be set (per NIST SP 800-63B v4 draft)

Applying these flags in combination prevents the most common network-based and cross-site fixation delivery scenarios and raises the bar significantly for any attacker attempting cookie injection.

Architecture-Level Controls

Do not mix applications of different security levels on the same domain. Implement full HSTS including subdomains to counter network-based fixation. Deploy ModSecurity with the OWASP Core Rule Set for WAF-layer protection when application-level changes are not immediately possible. Prevention and review work best when supported by the right tools.

Tools for Detection and Prevention

Identifying and stopping session fixation requires tools across three layers: dynamic scanners that simulate real attack conditions, framework-native protections that enforce secure defaults at the code level, and behavioral analysis that catches fixation-based intrusions that reach the authenticated session. The tools below cover all three.

DAST and Penetration Testing Tools

• OWASP ZAP is a free, open-source dynamic application security testing tool. Per official docs, ZAP uses active and passive scanning modes to find session management flaws, including session fixation.
• Burp Suite Professional provides session testing workflows and scanner rules for identifying session token handling vulnerabilities. Its manual testing capabilities let you step through the WSTG-SESS-03 procedure with full request/response visibility.
• ModSecurity with OWASP Core Rule Set provides WAF-layer countermeasures against session fixation, including identification and enforcement of security cookie attributes, sticky session tracking, and session ID renewal when privilege changes are observed.

Framework Security Features

Spring Security's built-in session fixation protection, PHP's session.use_strict_mode and session_regenerate_id(), and ASP.NET's Session.Abandon() all provide language-native prevention. You should verify these features are enabled and configured correctly in your deployments rather than relying on default settings.

Related Vulnerabilities

Session fixation does not operate in isolation. Several closely related weaknesses share delivery mechanisms, exploit conditions, or risk amplifiers with CWE-384. Understanding them as a group produces a stronger remediation scope than treating session fixation alone.

• Cross-Site Scripting (CWE-79) serves as a delivery mechanism for session fixation. Reflected XSS can inject JavaScript that sets a controlled session cookie in the victim's browser. Addressing XSS closes one of the primary fixation delivery channels.
• Cross-Site Request Forgery (CWE-352) is often confused with session fixation, but the mechanics differ. CSRF exploits the browser's automatic cookie transmission to forge requests from an authenticated session. It does not require the attacker to know or control the session ID. CWE-352 ranked #9 in the 2023 CWE Top 25.
• Improper Authentication (CWE-287) is closely related to session fixation, sitting within the same OWASP A07 authentication failure category. CWE-287 covers all forms of broken authentication and ranked #13 in the 2023 CWE Top 25 with 10 entries in the CISA Known Exploited Vulnerabilities catalog.
• Insufficient Session Expiration (CWE-613)](https://www.sentinelone.com/cybersecurity-101/cybersecurity/enterprise-application-security/) amplifies session fixation risk by extending the window during which a fixed session ID remains valid. Long session timeouts give attackers more time to exploit a fixed session.
• Generation of Predictable Numbers (CWE-340) can precede session fixation via a CanFollow relationship in MITRE's taxonomy. Predictable session identifiers lower the barrier for fixation attacks by making it possible to guess valid session ID values. Addressing session fixation in isolation rarely covers the full risk surface; reviewing these related weaknesses in the same cycle closes the gaps that fixation exploits to gain its initial foothold.

Related CVEs

AI-Powered Cybersecurity

Elevate your security posture with real-time detection, machine-speed response, and total visibility of your entire digital environment.

Get a Demo

Conclusion

Session fixation exploits a single, well-understood failure: your application does not regenerate the session ID after authentication. Formally classified as CWE-384 and mapped to OWASP Top 10 2025 A07, it continues to appear across CMS platforms, Java frameworks, PHP applications, and ICS/SCADA systems. 

You reduce risk by rotating session IDs at every privilege change, enforcing strict session acceptance, hardening cookie scope, and reviewing post-authentication activity for misuse.