Common Weakness Enumeration

CWE-1327

Allowed

Binding to an Unrestricted IP Address

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The product assigns the address 0.0.0.0 for a database server, a cloud service/instance, or any computing resource that communicates remotely.

37 vulnerabilities reference this CWE, most recent first.

GHSA-G3WF-C9JP-7296

Vulnerability from github – Published: 2024-10-15 12:30 – Updated: 2024-10-15 12:30
VLAI
Details

Excessive attack surface in archive-server service due to binding to an unrestricted IP address. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 38690.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-49382"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-15T11:15:13Z",
    "severity": "LOW"
  },
  "details": "Excessive attack surface in archive-server service due to binding to an unrestricted IP address. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 38690.",
  "id": "GHSA-g3wf-c9jp-7296",
  "modified": "2024-10-15T12:30:37Z",
  "published": "2024-10-15T12:30:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49382"
    },
    {
      "type": "WEB",
      "url": "https://security-advisory.acronis.com/advisories/SEC-7286"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-G7C7-634V-GP3R

Vulnerability from github – Published: 2026-05-15 06:30 – Updated: 2026-05-15 06:30
VLAI
Details

Unrestricted IP address binding in the AMD Device Metrics Exporter (ROCm ecosystem) could allow a remote attacker to perform unauthorized changes to the GPU configuration, potentially resulting in loss of availability

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-0481"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-15T05:16:33Z",
    "severity": "CRITICAL"
  },
  "details": "Unrestricted IP address binding in the AMD Device Metrics Exporter (ROCm ecosystem) could allow a remote attacker to perform unauthorized changes to the GPU configuration, potentially resulting in loss of availability",
  "id": "GHSA-g7c7-634v-gp3r",
  "modified": "2026-05-15T06:30:29Z",
  "published": "2026-05-15T06:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-0481"
    },
    {
      "type": "WEB",
      "url": "https://www.amd.com/en/resources/product-security/bulletin/AMD-SB-6031.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:H/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-J4VQ-Q93M-4683

Vulnerability from github – Published: 2025-12-02 00:35 – Updated: 2025-12-02 00:35
VLAI
Summary
Keycloak has debug default bind address
Details

A vulnerability exists in Keycloak's server distribution where enabling debug mode (--debug) insecurely defaults to binding the Java Debug Wire Protocol (JDWP) port to all network interfaces (0.0.0.0). This exposes the debug port to the local network, allowing an attacker on the same network segment to attach a remote debugger and achieve remote code execution within the Keycloak Java virtual machine.

Red Hat evaluates this as a Moderate impact vulnerability due to the requirement of running debug mode and untrusted network. Also, for Red Hat Single Sign-On, this must as well be bound to 0.0.0.0 address, which is not recommended in production scenarios.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-quarkus-dist"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.4.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-11538"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-12-02T00:35:03Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "A vulnerability exists in Keycloak\u0027s server distribution where enabling debug mode (`--debug`) insecurely defaults to binding the Java Debug Wire Protocol (JDWP) port to all network interfaces (`0.0.0.0`). This exposes the debug port to the local network, allowing an attacker on the same network segment to attach a remote debugger and achieve remote code execution within the Keycloak Java virtual machine.\n\nRed Hat evaluates this as a Moderate impact vulnerability due to the requirement of running debug mode and untrusted network. Also, for Red Hat Single Sign-On, this must as well be bound to 0.0.0.0 address, which is not recommended in production scenarios.",
  "id": "GHSA-j4vq-q93m-4683",
  "modified": "2025-12-02T00:35:03Z",
  "published": "2025-12-02T00:35:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/security/advisories/GHSA-j4vq-q93m-4683"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11538"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21370"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21371"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-11538"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2402622"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Keycloak has debug default bind address"
}

GHSA-MFW9-VJXF-GVR8

Vulnerability from github – Published: 2026-02-10 18:30 – Updated: 2026-02-10 18:30
VLAI
Details

Binding to an unrestricted ip address in Azure IoT SDK allows an unauthorized attacker to disclose information over a network.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-21528"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327",
      "CWE-668"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-02-10T18:16:35Z",
    "severity": "MODERATE"
  },
  "details": "Binding to an unrestricted ip address in Azure IoT SDK allows an unauthorized attacker to disclose information over a network.",
  "id": "GHSA-mfw9-vjxf-gvr8",
  "modified": "2026-02-10T18:30:42Z",
  "published": "2026-02-10T18:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21528"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-21528"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-PMRX-695R-4349

Vulnerability from github – Published: 2024-05-28 21:19 – Updated: 2024-05-28 21:19
VLAI
Summary
dbt allows Binding to an Unrestricted IP Address via socketsocket
Details

Summary

Binding to INADDR_ANY (0.0.0.0) or IN6ADDR_ANY (::) exposes an application on all network interfaces, increasing the risk of unauthorized access.

While doing some static analysis and code inspection, I found the following code binding a socket to INADDR_ANY by passing "" as the address. This effectively binds to any network interface on the local system, not just localhost (127.0.0.1).

Details

As stated in the Python docs, a special form for address is accepted instead of a host address: '' represents INADDR_ANY, equivalent to "0.0.0.0". On systems with IPv6, '' represents IN6ADDR_ANY, which is equivalent to "::".

https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/task/docs/serve.py#L23C38-L23C39

The text around this code also imply the intention is to host docs only on localhost.

PoC

To recreate, run the docs ServeTask.run() to stand up the HTTP server. Then run netstat to see what addresses this process is bound.

Impact

A user who serves docs on an unsecured public network, may unknowingly be hosting an unsecured (http) web site for any remote user/system to access on the same network.

Further references: https://docs.python.org/3/library/socket.html#socket-families https://docs.securesauce.dev/rules/PY030 https://cwe.mitre.org/data/definitions/1327.html

Patches

The issue has has been mitigated in dbt-core v1.6.15, dbt-core v1.7.15, and dbt-core v1.8.1 by binding to localhost explicitly by default in dbt docs serve (https://github.com/dbt-labs/dbt-core/issues/10209).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "dbt-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "dbt-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.7.0"
            },
            {
              "fixed": "1.7.15"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "dbt-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.8.0"
            },
            {
              "fixed": "1.8.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.8.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2024-36105"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-28T21:19:14Z",
    "nvd_published_at": "2024-05-27T18:15:10Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nBinding to `INADDR_ANY (0.0.0.0)` or `IN6ADDR_ANY (::)` exposes an application on all network interfaces, increasing the risk of unauthorized access.\n\nWhile doing some static analysis and code inspection, I found the following code binding a socket to `INADDR_ANY` by passing `\"\"` as the address. This effectively binds to any network interface on the local system, not just localhost (127.0.0.1). \n\n### Details\n\nAs stated in the Python docs, a special form for address is accepted instead of a host address: `\u0027\u0027` represents `INADDR_ANY`, equivalent to `\"0.0.0.0\"`. On systems with IPv6, \u0027\u0027 represents `IN6ADDR_ANY`, which is equivalent to `\"::\"`. \n\nhttps://github.com/dbt-labs/dbt-core/blob/main/core/dbt/task/docs/serve.py#L23C38-L23C39\n\nThe text around this code also imply the intention is to host docs only on localhost.\n\n### PoC\n\nTo recreate, run the docs ServeTask.run() to stand up the HTTP server.  Then run `netstat` to see what addresses this process is bound.\n\n### Impact\n\nA user who serves docs on an unsecured public network, may unknowingly be hosting an unsecured (http) web site for any remote user/system to access on the same network.\n\nFurther references:\nhttps://docs.python.org/3/library/socket.html#socket-families\nhttps://docs.securesauce.dev/rules/PY030\nhttps://cwe.mitre.org/data/definitions/1327.html\n\n### Patches\nThe issue has has been mitigated in [dbt-core v1.6.15](https://github.com/dbt-labs/dbt-core/releases/tag/v1.6.15), [dbt-core v1.7.15](https://github.com/dbt-labs/dbt-core/releases/tag/v1.7.15), and [dbt-core v1.8.1](https://github.com/dbt-labs/dbt-core/releases/tag/v1.8.1) by binding to localhost explicitly by default in `dbt docs serve` (https://github.com/dbt-labs/dbt-core/issues/10209).\n",
  "id": "GHSA-pmrx-695r-4349",
  "modified": "2024-05-28T21:19:14Z",
  "published": "2024-05-28T21:19:14Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-core/security/advisories/GHSA-pmrx-695r-4349"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36105"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-core/issues/10209"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-core/pull/10208"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-core/commit/0c08d7a19ad1740be3cb0b2e6d9d64f6537176f7"
    },
    {
      "type": "WEB",
      "url": "https://cwe.mitre.org/data/definitions/1327.html"
    },
    {
      "type": "WEB",
      "url": "https://docs.python.org/3/library/socket.html#socket-families"
    },
    {
      "type": "WEB",
      "url": "https://docs.securesauce.dev/rules/PY030"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/dbt-labs/dbt-core"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-core/blob/main/core/dbt/task/docs/serve.py#L23C38-L23C39"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-core/releases/tag/v1.6.15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-core/releases/tag/v1.7.15"
    },
    {
      "type": "WEB",
      "url": "https://github.com/dbt-labs/dbt-core/releases/tag/v1.8.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "dbt allows Binding to an Unrestricted IP Address via socketsocket"
}

GHSA-QW99-GRCX-4PVM

Vulnerability from github – Published: 2026-02-17 17:09 – Updated: 2026-03-06 00:58
VLAI
Summary
OpenClaw's Chrome extension relay binds publicly due to wildcard treated as loopback
Details

Summary

The Chrome extension relay (ensureChromeExtensionRelayServer) previously treated wildcard hosts (0.0.0.0 / ::) as loopback, which could make it bind the relay HTTP/WS server to all interfaces when a wildcard cdpUrl was passed.

Impact

If configured with a wildcard cdpUrl, relay HTTP endpoints could become reachable off-host, leaking service presence/port and enabling DoS/brute-force traffic against the relay token header.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected: >= 2026.1.14-1 < 2026.2.12

Fixed Versions

  • Patched: >= 2026.2.12 (released 2026-02-13)

Fix Commit(s)

  • 8d75a496bf5aaab1755c56cf48502d967c75a1d0

Notes

  • Earlier hardening for /json* auth and /cdp token checks landed in:
  • a1e89afcc19efd641c02b24d66d689f181ae2b5c

Thanks @qi-scape for reporting.

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L
6.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2026.1.14-1"
            },
            {
              "fixed": "2026.2.12"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-28395"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327",
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-02-17T17:09:43Z",
    "nvd_published_at": "2026-03-05T22:16:16Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nThe Chrome extension relay (`ensureChromeExtensionRelayServer`) previously treated wildcard hosts (`0.0.0.0` / `::`) as loopback, which could make it bind the relay HTTP/WS server to all interfaces when a wildcard `cdpUrl` was passed.\n\n## Impact\nIf configured with a wildcard `cdpUrl`, relay HTTP endpoints could become reachable off-host, leaking service presence/port and enabling DoS/brute-force traffic against the relay token header.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Affected: `\u003e= 2026.1.14-1 \u003c 2026.2.12`\n\n## Fixed Versions\n- Patched: `\u003e= 2026.2.12` (released 2026-02-13)\n\n## Fix Commit(s)\n- 8d75a496bf5aaab1755c56cf48502d967c75a1d0\n\n## Notes\n- Earlier hardening for `/json*` auth and `/cdp` token checks landed in:\n  - a1e89afcc19efd641c02b24d66d689f181ae2b5c\n\nThanks @qi-scape for reporting.",
  "id": "GHSA-qw99-grcx-4pvm",
  "modified": "2026-03-06T00:58:28Z",
  "published": "2026-02-17T17:09:43Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-qw99-grcx-4pvm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28395"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/8d75a496bf5aaab1755c56cf48502d967c75a1d0"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/a1e89afcc19efd641c02b24d66d689f181ae2b5c"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.2.12"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-unintended-public-binding-of-chrome-extension-relay-via-wildcard-cdpurl"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s Chrome extension relay binds publicly due to wildcard treated as loopback"
}

GHSA-X227-PF99-VFFG

Vulnerability from github – Published: 2026-06-18 13:55 – Updated: 2026-06-18 13:55
VLAI
Summary
PraisonAI: MCP SSE transport binds 0.0.0.0 with no authentication and no Origin validation; bundled SecurityConfig is never wired in
Details

The MCP SSE server started via ToolsMCPServer.run_sse() / launch_tools_mcp_server(transport="sse") binds to 0.0.0.0 by default and builds its Starlette application with no authentication middleware and no Origin-header validation. The module mcp/mcp_security.py provides exactly the needed controls (origin validation, DNS-rebinding detection, auth-header enforcement, a SecurityConfig), but none of these functions are ever called by any transport — they are dead code. Any host that can reach the port can list and invoke every registered tool with no credentials, and a victim's browser can drive the same calls against a localhost instance via DNS rebinding.

Affected code: src/praisonai-agents/praisonaiagents/mcp/mcp_server.py - run_sse defaults host to all interfaces (line 245) and builds the app with only debug and routes - no middleware= and no per-route auth/origin gate (lines ~271-289): app = Starlette(debug=self._debug, routes=[ Route(sse_path, endpoint=handle_sse), # "/sse" Mount(messages_path, app=sse_transport.handle_post_message), # "/messages/" ]) uvicorn.run(app, host=host, port=port) - launch_tools_mcp_server also defaults host="0.0.0.0" (line 301).

src/praisonai-agents/praisonaiagents/mcp/mcp_security.py defines but the transports never call: - is_valid_origin (line 30), is_potential_dns_rebinding (line 110), validate_auth_header (line 167), SecurityConfig.is_origin_allowed (line 236). These symbols are referenced only inside mcp_security.py and the init re-export. (mcp_websocket.py's auth references are CLIENT-side, not server validation.)

Impact: launch_tools_mcp_server(transport="sse") is the documented path for exposing tools over MCP. With the defaults above it is an unauthenticated, network-reachable tool-execution endpoint. Blast radius equals the capabilities of the registered tools; with file/shell/code-exec tools this is RCE. With no Origin check, a malicious page the victim merely visits can rebind its hostname to 127.0.0.1 and issue the JSON-RPC calls cross-origin against a developer's local server.

Proof of concept: Static proof (AST analysis of unmodified source): Check 1 - run_sse(host='0.0.0.0'); launch_tools_mcp_server(host='0.0.0.0') -> EXPOSED Check 2 - Starlette(...) kwargs: ['debug','routes'] -> NO middleware= (no auth/origin gate) Check 3 - is_valid_origin / is_potential_dns_rebinding / validate_auth_header / SecurityConfig never called by any transport -> DEAD CODE Live exploitation against a running server: curl -N http://VICTIM:8080/sse # event: endpoint / data: /messages/?session_id= curl -X POST "http://VICTIM:8080/messages/?session_id=" -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2024-11-05", "capabilities":{},"clientInfo":{"name":"x","version":"1"}}}' curl -X POST "http://VICTIM:8080/messages/?session_id=" -H 'Content-Type: application/json' \ -d '{"jsonrpc":"2.0","id":2,"method":"tools/call","params":{"name":"","arguments":{...}}}' No Authorization header anywhere. Browser DNS-rebinding variant drives the same calls cross-origin.

Remediation: Wire in the existing mcp_security.py controls and fix defaults: - Default run_sse(host="127.0.0.1"); require explicit opt-in to bind 0.0.0.0. - Attach Starlette middleware calling is_valid_origin / is_potential_dns_rebinding; reject bad origins. - Enforce validate_auth_header when SecurityConfig.require_auth; default require_auth=True (and allow_missing_origin=False) for any non-loopback bind.

Distinct from prior advisories: The accepted MCP advisories are tool-handler bugs — tools/call path traversal -> .pth RCE (GHSA-9mqq-jqxf-grvw) and unauthenticated file read via workflow.show/validate (GHSA-9cr9-25q5-8prj). This is a transport-layer missing-auth/exposure: the SSE server never enforces auth or Origin validation and ignores the security module the codebase ships. Closest in spirit to the default-insecure pattern (GHSA-8444 / 86qc) but a different server and a different root cause (unwired controls, not an unset env var).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonaiagents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.59"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327",
      "CWE-306",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T13:55:54Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "The MCP SSE server started via ToolsMCPServer.run_sse() / launch_tools_mcp_server(transport=\"sse\")\nbinds to 0.0.0.0 by default and builds its Starlette application with no authentication middleware\nand no Origin-header validation. The module mcp/mcp_security.py provides exactly the needed controls\n(origin validation, DNS-rebinding detection, auth-header enforcement, a SecurityConfig), but none of\nthese functions are ever called by any transport \u2014 they are dead code. Any host that can reach the\nport can list and invoke every registered tool with no credentials, and a victim\u0027s browser can drive\nthe same calls against a localhost instance via DNS rebinding.\n\nAffected code: src/praisonai-agents/praisonaiagents/mcp/mcp_server.py\n- run_sse defaults host to all interfaces (line 245) and builds the app with only `debug` and `routes`\n  - no `middleware=` and no per-route auth/origin gate (lines ~271-289):\n      app = Starlette(debug=self._debug, routes=[\n          Route(sse_path, endpoint=handle_sse),                          # \"/sse\"\n          Mount(messages_path, app=sse_transport.handle_post_message),   # \"/messages/\"\n      ])\n      uvicorn.run(app, host=host, port=port)\n- launch_tools_mcp_server also defaults host=\"0.0.0.0\" (line 301).\n\nsrc/praisonai-agents/praisonaiagents/mcp/mcp_security.py defines but the transports never call:\n- is_valid_origin (line 30), is_potential_dns_rebinding (line 110), validate_auth_header (line 167),\n  SecurityConfig.is_origin_allowed (line 236). These symbols are referenced only inside mcp_security.py\n  and the __init__ re-export. (mcp_websocket.py\u0027s auth references are CLIENT-side, not server validation.)\n\nImpact:\nlaunch_tools_mcp_server(transport=\"sse\") is the documented path for exposing tools over MCP. With the\ndefaults above it is an unauthenticated, network-reachable tool-execution endpoint. Blast radius equals\nthe capabilities of the registered tools; with file/shell/code-exec tools this is RCE. With no Origin\ncheck, a malicious page the victim merely visits can rebind its hostname to 127.0.0.1 and issue the\nJSON-RPC calls cross-origin against a developer\u0027s local server.\n\nProof of concept:\nStatic proof (AST analysis of unmodified source):\n  Check 1 - run_sse(host=\u00270.0.0.0\u0027); launch_tools_mcp_server(host=\u00270.0.0.0\u0027)  -\u003e EXPOSED\n  Check 2 - Starlette(...) kwargs: [\u0027debug\u0027,\u0027routes\u0027]  -\u003e NO middleware= (no auth/origin gate)\n  Check 3 - is_valid_origin / is_potential_dns_rebinding / validate_auth_header / SecurityConfig\n            never called by any transport  -\u003e DEAD CODE\nLive exploitation against a running server:\n  curl -N http://VICTIM:8080/sse\n  #   event: endpoint  / data: /messages/?session_id=\u003csid\u003e\n  curl -X POST \"http://VICTIM:8080/messages/?session_id=\u003csid\u003e\" -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"jsonrpc\":\"2.0\",\"id\":1,\"method\":\"initialize\",\"params\":{\"protocolVersion\":\"2024-11-05\",\n         \"capabilities\":{},\"clientInfo\":{\"name\":\"x\",\"version\":\"1\"}}}\u0027\n  curl -X POST \"http://VICTIM:8080/messages/?session_id=\u003csid\u003e\" -H \u0027Content-Type: application/json\u0027 \\\n    -d \u0027{\"jsonrpc\":\"2.0\",\"id\":2,\"method\":\"tools/call\",\"params\":{\"name\":\"\u003ctool\u003e\",\"arguments\":{...}}}\u0027\nNo Authorization header anywhere. Browser DNS-rebinding variant drives the same calls cross-origin.\n\nRemediation:\nWire in the existing mcp_security.py controls and fix defaults:\n- Default run_sse(host=\"127.0.0.1\"); require explicit opt-in to bind 0.0.0.0.\n- Attach Starlette middleware calling is_valid_origin / is_potential_dns_rebinding; reject bad origins.\n- Enforce validate_auth_header when SecurityConfig.require_auth; default require_auth=True (and\n  allow_missing_origin=False) for any non-loopback bind.\n\nDistinct from prior advisories:\nThe accepted MCP advisories are tool-handler bugs \u2014 tools/call path traversal -\u003e .pth RCE\n(GHSA-9mqq-jqxf-grvw) and unauthenticated file read via workflow.show/validate (GHSA-9cr9-25q5-8prj).\nThis is a transport-layer missing-auth/exposure: the SSE server never enforces auth or Origin validation\nand ignores the security module the codebase ships. Closest in spirit to the default-insecure pattern\n(GHSA-8444 / 86qc) but a different server and a different root cause (unwired controls, not an unset env var).",
  "id": "GHSA-x227-pf99-vffg",
  "modified": "2026-06-18T13:55:54Z",
  "published": "2026-06-18T13:55:54Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-x227-pf99-vffg"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI: MCP SSE transport binds 0.0.0.0 with no authentication and no Origin validation; bundled SecurityConfig is never wired in"
}
Mitigation
System Configuration

Assign IP addresses that are not 0.0.0.0.

Mitigation
System Configuration

Strategy: Firewall

Unwanted connections to the configured server may be denied through a firewall or other packet filtering measures.

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

← Back to the CWE list