Common Weakness Enumeration

CWE-639

Allowed

Authorization 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:14
VLAI
Summary
Langflow: IDOR Vulnerability in `/api/v1/responses` Endpoint Allows Authenticated Attackers to Access Another User's Flow
Details

Summary

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

Show details on source website

{
  "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:10
VLAI
Summary
Duplicate Advisory: Authorization Bypass in OPC UA .NET Standard Stack
Details

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

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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:01
VLAI
Summary
OpenStack Keystone intended authorization restrictions bypass
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.

Show details on source website

{
  "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: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.

Show details on source website

{
  "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:14
VLAI
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.

Show details on source website

{
  "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:30
VLAI
Details

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

Show details on source website

{
  "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:07
VLAI
Summary
Daytona: Cross-tenant data leak in notification WebSocket gateway via unverified organizationId join
Details

Summary

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

Show details on source website

{
  "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:38
VLAI
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 WebPage::send-request signal handler to approve or reject all network requests. However, certain types of HTTP requests bypass this signal handler.

Show details on source website

{
  "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:30
VLAI
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.

Show details on source website

{
  "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
Architecture and Design

For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.

Mitigation
Architecture and Design Implementation

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
Architecture and Design

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.