What Is Session Fixation? How Attackers Hijack User Sessions

Session fixation lets attackers hijack authenticated accounts by forcing a known session ID before login. The core defense: regenerate session IDs on every login.

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.

Attribute	Session Fixation	Session Hijacking
Attack timing	Before victim authenticates	After victim has authenticated
Session ID knowledge	Attacker sets or knows the ID in advance	Attacker must capture or predict the ID
Primary countermeasure	Session ID regeneration upon login	Token encryption, secure transmission

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.

Reference	System	Purpose
CWE-384	MITRE CWE	Formal weakness tracking; used by SAST/DAST tools and CVE records
A07:2025	OWASP Top 10	Risk prioritisation signal; scopes the review to authentication controls
WSTG-SESS-03	OWASP WSTG	Authoritative black-box test procedure and pass/fail criteria
Session Management Cheat Sheet	OWASP CheatSheets	Developer-facing prevention reference for regeneration, cookie scope, and strict mode

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.

Year	Event
Dec 2002	Mitja Kolšek (ACROS Security) publishes "Session Fixation Vulnerability in Web-based Applications," formally naming session fixation as a fourth attack class against session identifiers
2006	CVE-2006-1228 (Drupal 4.5.x/4.6.x): URL-based session ID fixation
July 2006	MITRE adds CWE-384 to Common Weakness Enumeration (Draft 3)
Feb 2008	Oracle/BEA WebLogic Server advisory BEA08-196.00: session fixation enabling privilege escalation
2009	CVE-2009-1580 (SquirrelMail); Black Hat USA documents CWE-384 in BitTorrent tracker communities
2010	CVE-2010-1434 (Joomla! 1.5.0 through 1.5.15): CVSS 7.5 HIGH
Dec 2011	CVE-2011-4718 (PHP session adoption): affects PHP 5.0.0 through 5.5.1
May 2013	CVE-2013-2067 (Apache Tomcat 6.x, 7.x): FORM auth race condition, Apache "Important" severity
2015	Microsoft Research (IEEE S&P) documents cookie injection bypassing widely adopted regeneration defenses
2019	CWE-384 enters Top 25
Dec 2019	CVE-2019-17563 (Apache Tomcat): NIST 9.8 CRITICAL vs. Apache "Low"
2022	CVE-2022-24895 (Symfony): partial regeneration bypass
Jan 2025	CVE-2024-56529 (Mailcow): session fixation when HSTS disabled
Aug 2025	CVE-2025-55668 (Apache Tomcat 9.x/10.x/11.x): CVSS 6.5 MODERATE
Mar 2026	CVE-2025-70973 (ScadaBR 1.12.4) and CVE-2026-25101 (Bludit): new CVEs confirm the vulnerability class remains active

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

Framework	Invalidate Existing Session	Create New Session
J2EE	HttpSession.invalidate()	request.getSession(true)
ASP.NET	Session.Abandon()	Response.Cookies.Add(new HttpCookie(...))
PHP	session_start()	session_regenerate_id(true)

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

CVE ID	Description	Severity	Affected Product	Year
CVE-2026-23796	Session identifier not regenerated after login; attacker sets victim's session ID before authentication and hijacks the post-login session	Pending	OpenSolution: Quick.Cart	2026
CVE-2026-23624	Session fixation triggered when remote authentication uses SSO variables; attacker can steal session previously opened by another user on the same machine	Pending	GLPI (≥ 0.71 < 10.0.23; ≥ 11.0.0-alpha < 11.0.5)	2026
CVE-2025-55266	Session fixation (CWE-384) allows attacker to take over user's session and perform unauthorized transactions on behalf of the victim	MEDIUM (6.5)	HCL Technologies: Aftermarket DPC (Aftermarket Cloud 1.0.0)	2025
CVE-2025-1723	Session mishandling (CWE-287) in ManageEngine ADSelfService Plus; low-privileged authenticated user exploits improper session management to take over other user accounts	HIGH (9.3)	Zohocorp ManageEngine ADSelfService Plus (≤ build 6510)	2025
CVE-2024-38513	Session fixation (CWE-384) in GoFiber session middleware; accepts user-supplied session_id values, giving the attacker control of the authenticated session key	CRITICAL (9.8)	GoFiber: Fiber (< 2.52.5)	2024
CVE-2024-22250	Session hijacking (CWE-384) in deprecated VMware Enhanced Authentication Plug-in; local unprivileged attacker hijacks a privileged domain user's authenticated EAP session	HIGH (7.8)	VMware: Enhanced Authentication Plug-in (deprecated)	2024
CVE-2024-22245	Authentication relay and session hijacking in deprecated VMware EAP; malicious actor tricks domain user into relaying Kerberos service tickets for arbitrary Active Directory SPNs	CRITICAL (9.6)	VMware: Enhanced Authentication Plug-in (deprecated)	2024
CVE-2023-27524	Default SECRET_KEY in Apache Superset used to sign session cookies; attacker with knowledge of the default value can forge valid session cookies and authenticate as any user including admins; CISA KEV	CRITICAL (9.8)	Apache Superset (≤ 2.0.1)	2023
CVE-2021-34428	Session ID remains valid in session ID manager when an exception is thrown from SessionListener#sessionDestroyed() (CWE-613); prior user's session accessible after logout on shared computers	LOW (3.5)	Eclipse Jetty (< 9.4.41, < 10.0.3, < 11.0.3)	2021
CVE-2020-17526	Session tokens signed with the default secret key accepted across different Airflow deployments; authenticated user on one instance can access another without re-authentication	HIGH (8.8)	Apache Airflow Webserver (< 1.10.14)	2020

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.

FAQs

What is Session Fixation Vulnerability?

Session fixation happens when an application keeps the same session ID before and after login. An attacker first makes the victim use a known session ID, then waits for the victim to authenticate. 

If the application does not issue a fresh ID, the attacker can use that same authenticated session. The key defense is simple: invalidate the old session and create a new one after login and other privilege changes.

Is session fixation part of OWASP Top 10?

Yes. CWE-384 is included under OWASP Top 10 2025 A07: Authentication Failures. For you as a defender, that matters less as a label than as a prioritization signal: session fixation is treated as an authentication failure, not just a cookie misconfiguration. 

It belongs in login-flow reviews, session-management testing, and authentication hardening work.

Can session fixation be exploited remotely?

Yes. Remote delivery is common because the attacker usually only needs a way to make the victim use a chosen session ID. That can happen through a crafted URL, a browser-side script, a malicious response, or a weaker application on the same parent domain. 

Physical access is only required in scenarios like shared or public terminals.

What types of applications are most vulnerable to session fixation?

The highest-risk apps are those that accept user-supplied session IDs or fail to rotate them after authentication. Common examples in the article include URL-based session schemes, CMS authentication modules, Java application stacks, shared-domain environments, workflow platforms, and ICS/SCADA web interfaces. 

The shared pattern is weak session lifecycle handling, not a single language or industry.

How do attackers typically discover session fixation?

They test whether a session survives login unchanged. A simple method is to capture a pre-authentication session ID, authenticate with it, and compare the value afterward. 

If the same ID is still valid, the flaw is present. Scanning tools can help, but manual testing is often needed for edge cases like partial regeneration or cross-subdomain cookie behavior.

What are the early signs of session fixation exploitation?

Look for one session behaving as if two users own it. Practical warning signs include the same session appearing from different IP addresses, sudden device or location shifts, or access patterns that change immediately after login. 

Requests that carry session identifiers in URLs to authentication endpoints can also indicate attempted fixation rather than normal browsing.

How severe is session fixation compared to other vulnerabilities?

Severity depends on what the compromised account can do. In low-value contexts, it may rate as medium. In high-value systems, the same flaw can enable full account takeover and administrative abuse. 

The article's CVE examples range from 4.6 to 9.8, which shows session fixation is not inherently minor; impact is driven by privilege, exposure, and surrounding controls.

Can session fixation lead to full system compromise?

It can lead directly to full compromise of the targeted account, and that may become broader compromise if the victim is an administrator. Once the attacker inherits elevated privileges, they may change settings, access sensitive data, or perform actions that affect the whole environment. 

The flaw itself targets sessions, but the business impact can extend well beyond a single login.

Is session fixation easy to find with security tools?

The simplest form is relatively easy to spot because tools can compare session IDs before and after authentication. Harder cases involve partial regeneration, inherited cookies across subdomains, or conditions tied to transport and browser behavior. 

In practice, scanning is useful for coverage, but focused manual testing is still important for confirming real exploitability.

What industries are most at risk from session fixation?

Any industry running authenticated web applications is exposed, especially where users handle sensitive data or transactions. The article highlights e-commerce, enterprise platforms, shared-domain environments, healthcare-style regulated systems, and ICS/SCADA deployments. 

Risk rises when organizations rely on plugins, legacy session handling, or multiple applications sharing a parent domain.