CWE-918

{
  "affected": [],
  "aliases": [
    "CVE-2025-59436"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-16T06:16:05Z",
    "severity": "LOW"
  },
  "details": "The ip (aka node-ip) package through 2.0.1 (in NPM) might allow SSRF because the IP address value 017700000001 is improperly categorized as globally routable via isPublic. NOTE: this issue exists because of an incomplete fix for CVE-2024-29415.",
  "id": "GHSA-qf5v-q897-m77r",
  "modified": "2025-09-16T15:32:31Z",
  "published": "2025-09-16T15:32:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-59436"
    },
    {
      "type": "WEB",
      "url": "https://github.com/indutny/node-ip/issues/160"
    },
    {
      "type": "WEB",
      "url": "https://cosmosofcyberspace.github.io/CVE-Application-Document.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-47635"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-07T15:16:16Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in WPWebinarSystem WebinarPress allows Server Side Request Forgery. This issue affects WebinarPress: from n/a through 1.33.27.",
  "id": "GHSA-qf94-9355-3gff",
  "modified": "2026-04-01T18:35:04Z",
  "published": "2025-05-07T15:31:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-47635"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/wp-webinarsystem/vulnerability/wordpress-webinarpress-1-33-27-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-37359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-19T23:15:10Z",
    "severity": "HIGH"
  },
  "details": "The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. (CWE-918) \n\n\n\n\u00a0\n\n\n\nHitachi Vantara Pentaho Business Analytics Server versions before 10.2.0.0 and 9.3.0.9, including 8.3.x, do not validate the Host header of incoming HTTP/HTTPS requests.\n\n\n\n\u00a0\n\n\n\nBy providing URLs to unexpected hosts or ports, attackers can make it appear that the server is sending the request, possibly bypassing access controls such as firewalls that prevent the attackers from accessing the URLs directly. The server can be used as a proxy to conduct port scanning of hosts in internal networks, use other URLs such as that can access documents on the system (using file://), or use other protocols such as gopher:// or tftp://, which may provide greater control over the contents of requests.",
  "id": "GHSA-qfm9-r3p9-8hcp",
  "modified": "2025-02-20T00:32:03Z",
  "published": "2025-02-20T00:32:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-37359"
    },
    {
      "type": "WEB",
      "url": "https://support.pentaho.com/hc/en-us/articles/34296789835917--Resolved-Hitachi-Vantara-Pentaho-Business-Analytics-Server-Server-Side-Request-Forgery-Versions-before-10-2-0-0-and-9-3-0-9-including-8-3-x-Impacted-CVE-2024-37359"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2020-7796"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-02-18T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Zimbra Collaboration Suite (ZCS) before 8.8.15 Patch 7 allows SSRF when WebEx zimlet is installed and zimlet JSP is enabled.",
  "id": "GHSA-qfxw-56c6-7pjg",
  "modified": "2026-02-17T21:31:12Z",
  "published": "2022-05-24T17:09:16Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-7796"
    },
    {
      "type": "WEB",
      "url": "https://wiki.zimbra.com/wiki/Zimbra_Releases/8.8.15/P7"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2020-7796"
    }
  ],
  "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"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.6.77"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "praisonaiagents"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.6.78"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-61430"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200",
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-08T16:36:50Z",
    "nvd_published_at": "2026-07-15T17:16:52Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nPraisonAI\u0027s `web_crawl` agent tool performs a server-side HTTP fetch of an agent/attacker-influenced URL. SSRF is meant to be prevented by `_is_safe_crawl_url()`, which resolves the hostname and rejects private/loopback/link-local IPs **at validation time**. The validated value is the URL *string* (not a pinned IP); the fetch backend then **re-resolves the hostname at connection time**. Because validation and connection perform two independent DNS resolutions, a **DNS-rebinding** domain that returns a public IP during validation and an internal IP during the fetch fully bypasses the guard, and the internal HTTP response body is returned to the caller.\n\nThis is **SSRF with internal response disclosure (read-back)** \u2014 not blind SSRF. Runtime-confirmed against PraisonAI 4.6.63; the crawl response returned the controlled internal markers `PRAISONAI_INTERNAL_SECRET_CANARY_7f3a91` / `FAKE_INTERNAL_TOKEN_DO_NOT_USE_7f3a91`. Severity High. Reachable by any actor who can influence the URL an agent crawls (e.g. a chat/bot/agent surface).\n\n## Details\n\n### Affected component\n- Package: `praisonaiagents` (PraisonAI), version **4.6.63**.\n- File: `src/praisonai-agents/praisonaiagents/tools/web_crawl_tools.py`; tool `web_crawl` / `crawl_web` (part of the default bot tool set).\n\n### Vulnerable code / root cause\n\n**Code point 1 \u2014 check-time-only DNS validation, no IP pinning**\n\nPath:\n`src/praisonai-agents/praisonaiagents/tools/web_crawl_tools.py`\n\nFunction:\n`_is_safe_crawl_url`\n\nSnippet:\n```python\nfor info in socket.getaddrinfo(hostname, None):          # resolve at CHECK time\n    ip = ipaddress.ip_address(info[4][0])\n    if (ip.is_loopback or ip.is_private or ip.is_link_local\n            or ip.is_multicast or ip.is_unspecified):\n        return False\nreturn True\n```\nIssue: the guard validates the hostname by resolving it **once at check time**. It does not pin the resolved IP and does not return/forward that IP to the HTTP client. Any later resolution can differ.\n\n**Code point 2 \u2014 guard runs, then the URL *string* is handed to the backend**\n\nFunction:\n`web_crawl`\n\nSnippet:\n```python\nfor u in raw_url_list:\n    if _is_safe_crawl_url(u):       # validate the URL string\n        url_list.append(u)\n...\nresults = _crawl_with_httpx(url_list)   # or _crawl_with_crawl4ai(url_list)\n```\nIssue: attacker-controlled input (`urls`) is validated as a string; the backend then fetches that string and **re-resolves DNS independently** of the guard. There is no shared, pinned IP between check and fetch.\n\n**Code point 3 \u2014 `_crawl_with_httpx` backend re-resolves (redirect re-validation does not stop rebinding)**\n\nFunction:\n`_crawl_with_httpx`\n\nSnippet:\n```python\nwith httpx.Client(follow_redirects=False, timeout=30.0) as client:\n    for _ in range(max_redirects + 1):\n        if not _is_safe_crawl_url(current):   # re-resolves hostname (CHECK)\n            raise ValueError(\"Redirect target failed SSRF validation\")\n        response = client.get(current)        # resolves AGAIN at CONNECT\n```\nIssue: even with per-hop redirect re-validation, `_is_safe_crawl_url(current)` and `client.get(current)` are **two separate DNS resolutions** of the same hostname. A rebinding domain answers public to the check and internal to the connect \u2192 TOCTOU bypass. No IP pinning.\n\n**Code point 4 \u2014 urllib fallback (same function), no per-hop guard**\n\nSnippet:\n```python\nimport urllib.request\nwith urllib.request.urlopen(url, timeout=30) as response:   # re-resolves + auto-follows redirects\n    content = response.read().decode(\u0027utf-8\u0027, errors=\u0027ignore\u0027)\n```\nIssue: when `httpx` is not installed, this fallback inside `_crawl_with_httpx` fetches the URL and auto-follows redirects with no per-hop/per-connect validation. (Results from this function are labelled `\"provider\": \"httpx\"` regardless of which path runs.)\n\n**Code point 5 \u2014 crawl4ai/Chromium backend (confirmed addendum)**\n\nThe crawl4ai backend (`_crawl_with_crawl4ai` \u2192 `crawler.arun(url=url)`, headless Chromium) is also runtime-confirmed affected (browser re-resolves DNS / follows redirects with no per-connect guard). To keep this report focused on the `web_crawl` SSRF guard, the backend-specific evidence is in `SSRF-04_Crawl4AI_SSRF_Backend_Addendum.md`.\n\n### Attack flow\n1. Attacker controls a hostname (e.g. `rebind.lab`) whose authoritative DNS rebinds.\n2. Lookup #1 (the guard) \u2192 a public IP \u2192 `_is_safe_crawl_url()` returns true.\n3. The backend re-resolves \u2192 the attacker\u0027s DNS now answers an internal/private IP (cloud metadata, loopback, internal service).\n4. The backend connects to the internal service and returns its body to the caller \u2192 internal data disclosure.\n\n### Why existing protection is bypassed\n- The guard validates the hostname, not a pinned IP; check and connect resolve independently \u2192 DNS rebinding (TOCTOU) defeats it on every backend.\n- Redirect re-validation (httpx path) re-checks the *hostname* but still re-resolves at connect, so it does not stop rebinding; the urllib fallback and crawl4ai backends have no per-hop guard at all.\n\n### Security boundary\nThe server-side fetch reaches internal/loopback/metadata services not exposed to the attacker and returns their content (CVSS Scope: Changed). Reachable wherever an agent can be induced to crawl an attacker-supplied URL (PR:L). An unauthenticated single-request path to `web_crawl` read-back was not found in 4.6.63 (so PR:N / Critical is not claimed).\n\n## Proof of Concept\n\n### Environment\nReal PraisonAI 4.6.63 in a local Docker runtime; a controlled internal canary service (Docker-internal only, not published) returns synthetic markers; a controlled DNS responder implements rebinding for `rebind.lab`. No public host / real metadata / real secret. Runnable assets: `PraisonAI-Runtime-Repro\\runtime-files\\`.\n\n### Steps to reproduce\n1. Burp Repeater tab `PRAI-05-01-DNS-Rebind-Trigger` \u2192 `127.0.0.1:18080`:\n```http\nPOST /tool/web_crawl HTTP/1.1\nHost: 127.0.0.1:18080\nContent-Type: application/json\n\n{\"url\":\"http://rebind.lab:8081/secret\"}\n```\n2. Send (`PRAI-05-02-DNS-Rebind-Secret-Readback` captures the response). If a send returns the \"blocked\" error, the rebinding DNS auto-resets (~3s) \u2014 resend.\n3. Redirect variant: `PRAI-05-03-Redirect-Trigger` / `PRAI-05-04-Redirect-Secret-Readback` send `{\"url\":\"http://redirector:8082/redirect-to-internal\"}`.\n\n### Expected result\nA safe SSRF guard refuses destinations that resolve to internal/private IPs regardless of DNS timing or redirects, and does not return internal content.\n\n### Actual result\nHTTP 200 with the internal body in the crawl result. Primary evidence is the `provider: \"httpx\"` backend returning the internal canary via DNS rebinding:\n```json\n{\"input_url\":\"http://rebind.lab:8081/secret\",\n \"result\":{\"content\":\"{ ... \\\"secret\\\": \\\"PRAISONAI_INTERNAL_SECRET_CANARY_7f3a91\\\", \\\"token\\\": \\\"FAKE_INTERNAL_TOKEN_DO_NOT_USE_7f3a91\\\" ... }\",\"provider\":\"httpx\"}}\n```\nThe redirect variant returns the same internal markers via a redirect chain (`provider: \"httpx\"`).\n\n### Screenshots\n\n**DNS rebinding read-back**\n\nThe attacker-controlled `rebind.lab` URL is accepted by `web_crawl`, and the PraisonAI response contains the internal canary response body.\n\n\u003cimg width=\"1543\" height=\"785\" alt=\"01-DNS-Rebind-Burp-Readback\" src=\"https://github.com/user-attachments/assets/e86e95dd-3d3a-4bef-b1c6-cb897234a212\" /\u003e\n\n**DNS rebinding runtime evidence**\n\nThe runtime log shows `rebind.lab` first resolving to an allowed/public IP during validation (`guard-pass`), then resolving to an internal Docker IP during the actual fetch (`fetch-hit`). The internal canary receives `GET /secret` from the PraisonAI container.\n\n\u003cimg width=\"1654\" height=\"828\" alt=\"02-DNS-Rebind-DNS-Log-And-Internal-Hit\" src=\"https://github.com/user-attachments/assets/f1d28046-de34-48f0-9bee-bbe26e598d5f\" /\u003e\n\n**Redirect-based SSRF read-back**\n\nThe attacker-controlled redirector URL is accepted by `web_crawl`. PraisonAI follows the redirect and returns the internal canary response body containing `PRAISONAI_INTERNAL_SECRET_CANARY_7f3a91`.\n\n\u003cimg width=\"1540\" height=\"772\" alt=\"03-Redirect-Burp-Readback\" src=\"https://github.com/user-attachments/assets/79eec159-4b9f-44be-a9eb-b15aba35ead8\" /\u003e\n\n**Redirect chain runtime evidence**\n\nThe controlled redirector returns `302 -\u003e http://internal-canary:8081/secret`, and the internal canary receives `GET /secret`, confirming that the server-side client followed the redirect into the internal network.\n\n\u003cimg width=\"1637\" height=\"894\" alt=\"04-Redirect-Internal-Hit-Log\" src=\"https://github.com/user-attachments/assets/1c503e30-9d01-4d32-8658-497f755a969e\" /\u003e\n\n### Reproduction assets\n\nThe attached archive contains the local Docker runtime used to reproduce the issue with controlled canary services only. It does not contain real secrets, real cloud metadata access, or third-party API keys.\n\n[PraisonAI-Runtime-Repro.zip](https://github.com/user-attachments/files/29142379/PraisonAI-Runtime-Repro.zip)\n\n## Impact\nSSRF against internal/loopback/cloud-metadata endpoints with **disclosure of internal HTTP responses** (read-back) to the attacker. Bypasses the project\u0027s SSRF protection on every fetch backend.\n\n## Suggested remediation\n1. Resolve the host once, reject all returned records that are private/loopback/link-local/ULA/CGNAT/metadata, then **connect to that exact validated IP** (pin it; send the original `Host`). Do not let the HTTP client / browser re-resolve.\n2. Apply the same validation + IP pinning to every backend (httpx, urllib fallback, crawl4ai) and every redirect hop.\n3. Disable automatic redirect following (or cap + re-validate each hop with pinning).\n4. Treat IPv4-mapped IPv6, decimal/octal/hex IPs, and CGNAT/non-global ranges as unsafe.",
  "id": "GHSA-qg25-6gc4-48mg",
  "modified": "2026-10-08T16:36:50Z",
  "published": "2026-10-08T16:36:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/MervinPraison/PraisonAI/security/advisories/GHSA-qg25-6gc4-48mg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61430"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62169"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/MervinPraison/PraisonAI"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/praisonai-before-dns-rebinding-ssrf-via-web-crawl"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "PraisonAI: DNS rebinding bypass in `web_crawl` SSRF protection allows internal response disclosure"
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-45250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-06T17:16:12Z",
    "severity": "MODERATE"
  },
  "details": "MrDoc v0.95 and before is vulnerable to Server-Side Request Forgery (SSRF) in the validate_url function of the app_doc/utils.py file.",
  "id": "GHSA-qg2f-vrg7-hr49",
  "modified": "2025-05-06T21:30:48Z",
  "published": "2025-05-06T18:30:39Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-45250"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Anike-x/CVE-2025-45250"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zmister2016/MrDoc"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.17.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "sillytavern"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-46372"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-19T20:09:52Z",
    "nvd_published_at": "2026-05-29T19:16:25Z",
    "severity": "HIGH"
  },
  "details": "## Resolution\n\nSillyTavern 1.18.0 added a generic server-side request filter (Private Request Whitelisting). Since we expect users to use the application in a trusted environment, the filter is disabled by default, however it is strongly advised to be enabled and properly configured when an instance is being hosted over a network, as suggested by a console warning message and an officially published security checklist for administrators.\n\nDocumentation: \n\n- https://docs.sillytavern.app/administration/config-yaml/#private-address-whitelisting\n- https://docs.sillytavern.app/administration/#security-checklist\n\n## Note on future SSRF findings\n\nSince the request filter applies to the entire application, no SSRF vulnerabilities against individual endpoints will be accepted, unless it has been proven that a properly configured and enabled filter can be bypassed in an undocumented way. Only advisories disclosed before the 1.18.0 release will be posted if their concern is SSRF.\n\n## Summary\nSillyTavern 1.17.0 exposes `/api/search/searxng`, which accepts attacker-controlled `baseUrl` and uses it directly to build outbound server-side fetches. An authenticated low-privilege user can point `baseUrl` at an internal or loopback HTTP service and receive the `/search` response body.\n\nConfirmed version: SillyTavern 1.17.0 from the audited source tree. Broader affected versions and patched versions should be confirmed by the maintainer.\n\n## Details\nThe `/api/search/searxng` route in `src/endpoints/search.js` reads `baseUrl` from `request.body` and performs no allowlist, IP range, DNS, or scheme validation before making outbound requests.\n\nCore vulnerable path:\n\n```js\nrouter.post(\u0027/searxng\u0027, async (request, response) =\u003e {\n    const { baseUrl, query, preferences, categories } = request.body;\n    if (!baseUrl || !query) {\n        return response.status(400).send(\u0027Missing required parameters\u0027);\n    }\n\n    const mainPageUrl = new URL(baseUrl);\n    const mainPageRequest = await fetch(mainPageUrl, { headers: visitHeaders });\n    ...\n    const searchUrl = new URL(\u0027/search\u0027, baseUrl);\n    const searchParams = new URLSearchParams();\n    searchParams.append(\u0027q\u0027, query);\n    ...\n    const searchResult = await fetch(searchUrl, { headers: visitHeaders });\n    ...\n    const data = await searchResult.text();\n    return response.send(data);\n});\n```\n\n`src/server-startup.js` mounts this router at `/api/search`, and `src/server-main.js` applies login middleware before the API routes. This means the source is a remote authenticated POST request and the sink is server-side `fetch()` to attacker-selected hosts.\n\n## PoC\nAttacker prerequisites: a valid SillyTavern web session, or access to a deployment where user accounts are disabled.\n\nStart an internal mock service on the target host:\n\n```js\nimport http from \u0027node:http\u0027;\n\nhttp.createServer((req, res) =\u003e {\n  if (req.url === \u0027/\u0027) {\n    res.writeHead(200, { \u0027Content-Type\u0027: \u0027text/html\u0027 });\n    return res.end(\u0027\u003chtml\u003e\u003chead\u003e\u003clink href=\"/client.css\" rel=\"stylesheet\"\u003e\u003c/head\u003e\u003c/html\u003e\u0027);\n  }\n  if (req.url === \u0027/client.css\u0027) {\n    res.writeHead(200, { \u0027Content-Type\u0027: \u0027text/css\u0027 });\n    return res.end(\u0027body{}\u0027);\n  }\n  if (req.url.startsWith(\u0027/search?q=\u0027)) {\n    res.writeHead(200, { \u0027Content-Type\u0027: \u0027text/plain\u0027 });\n    return res.end(\u0027INTERNAL-SEARCH-RESULT\u0027);\n  }\n  res.writeHead(404);\n  res.end(\u0027not found\u0027);\n}).listen(9091, \u0027127.0.0.1\u0027);\n```\n\nThen send:\n\n```http\nPOST /api/search/searxng HTTP/1.1\nHost: TARGET:8000\nCookie: session-...=...\nX-CSRF-Token: \u003ctoken from /csrf-token\u003e\nContent-Type: application/json\n\n{\"baseUrl\":\"http://127.0.0.1:9091/\",\"query\":\"x\"}\n```\n\nResult based on the route logic: SillyTavern first fetches `http://127.0.0.1:9091/`, then fetches `http://127.0.0.1:9091/search?q=x`, and returns `INTERNAL-SEARCH-RESULT` to the attacker.\n\n## Impact\nThis is an authenticated SSRF primitive with arbitrary host and port selection. It can disclose responses from loopback or internal HTTP services reachable from the SillyTavern host and may enable interaction with internal admin panels, development services, cloud metadata endpoints in applicable deployments, or service discovery across private networks.",
  "id": "GHSA-qg89-qwwh-5f3j",
  "modified": "2026-06-09T10:32:23Z",
  "published": "2026-05-19T20:09:52Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/SillyTavern/SillyTavern/security/advisories/GHSA-qg89-qwwh-5f3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-46372"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/SillyTavern/SillyTavern"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SillyTavern: SSRF in SearXNG Search Proxy via Unvalidated baseUrl"
}

{
  "affected": [],
  "aliases": [
    "CVE-2023-26435"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-06-20T08:15:09Z",
    "severity": "MODERATE"
  },
  "details": "It was possible to call filesystem and network references using the local LibreOffice instance using manipulated ODT documents. Attackers could discover restricted network topology and services as well as including local files with read permissions of the open-xchange system user. This was limited to specific file-types, like images. We have improved existing content filters and validators to avoid including any local resources. No publicly available exploits are known.\n\n",
  "id": "GHSA-qg93-cpf3-386g",
  "modified": "2024-01-12T09:30:27Z",
  "published": "2023-06-20T09:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-26435"
    },
    {
      "type": "WEB",
      "url": "https://documentation.open-xchange.com/appsuite/security/advisories/csaf/2023/oxas-adv-2023-0002.json"
    },
    {
      "type": "WEB",
      "url": "https://documentation.open-xchange.com/security/advisories/csaf/oxas-adv-2023-0002.json"
    },
    {
      "type": "WEB",
      "url": "https://software.open-xchange.com/products/appsuite/doc/Release_Notes_for_Patch_Release_6219_7.10.6_2023-03-20.pdf"
    },
    {
      "type": "WEB",
      "url": "http://packetstormsecurity.com/files/173083/OX-App-Suite-SSRF-Resource-Consumption-Command-Injection.html"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2023/Jun/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "nltk"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.9.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-02T15:38:15Z",
    "nvd_published_at": "2026-08-22T15:16:19Z",
    "severity": "MODERATE"
  },
  "details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-3gqm-fcw5-w839. This link is maintained to preserve external references.\n\n## Original Description\nNLTK before 3.10.0 (affected versions \u003c= 3.9.4) contains a server-side request forgery (SSRF) vulnerability in the validate_network_url() function in nltk/pathsec.py. The _resolve_hostname() helper catches OSError and ValueError during socket.getaddrinfo() and returns an empty list; when DNS resolution fails, the validation loop executes no IP checks and the function fails open, allowing urlopen() to proceed without validation. An attacker who can trigger DNS resolution failures or use DNS rebinding can bypass SSRF protections and reach restricted network resources, including cloud metadata endpoints (e.g., 169.254.169.254).",
  "id": "GHSA-qg9p-xrhj-435m",
  "modified": "2026-09-02T15:38:15Z",
  "published": "2026-08-22T15:31:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/nltk/nltk/security/advisories/GHSA-3gqm-fcw5-w839"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63311"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/nltk-before-ssrf-via-dns-resolution-failure"
    }
  ],
  "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"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: nltk: SSRF Fail-Open in validate_network_url() via DNS Resolution Failure",
  "withdrawn": "2026-09-02T15:38:15Z"
}

{
  "affected": [],
  "aliases": [
    "CVE-2022-43699"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-04-15T02:15:00Z",
    "severity": "MODERATE"
  },
  "details": "OX App Suite before 7.10.6-rev30 allows SSRF because e-mail account discovery disregards the deny-list and thus can be attacked by an adversary who controls the DNS records of an external domain (found in the host part of an e-mail address).",
  "id": "GHSA-qgqh-6wpp-27c4",
  "modified": "2024-04-04T03:29:02Z",
  "published": "2023-04-15T03:30:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43699"
    },
    {
      "type": "WEB",
      "url": "https://open-xchange.com"
    },
    {
      "type": "WEB",
      "url": "https://seclists.org/fulldisclosure/2023/Feb/3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}