CWE-1327

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "esphome-device-builder"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59177"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-09T23:51:25Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nOn the Home Assistant add-on, the dashboard serves a trusted ingress site that skips authentication because the supervisor authenticates the request upstream. That site was binding `0.0.0.0`. The add-on runs in host network mode for mDNS, so binding all interfaces also bound the host\u0027s LAN interface, and any device on the local network could reach `http://\u003cha-ip\u003e:\u003cingress_port\u003e/` and get the full dashboard with no credentials.\n\n## Details\n\nThe HA add-on ingress site is intentionally unauthenticated: the supervisor\u0027s ingress proxy authenticates the browser upstream, and the dashboard\u0027s threat model assumes the site is reachable only through the supervisor\u0027s docker network. The protection depended on physically binding the site to the supervisor, but the site bound `0.0.0.0` instead. Because the add-on uses host networking, `0.0.0.0` includes the host\u0027s LAN address, so the no-auth site was reachable directly from the LAN, bypassing the supervisor and its authentication entirely.\n\nThis is an auth bypass on a boundary the dashboard explicitly defends. `docs/THREAT_MODEL.md` names, under the surface it still defends, \"anything that lets external traffic reach the ingress site without going through the supervisor.\" The bug is exactly that.\n\nThe fix, in PR #1565, mirrors what the legacy add-on\u0027s nginx did:\n\n- Bind the ingress site to loopback plus the supervisor gateway (`127.0.0.1` and `172.30.32.1`) instead of all interfaces. Loopback serves HA core\u0027s host-network ESPHome integration, which connects to `127.0.0.1:\u003cingress_port\u003e` without credentials by design; the gateway serves the supervisor\u0027s ingress proxy. The LAN interface is no longer bound; an explicit `--ingress-host` still overrides the bind.\n- Add `ingress_peer_guard`, which returns 403 to any TCP peer other than loopback or the supervisor (`172.30.32.2`), so another hassio bridge add-on reaching the gateway cannot use the site either. This mirrors the legacy nginx `allow 127.0.0.1; allow 172.30.32.2; deny all`.\n\nThe password-gated public port (6052) is not affected; this only affects the host-network HA add-on\u0027s ingress port.\n\n## Impact\n\nAny device on the same local network as the Home Assistant host could open the dashboard with no credentials and gain its full authenticated capability. Per `docs/THREAT_MODEL.md`, that capability is host equivalent: an authenticated caller can run arbitrary Python at compile time via `external_components:`, run arbitrary shell through the compile and validation subprocesses, and read or write arbitrary files in the config and data directories. So the practical impact is full compromise of the add-on, including the Home Assistant config directory it mounts and the ESPHome devices it manages.\n\nThe exposure was present by default on every host-network HA add-on install; no operator misconfiguration was required. The standalone Docker dashboard and the password-gated public port are not affected.\n\n\n## Severity rationale\n\nAn unauthenticated network client reaches a dashboard site that performs no authentication of its own, and a client that reaches the dashboard has host equivalent capability. ESPHome\u0027s [threat model](https://github.com/esphome/device-builder/blob/main/docs/THREAT_MODEL.md) documents that a dashboard caller can run arbitrary code at compile time and read or write files in the config and data directories, so confidentiality, integrity, and availability are all High, with no credentials, no user interaction, and low attack complexity. The exposed surface is the Home Assistant host\u0027s local network interface rather than the internet, so the attack vector is adjacent, giving a CVSS base score of 8.8.\n\nThe rating is anchored at the worst case because the exposure was present by default on every host-network HA add-on install, the dominant deployment, and required nothing of the victim. Any party able to reach the host\u0027s local network, including a guest network that is not isolated, an untrusted IoT device, or a compromised local host, obtains full control with a single unauthenticated request.\n\nOperational risk is lower for installations on a single trusted home or business network behind a firewall, since reaching the dashboard there requires an attacker who is already inside that network, and ESPHome is [designed for deployment on trusted networks](https://esphome.io/guides/security_best_practices/) with the network perimeter as the primary defense. That deployment context reduces real world exposure; it does not change the base severity. The ingress site is intended to require the supervisor\u0027s authentication even on the local network, and the fix restores that.\n\n## Patches\n\nFixed in device-builder 1.0.10 (PR #1565). The ingress site is bound to loopback and the supervisor gateway only, and a peer guard rejects any TCP peer other than loopback or the supervisor regardless of `--ingress-host`. The esphome container delivers the fix by bundling device-builder 1.0.10 or newer.\n\n## Workarounds\n\nUpgrade to 1.0.10 or newer (an esphome container bundling device-builder 1.0.10+). Without upgrading, restrict access to the add-on\u0027s ingress port at the network layer, for example a host or router firewall rule that allows only the Home Assistant host and the supervisor to reach it, and keep the Home Assistant host on a trusted LAN segment. Accessing the dashboard through Home Assistant\u0027s normal ingress URL is unaffected and stays authenticated.\n\n## Resources\n\n- Fix: esphome/device-builder#1565\n- Ingress site introduction: esphome/device-builder#25\n- Originating investigation: esphome/device-builder#1560\n- ESPHome security best practices: https://esphome.io/guides/security_best_practices/",
  "id": "GHSA-vv4j-m4vr-f3g6",
  "modified": "2026-09-09T23:51:25Z",
  "published": "2026-09-09T23:51:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/security/advisories/GHSA-vv4j-m4vr-f3g6"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/pull/1565"
    },
    {
      "type": "WEB",
      "url": "https://github.com/esphome/device-builder/commit/b6387db3f8bf1d3df5771f40e9856b959ae4f6a1"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/esphome/device-builder"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "ESPHome Device Builder Dashboard: Unauthenticated dashboard access via the HA add-on ingress site bound to all interfaces"
}

{
  "affected": [],
  "aliases": [
    "CVE-2026-16713"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-13T20:17:14Z",
    "severity": "MODERATE"
  },
  "details": "IBM Documentation Offline 1.0.0 through 1.4.1 IBM Documentation could allow a remote attacker to obtain sensitive information due to a security misconfiguration where the documentation server binds to an unrestricted IP address.",
  "id": "GHSA-wv43-5q36-5wg7",
  "modified": "2026-08-13T21:36:05Z",
  "published": "2026-08-13T21:36:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-16713"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7283484"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonaiagents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.59"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-57123"
  ],
  "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-07-20T21:25:09Z",
  "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"
}