CWE-639
AllowedAuthorization Bypass Through User-Controlled Key
Abstraction: Base · Status: Incomplete
The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
3256 vulnerabilities reference this CWE, most recent first.
GHSA-QRPV-Q767-XQQ2
Vulnerability from github – Published: 2026-06-19 21:16 – Updated: 2026-07-07 22:14Summary
Insecure Direct Object Reference (IDOR) vulnerability in /api/v1/responses endpoint allows an authenticated attacker to execute any flow belonging to another user by specifying the victim's flow ID in the request.
Details
The vulnerability exists in the get_flow_by_id_or_endpoint_name helper function in src/backend/base/langflow/helpers/flow.py (lines 399-414).
When a flow is accessed via UUID (flow_id), the function queries the database directly without verifying if the authenticated user owns that flow:
# src/backend/base/langflow/helpers/flow.py:399-414
async def get_flow_by_id_or_endpoint_name(flow_id_or_name: str, user_id: str | UUID | None = None) -> FlowRead:
async with session_scope() as session:
try:
flow_id = UUID(flow_id_or_name)
# When using UUID, query directly WITHOUT checking user_id
flow = await session.get(Flow, flow_id) # ❌ No user_id check!
except ValueError:
endpoint_name = flow_id_or_name
stmt = select(Flow).where(Flow.endpoint_name == endpoint_name)
# Only when using endpoint_name is user_id checked
if user_id:
stmt = stmt.where(Flow.user_id == uuid_user_id)
This function is used by the /api/v1/responses endpoint (defined in src/backend/base/langflow/api/v1/openai_responses.py:589).
PoC (Proof of Concept)
# Attacker (user A) with API_KEY_A tries to execute victim (user B)'s flow
curl -X POST "http://localhost:7860/api/v1/responses" \
-H "x-api-key: sk-ATTACKER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "VICTIM_FLOW_ID",
"input_value": "test",
"stream": false
}'
# Returns 200 and executes the victim's flow
Impact
Any authenticated user can: 1. Execute any flow in the system by knowing its flow ID 2. Access potentially sensitive data processed by victim's flows 3. Consume victim's resources
Fixes
Fixed in PR #12832 (fix(security): close IDOR in get_flow_by_id_or_endpoint_name), merged 2026-04-22, released in Langflow 1.9.1.
The helper normalizes user_id once and enforces ownership on both lookup branches (UUID and endpoint_name):
flow_id = UUID(flow_id_or_name)
flow = await session.get(Flow, flow_id)
if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id:
flow = None # cross-user lookup falls through to the shared 404
Key points:
- Cross-user lookups return 404 (not 403), so flow existence is not disclosed via a 403-vs-404 oracle.
- /api/v1/responses and /api/v2/workflow pass user_id explicitly, so fixing the helper closes them directly; the /api/v1/run* routes were additionally moved from a bare Depends(get_flow_by_id_or_endpoint_name) to auth-aware wrapper dependencies (defense in depth).
- A malformed user_id now fails closed (404 instead of a raw 500).
- Webhook routes intentionally keep the unscoped lookup (public by design / explicit ownership check elsewhere).
- Regression tests cover the cross-user UUID case and reproduce the original PoC against /api/v1/responses.
Acknowledgements
Thanks to the security researchers who responsibly disclosed this vulnerability: * @yzeirnials * @johnatzeropath * @LeftenantZero * @Zwique
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langflow"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.9.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55255"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-19T21:16:46Z",
"nvd_published_at": "2026-06-23T17:17:08Z",
"severity": "HIGH"
},
"details": "## Summary\n\nInsecure Direct Object Reference (IDOR) vulnerability in `/api/v1/responses` endpoint allows an authenticated attacker to execute any flow belonging to another user by specifying the victim\u0027s flow ID in the request.\n\n## Details\n\nThe vulnerability exists in the `get_flow_by_id_or_endpoint_name` helper function in [`src/backend/base/langflow/helpers/flow.py` (lines 399-414)](https://github.com/langflow-ai/langflow/blob/v1.9.0/src/backend/base/langflow/helpers/flow.py#L399C1-L414C67).\n\nWhen a flow is accessed via UUID (flow_id), the function queries the database directly without verifying if the authenticated user owns that flow:\n\n```python\n# src/backend/base/langflow/helpers/flow.py:399-414\nasync def get_flow_by_id_or_endpoint_name(flow_id_or_name: str, user_id: str | UUID | None = None) -\u003e FlowRead:\n async with session_scope() as session:\n try:\n flow_id = UUID(flow_id_or_name)\n # When using UUID, query directly WITHOUT checking user_id\n flow = await session.get(Flow, flow_id) # \u274c No user_id check!\n except ValueError:\n endpoint_name = flow_id_or_name\n stmt = select(Flow).where(Flow.endpoint_name == endpoint_name)\n # Only when using endpoint_name is user_id checked\n if user_id:\n stmt = stmt.where(Flow.user_id == uuid_user_id)\n```\n\nThis function is used by the `/api/v1/responses` endpoint (defined in [`src/backend/base/langflow/api/v1/openai_responses.py:589`](https://github.com/langflow-ai/langflow/blob/v1.9.0/src/backend/base/langflow/api/v1/openai_responses.py#L589)).\n\n## PoC (Proof of Concept)\n\n```bash\n# Attacker (user A) with API_KEY_A tries to execute victim (user B)\u0027s flow\ncurl -X POST \"http://localhost:7860/api/v1/responses\" \\\n -H \"x-api-key: sk-ATTACKER_API_KEY\" \\\n -H \"Content-Type: application/json\" \\\n -d \u0027{\n \"model\": \"VICTIM_FLOW_ID\",\n \"input_value\": \"test\",\n \"stream\": false\n }\u0027\n# Returns 200 and executes the victim\u0027s flow\n```\n\n## Impact\n\nAny authenticated user can:\n1. Execute any flow in the system by knowing its flow ID\n2. Access potentially sensitive data processed by victim\u0027s flows\n3. Consume victim\u0027s resources\n\n## Fixes\n\nFixed in **PR #12832** (`fix(security): close IDOR in get_flow_by_id_or_endpoint_name`), merged 2026-04-22, released in **Langflow 1.9.1**.\n\nThe helper normalizes `user_id` once and enforces ownership on **both** lookup branches (UUID *and* `endpoint_name`):\n\n```python\nflow_id = UUID(flow_id_or_name)\nflow = await session.get(Flow, flow_id)\nif flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id:\n flow = None # cross-user lookup falls through to the shared 404\n```\n\nKey points:\n- Cross-user lookups return **404** (not 403), so flow existence is not disclosed via a 403-vs-404 oracle.\n- `/api/v1/responses` and `/api/v2/workflow` pass `user_id` explicitly, so fixing the helper closes them directly; the `/api/v1/run*` routes were additionally moved from a bare `Depends(get_flow_by_id_or_endpoint_name)` to auth-aware wrapper dependencies (defense in depth).\n- A malformed `user_id` now fails closed (404 instead of a raw 500).\n- Webhook routes intentionally keep the unscoped lookup (public by design / explicit ownership check elsewhere).\n- Regression tests cover the cross-user UUID case and reproduce the original PoC against `/api/v1/responses`.\n\n\n\n\n\n## Acknowledgements\n\nThanks to the security researchers who responsibly disclosed this vulnerability:\n* @yzeirnials\n* @johnatzeropath\n* @LeftenantZero\n* @Zwique",
"id": "GHSA-qrpv-q767-xqq2",
"modified": "2026-07-07T22:14:36Z",
"published": "2026-06-19T21:16:46Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/security/advisories/GHSA-qrpv-q767-xqq2"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55255"
},
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/pull/12832"
},
{
"type": "WEB",
"url": "https://github.com/langflow-ai/langflow/commit/2c9f498d664a3c32698b57d7c5e752625291060e"
},
{
"type": "PACKAGE",
"url": "https://github.com/langflow-ai/langflow"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/langflow/PYSEC-2026-221.yaml"
},
{
"type": "WEB",
"url": "https://webflow.sysdig.com/blog/understanding-langflow-cve-2026-55255-and-why-higher-cvss-vulnerabilities-arent-always-the-most-exploited"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-55255"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Langflow: IDOR Vulnerability in `/api/v1/responses` Endpoint Allows Authenticated Attackers to Access Another User\u0027s Flow"
}
GHSA-QV5F-57GW-VX3H
Vulnerability from github – Published: 2025-02-10 21:31 – Updated: 2025-03-03 20:10Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-h958-fxgg-g7w3. This link is maintained to preserve external references.
Original Description
Vulnerability in the OPC UA .NET Standard Stack before 1.5.374.158 allows an unauthorized attacker to bypass application authentication when the deprecated Basic128Rsa15 security policy is enabled.
{
"affected": [
{
"package": {
"ecosystem": "NuGet",
"name": "OPCFoundation.NetStandard.Opc.Ua"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.374.158"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-208",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2025-02-10T22:57:19Z",
"nvd_published_at": "2025-02-10T19:15:37Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-h958-fxgg-g7w3. This link is maintained to preserve external references.\n\n## Original Description\nVulnerability in the OPC UA .NET Standard Stack before 1.5.374.158 allows an unauthorized attacker to bypass application authentication when the deprecated Basic128Rsa15 security policy is enabled.",
"id": "GHSA-qv5f-57gw-vx3h",
"modified": "2025-03-03T20:10:40Z",
"published": "2025-02-10T21:31:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-42512"
},
{
"type": "WEB",
"url": "https://files.opcfoundation.org/SecurityBulletins/OPC%20Foundation%20Security%20Bulletin%20CVE-2024-42512.pdf"
},
{
"type": "PACKAGE",
"url": "https://github.com/OPCFoundation/UA-.NETStandard"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:L",
"type": "CVSS_V3"
}
],
"summary": "Duplicate Advisory: Authorization Bypass in OPC UA .NET Standard Stack",
"withdrawn": "2025-03-03T20:10:40Z"
}
GHSA-QV8Q-WWPQ-485R
Vulnerability from github – Published: 2023-06-20 09:30 – Updated: 2024-01-12 09:30Attackers can successfully request arbitrary snippet IDs, including E-Mail signatures of other users within the same context. Signatures of other users could be read even though they are not explicitly shared. We improved permission handling when requesting snippets that are not explicitly shared with other users. No publicly available exploits are known.
{
"affected": [],
"aliases": [
"CVE-2023-26428"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-20T08:15:09Z",
"severity": "MODERATE"
},
"details": "Attackers can successfully request arbitrary snippet IDs, including E-Mail signatures of other users within the same context. Signatures of other users could be read even though they are not explicitly shared. We improved permission handling when requesting snippets that are not explicitly shared with other users. No publicly available exploits are known.\n\n",
"id": "GHSA-qv8q-wwpq-485r",
"modified": "2024-01-12T09:30:25Z",
"published": "2023-06-20T09:30:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26428"
},
{
"type": "WEB",
"url": "https://documentation.open-xchange.com/appsuite/security/advisories/csaf/2023/oxas-adv-2023-0002.json"
},
{
"type": "WEB",
"url": "https://documentation.open-xchange.com/security/advisories/csaf/oxas-adv-2023-0002.json"
},
{
"type": "WEB",
"url": "https://software.open-xchange.com/products/appsuite/doc/Release_Notes_for_Patch_Release_6219_7.10.6_2023-03-20.pdf"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/173083/OX-App-Suite-SSRF-Resource-Consumption-Command-Injection.html"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2023/Jun/8"
}
],
"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"
}
]
}
GHSA-QVPR-QM6W-6RCC
Vulnerability from github – Published: 2022-05-17 01:39 – Updated: 2026-06-10 19:01OpenStack Keystone Essex (2012.1) and Folsom (2012.2) does not properly handle EC2 tokens when the user role has been removed from a tenant, which allows remote authenticated users to bypass intended authorization restrictions by leveraging a token for the removed user role.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Keystone"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "8.0.0a0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2012-5571"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2024-01-12T20:22:36Z",
"nvd_published_at": "2012-12-18T01:55:00Z",
"severity": "MODERATE"
},
"details": "OpenStack Keystone Essex (2012.1) and Folsom (2012.2) does not properly handle EC2 tokens when the user role has been removed from a tenant, which allows remote authenticated users to bypass intended authorization restrictions by leveraging a token for the removed user role.",
"id": "GHSA-qvpr-qm6w-6rcc",
"modified": "2026-06-10T19:01:45Z",
"published": "2022-05-17T01:39:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2012-5571"
},
{
"type": "WEB",
"url": "https://github.com/openstack/keystone/commit/37308dd4f3e33f7bd0f71d83fd51734d1870713b"
},
{
"type": "WEB",
"url": "https://github.com/openstack/keystone/commit/8735009dc5b895db265a1cd573f39f4acfca2a19"
},
{
"type": "WEB",
"url": "https://github.com/openstack/keystone/commit/9d68b40cb9ea818c48152e6c712ff41586ad9653"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2012-5571"
},
{
"type": "WEB",
"url": "https://bugs.launchpad.net/keystone/+bug/1064914"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/80333"
},
{
"type": "PACKAGE",
"url": "https://github.com/openstack/keystone"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/keystone/PYSEC-2012-35.yaml"
},
{
"type": "WEB",
"url": "http://lists.fedoraproject.org/pipermail/package-announce/2012-December/094286.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2012-1556.html"
},
{
"type": "WEB",
"url": "http://rhn.redhat.com/errata/RHSA-2012-1557.html"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2012/11/28/5"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2012/11/28/6"
},
{
"type": "WEB",
"url": "http://www.ubuntu.com/usn/USN-1641-1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "OpenStack Keystone intended authorization restrictions bypass"
}
GHSA-QVQR-5CV7-WH35
Vulnerability from github – Published: 2026-03-27 18:36 – Updated: 2026-03-30 20:10Summary
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:
- csharp-sdk - https://github.com/modelcontextprotocol/csharp-sdk/blob/main/src/ModelContextProtocol.AspNetCore/SseHandler.cs#L93-L97
- 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.
{
"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-QW5P-3FQ9-8GGV
Vulnerability from github – Published: 2022-05-24 19:14 – Updated: 2022-05-24 19:14IBM Security Guardium 10.6 and 11.3 could allow a remote authenticated attacker to obtain sensitive information or modify user details caused by an insecure direct object vulnerability (IDOR). IBM X-Force ID: 202865.
{
"affected": [],
"aliases": [
"CVE-2021-29773"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-09-15T18:15:00Z",
"severity": "MODERATE"
},
"details": "IBM Security Guardium 10.6 and 11.3 could allow a remote authenticated attacker to obtain sensitive information or modify user details caused by an insecure direct object vulnerability (IDOR). IBM X-Force ID: 202865.",
"id": "GHSA-qw5p-3fq9-8ggv",
"modified": "2022-05-24T19:14:36Z",
"published": "2022-05-24T19:14:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-29773"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/202865"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6488943"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QW84-4PC7-FXVW
Vulnerability from github – Published: 2026-04-14 09:30 – Updated: 2026-04-14 09:30A vulnerability has been identified in SINEC NMS (All versions < V4.0 SP3). Affected products do not properly validate user authorization when processing password reset requests. This could allow an authenticated remote attacker to bypass authorization checks, leading to the ability to reset the password of any arbitrary user account.
{
"affected": [],
"aliases": [
"CVE-2026-25654"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-14T09:16:35Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in SINEC NMS (All versions \u003c V4.0 SP3). Affected products do not properly validate user authorization when processing password reset requests. This could allow an authenticated remote attacker to bypass authorization checks, leading to the ability to reset the password of any arbitrary user account.",
"id": "GHSA-qw84-4pc7-fxvw",
"modified": "2026-04-14T09:30:44Z",
"published": "2026-04-14T09:30:44Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-25654"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-605717.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/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"
}
]
}
GHSA-QWXF-2M7M-2M3X
Vulnerability from github – Published: 2026-06-17 18:07 – Updated: 2026-06-17 18:07Summary
A cross-tenant authorization flaw in Daytona's notification WebSocket gateway allowed any authenticated user to subscribe to another organization's realtime notification channel and passively receive that organization's events.
Impact
The notification gateway's JWT handshake joined a client-supplied organization identifier to the corresponding notification room without verifying that the authenticated user was a member of that organization. As a result, an authenticated user could receive another organization's realtime sandbox, snapshot, volume, and runner events, including data carried in those events. This is a cross-tenant confidentiality break. It required a valid account and knowledge of the target organization id (a non-secret UUID); no elevated privileges were needed. The API-key authentication path was not affected.
The affected component is the Daytona API service (the apps/api NestJS application). It is distributed through Daytona's repository releases and container images for self-hosted deployments; it is not published as a Go or npm package, so the advisory will not surface through go get or npm dependency tooling.
Affected Versions
= 0.101.0, <= 0.184.0
Patched Versions
0.185.0
Credit
@vnth4nhnt from CyStack
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 0.184.0"
},
"package": {
"ecosystem": "Go",
"name": "github.com/daytonaio/daytona"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.185.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54324"
],
"database_specific": {
"cwe_ids": [
"CWE-639",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-17T18:07:30Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\nA cross-tenant authorization flaw in Daytona\u0027s notification WebSocket gateway allowed any authenticated user to subscribe to another organization\u0027s realtime notification channel and passively receive that organization\u0027s events.\n\n### Impact\nThe notification gateway\u0027s JWT handshake joined a client-supplied organization identifier to the corresponding notification room without verifying that the authenticated user was a member of that organization. As a result, an authenticated user could receive another organization\u0027s realtime sandbox, snapshot, volume, and runner events, including data carried in those events. This is a cross-tenant confidentiality break. It required a valid account and knowledge of the target organization id (a non-secret UUID); no elevated privileges were needed. The API-key authentication path was not affected.\n\nThe affected component is the Daytona API service (the `apps/api` NestJS application). It is distributed through Daytona\u0027s repository releases and container images for self-hosted deployments; it is not published as a Go or npm package, so the advisory will not surface through `go get` or npm dependency tooling.\n\n### Affected Versions\n\u003e= 0.101.0, \u003c= 0.184.0\n\n### Patched Versions\n0.185.0\n\n### Credit\n@vnth4nhnt from CyStack",
"id": "GHSA-qwxf-2m7m-2m3x",
"modified": "2026-06-17T18:07:30Z",
"published": "2026-06-17T18:07:30Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/daytonaio/daytona/security/advisories/GHSA-qwxf-2m7m-2m3x"
},
{
"type": "PACKAGE",
"url": "https://github.com/daytonaio/daytona"
}
],
"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": "Daytona: Cross-tenant data leak in notification WebSocket gateway via unverified organizationId join"
}
GHSA-QX86-G93J-M25R
Vulnerability from github – Published: 2026-04-23 15:38 – Updated: 2026-04-23 15:38An API design flaw in WebKitGTK and WPE WebKit allows untrusted web content to unexpectedly perform IP connections, DNS lookups, and HTTP requests. Applications expect to use the WebPage::send-request signal handler to approve or reject all network requests. However, certain types of HTTP requests bypass this signal handler.
{
"affected": [],
"aliases": [
"CVE-2025-66286"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-23T13:16:11Z",
"severity": "MODERATE"
},
"details": "An API design flaw in WebKitGTK and WPE WebKit allows untrusted web content to unexpectedly perform IP connections, DNS lookups, and HTTP requests. Applications expect to use the\nWebPage::send-request signal handler to approve or reject all network requests. However, certain types of HTTP requests bypass this signal handler.",
"id": "GHSA-qx86-g93j-m25r",
"modified": "2026-04-23T15:38:56Z",
"published": "2026-04-23T15:38:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66286"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2025-66286"
},
{
"type": "WEB",
"url": "https://bugs.webkit.org/show_bug.cgi?id=259787"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2424652"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-QXM8-6XVG-W483
Vulnerability from github – Published: 2025-07-18 15:31 – Updated: 2026-06-01 15:30Authorization Bypass Through User-Controlled Key vulnerability in Vidco Software VOC TESTER allows Forceful Browsing.This issue affects VOC TESTER: before 12.41.0.
{
"affected": [],
"aliases": [
"CVE-2024-13175"
],
"database_specific": {
"cwe_ids": [
"CWE-639"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-07-18T14:15:23Z",
"severity": "MODERATE"
},
"details": "Authorization Bypass Through User-Controlled Key vulnerability in Vidco Software VOC TESTER allows Forceful Browsing.This issue affects VOC TESTER: before 12.41.0.",
"id": "GHSA-qxm8-6xvg-w483",
"modified": "2026-06-01T15:30:32Z",
"published": "2025-07-18T15:31:56Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-13175"
},
{
"type": "WEB",
"url": "https://siberguvenlik.gov.tr/guvenlik-bildirimleri/detay/tr-25-0159"
},
{
"type": "WEB",
"url": "https://www.usom.gov.tr/bildirim/tr-25-0159"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
Mitigation
Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Mitigation
Use encryption in order to make it more difficult to guess other legitimate values of the key or associate a digital signature with the key so that the server can verify that there has been no tampering.
No CAPEC attack patterns related to this CWE.