Common Weakness Enumeration

CWE-384

Allowed

Session Fixation

Abstraction: Compound · Status: Incomplete

API response cwe.mitre.org

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.

547 vulnerabilities reference this CWE, most recent first.

GHSA-QVQR-5CV7-WH35

Vulnerability from github – Published: 2026-03-27 18:36 – Updated: 2026-03-30 20:10
VLAI
Summary
MCP Ruby SDK: Insufficient Session Binding Allows SSE Stream Hijacking via Session ID Replay
Details

Summary

The Ruby SDK's streamable_http_transport.rb implementation contains a session hijacking vulnerability. An attacker who obtains a valid session ID can completely hijack the victim's Server-Sent Events (SSE) stream and intercept all real-time data.

Details

Root Cause The StreamableHTTPTransport implementation stores only one SSE stream object per session ID and lacks:

  • Session-to-user identity binding
  • Ownership validation when establishing SSE connections
  • Protection against multiple simultaneous connections to the same session

PoC

Vulnerable Code

File: streamable_http_transport.rb - L336-L339:

def store_stream_for_session(session_id, stream)
  @mutex.synchronize do
    if @sessions[session_id]
      @sessions[session_id][:stream] = stream  # OVERWRITES existing stream
    else
      stream.close
    end
  end
end

Attack Scenario

Step 1: Legitimate Session Establishment

POST / (initialize) → receives session_id: "abc123"
GET / with Mcp-Session-Id: abc123 → SSE stream connected

Step 2: Session ID Compromise

  • An attacker obtains the session ID through various means (out of scope for this analysis)

Step 3: Stream Hijacking

GET / with Mcp-Session-Id: abc123 
@sessions["abc123"][:stream] = attacker_stream `# Victim's stream is REPLACED (silently disconnected)

Step 4: Data Interception

  • ALL subsequent tool responses/notifications go to the attacker
  • The legitimate user receives no data and has no indication of the hijacking

Technical Details

The vulnerability happens:

Client 1 connects (GET request)

proc do |stream1|  # ← Rack server provides stream1 for client 1
 @sessions[session_id][:stream] = stream1  # Stored
end

Client 2 connects with SAME session ID (Attack!)

proc do |stream2|  # ← Rack provides stream2 for client 2
 @sessions[session_id][:stream] = stream2  # REPLACES stream1!
end

Now when the server sends notifications:

@sessions[session_id][:stream].write(data)  # Goes to stream2 (attacker!)
# stream1 (victim) receives nothing

Comparison: Python SDK Protection

The Python SDK prevents this vulnerability by rejecting duplicate SSE connections:

Refer: https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/streamable_http.py#L680-L685

if GET_STREAM_KEY in self._request_streams:  # pragma: no cover
            response = self._create_error_response(
                "Conflict: Only one SSE stream is allowed per session",
                HTTPStatus.CONFLICT,
            )

When a duplicate connection attempt is detected, the Python SDK returns an HTTP 409 Conflict error, protecting the existing connection.

Recommended Mitigations For SDK Maintainers

  • Implement User Binding: All SDKs should bind session IDs to authenticated user identities where possible. Currently only, go-sdk and csharp-sdk do user binding.
  • Ruby SDK: Prevent Duplicate Connections: Implement checks to reject or handle multiple simultaneous connections to the same session
  • Improve Documentation: Provide clear guidance on secure session management implementation for SDK consumers

Steps To Reproduce:

Please find attached two python client files demonstrating the attack

Terminal 1: ruby streamable_http_server.rb

Makes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb This server has a tool call notification_tool which the clients call

Terminal 2:

python3 legitimate_client_ruby_server.py

What happens:

  • The client connects and prints the session ID
  • Press Enter to start the SSE stream
  • Notifications start appearing every 3 seconds as the client makes a tool call

Terminal 3 (while the legitimate client is running):

python3 attacker_client_ruby_server.py <SESSION_ID>

Replace <SESSION_ID> with the ID from Terminal 2.

What happens immediately:

  • Terminal 2 (Legitimate): Stops receiving notifications, shows disconnect message
  • Terminal 3 (Attacker): Starts receiving ALL the tool call responses

Impact

While the absence of user binding may not pose immediate risks if session IDs are not used to store sensitive data or state, the fundamental purpose of session IDs is to maintain stateful connections. If the SDK or its consumers utilize session IDs for sensitive operations without proper user binding controls, this creates a potential security vulnerability. For example: In the case of the Ruby SDK, the attacker was able to hijack the stream and receive all the tool responses belonging to the victim. The tool responses can be sensitive confidential data.

Additional Details

Session Hijacking Protection in MCP Implementations

The MCP specification recommends - "MCP servers SHOULD bind session IDs to user-specific information".

Current Implementation Status Across SDKs

Of the 10 official MCP SDKs, only the following implementations bind session IDs to user-specific information:

  1. csharp-sdk - https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L93-L97
  2. Go-sdk - https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L281C1-L288C2

attacker_client_ruby_server.py legitimate_client_ruby_server.py The remaining SDKs do not implement session-to-user binding. Most implementations only verify that a session ID exists, without validating ownership. Additionally, SDK documentation does not provide clear guidance on implementing secure session management, leaving security responsibilities unclear for SDK consumers.

Severity
8.2 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.9.1"
      },
      "package": {
        "ecosystem": "RubyGems",
        "name": "mcp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.9.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33946"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-384",
      "CWE-639"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-27T18:36:45Z",
    "nvd_published_at": "2026-03-27T22:16:21Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe Ruby SDK\u0027s [streamable_http_transport.rb](https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb) implementation contains a session hijacking vulnerability. An attacker who obtains a valid session ID can completely hijack the victim\u0027s Server-Sent Events (SSE) stream and intercept all real-time data.\n\n### Details\n**Root Cause**\nThe StreamableHTTPTransport implementation stores only one SSE stream object per session ID and lacks:\n\n- Session-to-user identity binding\n- Ownership validation when establishing SSE connections\n- Protection against multiple simultaneous connections to the same session\n\n### PoC\n\n#### Vulnerable Code\n\n**File**: streamable_http_transport.rb - [L336-L339](https://github.com/modelcontextprotocol/ruby-sdk/blob/main/lib/mcp/server/transports/streamable_http_transport.rb#L336-L339):\n\n```\ndef store_stream_for_session(session_id, stream)\n  @mutex.synchronize do\n    if @sessions[session_id]\n      @sessions[session_id][:stream] = stream  # OVERWRITES existing stream\n    else\n      stream.close\n    end\n  end\nend\n```\n#### Attack Scenario\n**Step 1**: Legitimate Session Establishment\n```\nPOST / (initialize) \u2192 receives session_id: \"abc123\"\nGET / with Mcp-Session-Id: abc123 \u2192 SSE stream connected\n```\nStep 2: Session ID Compromise\n\n- An attacker obtains the session ID through various means (out of scope for this analysis)\n\n**Step 3**: Stream Hijacking\n\n```\nGET / with Mcp-Session-Id: abc123 \n@sessions[\"abc123\"][:stream] = attacker_stream `# Victim\u0027s stream is REPLACED (silently disconnected)\n```\n\n**Step 4**: Data Interception\n\n- ALL subsequent tool responses/notifications go to the attacker\n- The legitimate user receives no data and has no indication of the hijacking\n\n#### Technical Details\n\nThe vulnerability happens:\n\n**Client 1 connects (GET request)**\n\n```\nproc do |stream1|  # \u2190 Rack server provides stream1 for client 1\n @sessions[session_id][:stream] = stream1  # Stored\nend\n```\n\n**Client 2 connects with SAME session ID (Attack!)**\n```\nproc do |stream2|  # \u2190 Rack provides stream2 for client 2\n @sessions[session_id][:stream] = stream2  # REPLACES stream1!\nend\n```\n\n**Now when the server sends notifications:**\n\n```\n@sessions[session_id][:stream].write(data)  # Goes to stream2 (attacker!)\n# stream1 (victim) receives nothing\n```\n\n**Comparison: Python SDK Protection**\n\nThe Python SDK prevents this vulnerability by rejecting duplicate SSE connections:\n\n**Refer**: https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/streamable_http.py#L680-L685\n\n```\nif GET_STREAM_KEY in self._request_streams:  # pragma: no cover\n            response = self._create_error_response(\n                \"Conflict: Only one SSE stream is allowed per session\",\n                HTTPStatus.CONFLICT,\n            )\n```\n\nWhen a duplicate connection attempt is detected, the Python SDK returns an HTTP 409 Conflict error, protecting the existing connection.\n\n**Recommended Mitigations**\n**For SDK Maintainers**\n\n- Implement User Binding: All SDKs should bind session IDs to authenticated user identities where possible. Currently only, go-sdk and csharp-sdk do user binding.\n- **Ruby SDK**: Prevent Duplicate Connections: Implement checks to reject or handle multiple simultaneous connections to the same session\n- **Improve Documentation**: Provide clear guidance on secure session management implementation for SDK consumers\n\n### Steps To Reproduce:\n\nPlease find attached two python client files demonstrating the attack\n\n**Terminal 1:**\n`ruby streamable_http_server.rb`\n\nMakes use of https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb\nThis server has a tool call notification_tool which the clients call\n\n**Terminal 2:**\n\n`python3 legitimate_client_ruby_server.py`\n\n**What happens:**\n\n- The client connects and prints the session ID\n- Press Enter to start the SSE stream\n- Notifications start appearing every 3 seconds as the client makes a tool call\n\n**Terminal 3 (while the legitimate client is running):**\n\n`python3 attacker_client_ruby_server.py \u003cSESSION_ID\u003e`\n\nReplace `\u003cSESSION_ID\u003e` with the ID from Terminal 2.\n\n**What happens immediately:**\n\n- Terminal 2 (Legitimate): Stops receiving notifications, shows disconnect message\n- Terminal 3 (Attacker): Starts receiving ALL the tool call responses\n\n### Impact\nWhile the absence of user binding may not pose immediate risks if session IDs are not used to store sensitive data or state, the fundamental purpose of session IDs is to maintain stateful connections. If the SDK or its consumers utilize session IDs for sensitive operations without proper user binding controls, this creates a potential security vulnerability. For example: In the case of the Ruby SDK, the attacker was able to hijack the stream and receive all the tool responses belonging to the victim. The tool responses can be sensitive confidential data.\n\n### Additional Details\n#### Session Hijacking Protection in MCP Implementations\nThe MCP specification recommends - \"MCP servers SHOULD bind session IDs to user-specific information\".\n\n#### Current Implementation Status Across SDKs\n\nOf the 10 official MCP SDKs, only the following implementations bind session IDs to user-specific information:\n\n1. csharp-sdk - https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L93-L97\n2. Go-sdk - https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L281C1-L288C2\n\n[attacker_client_ruby_server.py](https://github.com/user-attachments/files/25408485/attacker_client_ruby_server.py)\n[legitimate_client_ruby_server.py](https://github.com/user-attachments/files/25408486/legitimate_client_ruby_server.py)\nThe remaining SDKs do not implement session-to-user binding. Most implementations only verify that a session ID exists, without validating ownership. Additionally, SDK documentation does not provide clear guidance on implementing secure session management, leaving security responsibilities unclear for SDK consumers.",
  "id": "GHSA-qvqr-5cv7-wh35",
  "modified": "2026-03-30T20:10:39Z",
  "published": "2026-03-27T18:36:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/ruby-sdk/security/advisories/GHSA-qvqr-5cv7-wh35"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33946"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/ruby-sdk/commit/db40143402d65b4fb6923cec42d2d72cb89b3874"
    },
    {
      "type": "WEB",
      "url": "https://hackerone.com/reports/3556146"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L93-L97"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/go-sdk/blob/main/mcp/streamable.go#L281C1-L288C2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/python-sdk/blob/main/src/mcp/server/streamable_http.py#L680-L685"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/modelcontextprotocol/ruby-sdk"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/ruby-sdk/blob/main/examples/streamable_http_server.rb"
    },
    {
      "type": "WEB",
      "url": "https://github.com/modelcontextprotocol/ruby-sdk/releases/tag/v0.9.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/mcp/CVE-2026-33946.yml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "MCP Ruby SDK: Insufficient Session Binding Allows SSE Stream Hijacking via Session ID Replay"
}

GHSA-QW2P-V864-678M

Vulnerability from github – Published: 2022-05-14 01:38 – Updated: 2022-05-14 01:38
VLAI
Details

A Session Fixation issue was discovered in Bigtree before 4.2.24. admin.php accepts a user-provided PHP session ID instead of regenerating a new one after a user has logged in to the application. The Session Fixation could allow an attacker to hijack an admin session.

Severity
5.4 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2018-18380"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-384"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-10-19T20:29:00Z",
    "severity": "MODERATE"
  },
  "details": "A Session Fixation issue was discovered in Bigtree before 4.2.24. admin.php accepts a user-provided PHP session ID instead of regenerating a new one after a user has logged in to the application. The Session Fixation could allow an attacker to hijack an admin session.",
  "id": "GHSA-qw2p-v864-678m",
  "modified": "2022-05-14T01:38:50Z",
  "published": "2022-05-14T01:38:50Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-18380"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bigtreecms/BigTree-CMS/commit/c69402c4764ed9a76301c57277aefe70141b6418"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/zionspike/680eb504db7c86296fad0eff30c6317f"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bigtreecms/BigTree-CMS/tree/4.2.24"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-QW36-P97W-VCQR

Vulnerability from github – Published: 2021-11-24 20:05 – Updated: 2021-12-01 14:36
VLAI
Summary
Cookie persistence after password changes in symfony/security-bundle
Details

Description

Since the rework of the Remember me cookie in Symfony 5.3, the cookie is not invalidated anymore when the user changes its password.

Attackers can therefore maintain their access to the account even if the password is changed as long as they have had the chance to login once and get a valid remember me cookie.

Resolution

Symfony now makes the password part of the signature by default. In that way, when the password changes then the cookie is not valid anymore.

The patch for this issue is available here for branch 5.3.

Credits

We would like to thank Thibaut Decherit for reporting the issue and Wouter J for fixing the issue.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/security-bundle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.3.0"
            },
            {
              "fixed": "5.3.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "symfony/symfony"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.3.0"
            },
            {
              "fixed": "5.3.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-41268"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-384"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-11-24T20:00:03Z",
    "nvd_published_at": "2021-11-24T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Description\n-----------\n\nSince the rework of the Remember me cookie in Symfony 5.3, the cookie is not invalidated anymore when the user changes its password. \n\nAttackers can therefore maintain their access to the account even if the password is changed as long as they have had the chance to login once and get a valid remember me cookie.\n\nResolution\n----------\n\nSymfony now makes the password part of the signature by default. In that way, when the password changes then the cookie is not valid anymore.\n\nThe patch for this issue is available [here](https://github.com/symfony/symfony/commit/36a808b857cd3240244f4b224452fb1e70dc6dfc) for branch 5.3.\n\nCredits\n-------\n\nWe would like to thank Thibaut Decherit for reporting the issue and Wouter J for fixing the issue.\n",
  "id": "GHSA-qw36-p97w-vcqr",
  "modified": "2021-12-01T14:36:09Z",
  "published": "2021-11-24T20:05:22Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/security/advisories/GHSA-qw36-p97w-vcqr"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-41268"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/pull/44243"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/commit/36a808b857cd3240244f4b224452fb1e70dc6dfc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/security-bundle/CVE-2021-41268.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/symfony/symfony/CVE-2021-41268.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/symfony/symfony"
    },
    {
      "type": "WEB",
      "url": "https://github.com/symfony/symfony/releases/tag/v5.3.12"
    },
    {
      "type": "WEB",
      "url": "https://symfony.com/cve-2021-41268"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Cookie persistence after password changes in symfony/security-bundle"
}

GHSA-R2VW-P77F-VC27

Vulnerability from github – Published: 2022-05-17 02:36 – Updated: 2024-04-24 18:11
VLAI
Summary
phpMyAdmin Bypass logout timeout
Details

An issue was discovered in phpMyAdmin. With a crafted request parameter value it is possible to bypass the logout timeout. All 4.6.x versions (prior to 4.6.5), and 4.4.x versions (prior to 4.4.15.9) are affected.

Severity
5.3 (Medium)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpmyadmin/phpmyadmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.6"
            },
            {
              "fixed": "4.6.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "phpmyadmin/phpmyadmin"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.4"
            },
            {
              "fixed": "4.4.15.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2016-9851"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-384"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-24T18:11:42Z",
    "nvd_published_at": "2016-12-11T02:59:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in phpMyAdmin. With a crafted request parameter value it is possible to bypass the logout timeout. All 4.6.x versions (prior to 4.6.5), and 4.4.x versions (prior to 4.4.15.9) are affected.",
  "id": "GHSA-r2vw-p77f-vc27",
  "modified": "2024-04-24T18:11:42Z",
  "published": "2022-05-17T02:36:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-9851"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/phpmyadmin/composer"
    },
    {
      "type": "WEB",
      "url": "https://security.gentoo.org/glsa/201701-32"
    },
    {
      "type": "WEB",
      "url": "https://www.phpmyadmin.net/security/PMASA-2016-62"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/94534"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "phpMyAdmin Bypass logout timeout"
}

GHSA-R3XH-3R3W-47GP

Vulnerability from github – Published: 2026-02-12 15:29 – Updated: 2026-02-12 22:07
VLAI
Summary
FrankenPHP leaks session data between requests in worker mode
Details

Summary

When running FrankenPHP in worker mode, the $_SESSION superglobal is not correctly reset between requests. This allows a subsequent request processed by the same worker to access the $_SESSION data of the previous request (potentially belonging to a different user) before session_start() is called.

Details

In standard PHP execution, the environment is torn down completely after every request. In FrankenPHP's worker mode, the application stays in memory, and superglobals are manually reset between requests.

The vulnerability exists because $_SESSION is stored in the Zend Engine's symbol table (EG(symbol_table)). While the standard PHP request shutdown (RSHUTDOWN) decrements the reference count of the session data, it does not remove the $_SESSION variable itself from the symbol table. FrankenPHP's reset logic (frankenphp_reset_super_globals) previously cleared other superglobals but failed to explicitly delete $_SESSION.

Consequently, until session_start() is called in the new request (which re-initializes the variable), the $_SESSION array retains the data from the previous request processed by that specific worker thread.

Impact

This is a cross-request data leakage vulnerability.

  • Confidentiality: If an application reads $_SESSION before calling session_start(), it can access sensitive information (authentication tokens, user IDs, PII) belonging to the previous user.
  • Logic Errors / Impersonation: If application logic relies on $_SESSION being empty or unset to detect a "guest" state, or checks for specific keys in $_SESSION prior to session initialization, a malicious actor (or accidental race condition) could trigger privilege escalation or user impersonation.

This affects only users running FrankenPHP in worker mode and not session_start() for each request, which is done by default by most frameworks.

PoC

The following steps demonstrate the issue (derived from the regression tests added in the fix):

  1. Client A sends a request that starts a session and sets sensitive data:
// Request 1
session_start();
$_SESSION['secret'] = 'AliceData';
session_write_close();
  1. Client B (or the same client without cookies) sends a request to the same worker. This script checks $_SESSION without starting a session:
// Request 2
// session_start() is NOT called
if (!empty($_SESSION)) {
    echo "Leaked Data: " . $_SESSION['secret'];
}
  1. Result: Client B receives "Leaked Data: AliceData".

Workarounds

  • Ensure session_start() is called immediately at the entry point of your worker script to overwrite any residual data (though this may not cover all edge cases if middleware runs before the controller).
  • Manually unset $_SESSION at the very beginning of the worker loop, before handling the request.
Severity
8.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/dunglas/frankenphp"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.11.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-24894"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-384",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-12T15:29:30Z",
    "nvd_published_at": "2026-02-12T20:16:10Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nWhen running FrankenPHP in **worker mode**, the `$_SESSION` superglobal is not correctly reset between requests. This allows a subsequent request processed by the same worker to access the `$_SESSION` data of the previous request (potentially belonging to a different user) before `session_start()` is called.\n\n### Details\n\nIn standard PHP execution, the environment is torn down completely after every request. In FrankenPHP\u0027s worker mode, the application stays in memory, and superglobals are manually reset between requests.\n\nThe vulnerability exists because `$_SESSION` is stored in the Zend Engine\u0027s symbol table (`EG(symbol_table)`). While the standard PHP request shutdown (RSHUTDOWN) decrements the reference count of the session data, it does not remove the `$_SESSION` variable itself from the symbol table. FrankenPHP\u0027s reset logic (`frankenphp_reset_super_globals`) previously cleared other superglobals but failed to explicitly delete `$_SESSION`.\n\nConsequently, until `session_start()` is called in the new request (which re-initializes the variable), the `$_SESSION` array retains the data from the previous request processed by that specific worker thread.\n\n### Impact\n\nThis is a **cross-request data leakage** vulnerability.\n\n* **Confidentiality:** If an application reads `$_SESSION` before calling `session_start()`, it can access sensitive information (authentication tokens, user IDs, PII) belonging to the previous user.\n* **Logic Errors / Impersonation:** If application logic relies on `$_SESSION` being empty or unset to detect a \"guest\" state, or checks for specific keys in `$_SESSION` prior to session initialization, a malicious actor (or accidental race condition) could trigger privilege escalation or user impersonation.\n\nThis affects only users running FrankenPHP in **worker mode** and not `session_start()` for each request, which is done by default by most frameworks.\n\n### PoC\n\nThe following steps demonstrate the issue (derived from the regression tests added in the fix):\n\n1. **Client A** sends a request that starts a session and sets sensitive data:\n\n```php\n// Request 1\nsession_start();\n$_SESSION[\u0027secret\u0027] = \u0027AliceData\u0027;\nsession_write_close();\n```\n\n2. **Client B** (or the same client without cookies) sends a request to the same worker. This script checks `$_SESSION` *without* starting a session:\n\n```php\n// Request 2\n// session_start() is NOT called\nif (!empty($_SESSION)) {\n    echo \"Leaked Data: \" . $_SESSION[\u0027secret\u0027];\n}\n```\n\n\n3. **Result:** Client B receives \"Leaked Data: AliceData\".\n\n### Workarounds\n\n* Ensure `session_start()` is called immediately at the entry point of your worker script to overwrite any residual data (though this may not cover all edge cases if middleware runs before the controller).\n* Manually unset `$_SESSION` at the very beginning of the worker loop, before handling the request.",
  "id": "GHSA-r3xh-3r3w-47gp",
  "modified": "2026-02-12T22:07:50Z",
  "published": "2026-02-12T15:29:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/php/frankenphp/security/advisories/GHSA-r3xh-3r3w-47gp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24894"
    },
    {
      "type": "WEB",
      "url": "https://github.com/php/frankenphp/commit/24d6c991a7761b638190eb081deae258143e9735"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/php/frankenphp"
    },
    {
      "type": "WEB",
      "url": "https://github.com/php/frankenphp/releases/tag/v1.11.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ],
  "summary": "FrankenPHP leaks session data between requests in worker mode"
}

GHSA-R4R6-J2J3-7PP5

Vulnerability from github – Published: 2024-04-09 16:15 – Updated: 2024-04-09 21:12
VLAI
Summary
Contao: Remember-me tokens will not be cleared after a password change
Details

Impact

When a front end member changes their password, the corresponding remember-me tokens are not removed.

Patches

Update to Contao 4.13.40.

Workarounds

Disable "Allow auto login" in the login module.

References

https://contao.org/en/security-advisories/remember-me-tokens-are-not-cleared-after-a-password-change

For more information

If you have any questions or comments about this advisory, open an issue in contao/contao.

Severity
5.9 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "contao/core-bundle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.13.40"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-30262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-384",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-09T16:15:06Z",
    "nvd_published_at": "2024-04-09T17:16:02Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nWhen a front end member changes their password, the corresponding remember-me tokens are not removed.\n\n### Patches\n\nUpdate to Contao 4.13.40.\n\n### Workarounds\n\nDisable \"Allow auto login\" in the login module.\n\n### References\n\nhttps://contao.org/en/security-advisories/remember-me-tokens-are-not-cleared-after-a-password-change\n\n### For more information\n\nIf you have any questions or comments about this advisory, open an issue in [contao/contao](https://github.com/contao/contao/issues/new/choose).",
  "id": "GHSA-r4r6-j2j3-7pp5",
  "modified": "2024-04-09T21:12:19Z",
  "published": "2024-04-09T16:15:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/contao/contao/security/advisories/GHSA-r4r6-j2j3-7pp5"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30262"
    },
    {
      "type": "WEB",
      "url": "https://github.com/contao/contao/commit/3032baa456f607169ffae82a8920354adb338fe9"
    },
    {
      "type": "WEB",
      "url": "https://contao.org/en/security-advisories/remember-me-tokens-are-not-cleared-after-a-password-change"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/contao/contao"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Contao: Remember-me tokens will not be cleared after a password change"
}

GHSA-R4X6-GMW8-J8RH

Vulnerability from github – Published: 2026-03-09 21:31 – Updated: 2026-03-10 18:31
VLAI
Details

ScadaBR 1.12.4 is vulnerable to Session Fixation. The application assigns a JSESSIONID session cookie to unauthenticated users and does not regenerate the session identifier after successful authentication. As a result, a session created prior to login becomes authenticated once the victim logs in, allowing an attacker who knows the session ID to hijack an authenticated session.

Severity
4.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-70973"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-384"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-09T21:16:12Z",
    "severity": "MODERATE"
  },
  "details": "ScadaBR 1.12.4 is vulnerable to Session Fixation. The application assigns a JSESSIONID session cookie to unauthenticated users and does not regenerate the session identifier after successful authentication. As a result, a session created prior to login becomes authenticated once the victim logs in, allowing an attacker who knows the session ID to hijack an authenticated session.",
  "id": "GHSA-r4x6-gmw8-j8rh",
  "modified": "2026-03-10T18:31:16Z",
  "published": "2026-03-09T21:31:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-70973"
    },
    {
      "type": "WEB",
      "url": "https://github.com/chiranjib2001/ScadaBR/blob/main/README.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R7FX-8G9M-3539

Vulnerability from github – Published: 2022-05-24 19:21 – Updated: 2022-05-24 19:21
VLAI
Details

Session fixation vulnerability in D-Link DIR-600L routers (rev. Ax) with firmware before FW1.17.B01 allows remote attackers to hijack web sessions via unspecified vectors.

Severity
9.8 (Critical)
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2016-10405"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-384"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-09-07T13:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Session fixation vulnerability in D-Link DIR-600L routers (rev. Ax) with firmware before FW1.17.B01 allows remote attackers to hijack web sessions via unspecified vectors.",
  "id": "GHSA-r7fx-8g9m-3539",
  "modified": "2022-05-24T19:21:22Z",
  "published": "2022-05-24T19:21:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2016-10405"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R89W-QX4V-XPFV

Vulnerability from github – Published: 2025-02-05 18:34 – Updated: 2025-10-10 18:31
VLAI
Details

HCL iAutomate is affected by a session fixation vulnerability.  An attacker could hijack a victim's session ID from their authenticated session.

Severity
5.5 (Medium)
CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:L/A:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-42207"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-384"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-05T16:15:40Z",
    "severity": "MODERATE"
  },
  "details": "HCL iAutomate is affected by a session fixation vulnerability. \u00a0An attacker could hijack a victim\u0027s session ID from their authenticated session.",
  "id": "GHSA-r89w-qx4v-xpfv",
  "modified": "2025-10-10T18:31:16Z",
  "published": "2025-02-05T18:34:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42207"
    },
    {
      "type": "WEB",
      "url": "https://support.hcl-software.com/csm?id=kb_article\u0026sysparm_article=KB0118946"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-R9VC-JFMH-6J48

Vulnerability from github – Published: 2024-05-30 21:04 – Updated: 2024-05-30 21:04
VLAI
Summary
TYPO3 frontend login vulnerable to Session Fixation
Details

It has been discovered that TYPO3 is susceptible to session fixation. If a user authenticates while anonymous session data is present, the session id is not changed. This makes it possible for attackers to generate a valid session id, trick users into using this session id (e.g. by leveraging a different Cross-Site Scripting vulnerability) and then maybe getting access to an authenticated session.

Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.2.0"
            },
            {
              "fixed": "6.2.14"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "typo3/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "7.0.0"
            },
            {
              "fixed": "7.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-384"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-30T21:04:40Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "It has been discovered that TYPO3 is susceptible to session fixation. If a user authenticates while anonymous session data is present, the session id is not changed. This makes it possible for attackers to generate a valid session id, trick users into using this session id (e.g. by leveraging a different Cross-Site Scripting vulnerability) and then maybe getting access to an authenticated session.",
  "id": "GHSA-r9vc-jfmh-6j48",
  "modified": "2024-05-30T21:04:40Z",
  "published": "2024-05-30T21:04:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/4c9aba94a930d56ab374693c9c5cc0458587278a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/TYPO3/typo3/commit/4f6e84bba3c13ea8b2652af1a4c47758aa0705f4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/typo3/cms/2015-07-01-2.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/TYPO3/typo3"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/security/advisory/typo3-core-sa-2015-003"
    },
    {
      "type": "WEB",
      "url": "https://typo3.org/teams/security/security-bulletins/typo3-core/typo3-core-sa-2015-003"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "TYPO3 frontend login vulnerable to Session Fixation"
}
Mitigation
Architecture and Design

Invalidate any existing session identifiers prior to authorizing a new user session.

Mitigation
Architecture and Design

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.

Mitigation MIT-29
Operation

Strategy: Firewall

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].

CAPEC-196: Session Credential Falsification through Forging

An attacker creates a false but functional session credential in order to gain or usurp access to a service. Session credentials allow users to identify themselves to a service after an initial authentication without needing to resend the authentication information (usually a username and password) with every message. If an attacker is able to forge valid session credentials they may be able to bypass authentication or piggy-back off some other authenticated user's session. This attack differs from Reuse of Session IDs and Session Sidejacking attacks in that in the latter attacks an attacker uses a previous or existing credential without modification while, in a forging attack, the attacker must create their own credential, although it may be based on previously observed credentials.

CAPEC-21: Exploitation of Trusted Identifiers

An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.

CAPEC-31: Accessing/Intercepting/Modifying HTTP Cookies

This attack relies on the use of HTTP Cookies to store credentials, state information and other critical data on client systems. There are several different forms of this attack. The first form of this attack involves accessing HTTP Cookies to mine for potentially sensitive data contained therein. The second form involves intercepting this data as it is transmitted from client to server. This intercepted information is then used by the adversary to impersonate the remote user/session. The third form is when the cookie's content is modified by the adversary before it is sent back to the server. Here the adversary seeks to convince the target server to operate on this falsified information.

CAPEC-39: Manipulating Opaque Client-based Data Tokens

In circumstances where an application holds important data client-side in tokens (cookies, URLs, data files, and so forth) that data can be manipulated. If client or server-side application components reinterpret that data as authentication tokens or data (such as store item pricing or wallet information) then even opaquely manipulating that data may bear fruit for an Attacker. In this pattern an attacker undermines the assumption that client side tokens have been adequately protected from tampering through use of encryption or obfuscation.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-61: Session Fixation

The attacker induces a client to establish a session with the target software using a session identifier provided by the attacker. Once the user successfully authenticates to the target software, the attacker uses the (now privileged) session identifier in their own transactions. This attack leverages the fact that the target software either relies on client-generated session identifiers or maintains the same session identifiers after privilege elevation.

← Back to the CWE list