CWE-918
AllowedServer-Side Request Forgery (SSRF)
Abstraction: Base · Status: Incomplete
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.
6271 vulnerabilities reference this CWE, most recent first.
GHSA-FR6H-4RH3-WC9F
Vulnerability from github – Published: 2026-04-20 18:31 – Updated: 2026-04-20 18:31Vvveb prior to 1.0.8.1 contains a server-side request forgery vulnerability in the oEmbedProxy action of the editor/editor module where the url parameter is passed directly to getUrl() via curl without scheme or destination validation. Authenticated backend users can supply file:// URLs to read arbitrary files readable by the web server process or http:// URLs targeting internal network addresses to probe internal services, with response bodies returned directly to the caller.
{
"affected": [],
"aliases": [
"CVE-2026-34428"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-20T16:16:44Z",
"severity": "HIGH"
},
"details": "Vvveb prior to\u00a01.0.8.1 contains a server-side request forgery vulnerability in the oEmbedProxy action of the editor/editor module where the url parameter is passed directly to getUrl() via curl without scheme or destination validation. Authenticated backend users can supply file:// URLs to read arbitrary files readable by the web server process or http:// URLs targeting internal network addresses to probe internal services, with response bodies returned directly to the caller.",
"id": "GHSA-fr6h-4rh3-wc9f",
"modified": "2026-04-20T18:31:48Z",
"published": "2026-04-20T18:31:48Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34428"
},
{
"type": "WEB",
"url": "https://github.com/givanz/Vvveb/commit/2d356844f37819bf771e7cd5e12a8686975e0b2b"
},
{
"type": "WEB",
"url": "https://github.com/givanz/Vvveb/releases/tag/1.0.8.1"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/vvveb-ssrf-via-oembedproxy"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-FR94-7CQC-VJRQ
Vulnerability from github – Published: 2026-08-11 06:31 – Updated: 2026-08-11 06:31A caller-supplied X-Grafana-URL request header controls the destination of mcp-grafana's outbound requests, and the grafana_api_request tool lets the caller also choose the HTTP method, path, and body. Because the destination is not restricted to the configured Grafana instance, a caller can direct requests at internal, loopback, and link-local network services (including metadata endpoints) and read the responses, resulting in server-side request forgery. The fix for CVE-2026-15583 prevented the configured service-account token from being sent to unintended destinations but did not restrict the destinations themselves.
{
"affected": [],
"aliases": [
"CVE-2026-19516"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T06:17:13Z",
"severity": "CRITICAL"
},
"details": "A caller-supplied X-Grafana-URL request header controls the destination of mcp-grafana\u0027s outbound requests, and the grafana_api_request tool lets the caller also choose the HTTP method, path, and body. Because the destination is not restricted to the configured Grafana instance, a caller can direct requests at internal, loopback, and link-local network services (including metadata endpoints) and read the responses, resulting in server-side request forgery. The fix for CVE-2026-15583 prevented the configured service-account token from being sent to unintended destinations but did not restrict the destinations themselves.",
"id": "GHSA-fr94-7cqc-vjrq",
"modified": "2026-08-11T06:31:19Z",
"published": "2026-08-11T06:31:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-19516"
},
{
"type": "WEB",
"url": "https://grafana.com/security/security-advisories/cve-2026-19516"
}
],
"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:L",
"type": "CVSS_V3"
}
]
}
GHSA-FR96-WC8W-HG4C
Vulnerability from github – Published: 2024-03-29 18:30 – Updated: 2026-04-28 21:34Server-Side Request Forgery (SSRF) vulnerability in Brave Brave Popup Builder.This issue affects Brave Popup Builder: from n/a through 0.6.5.
{
"affected": [],
"aliases": [
"CVE-2024-30453"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-29T17:15:17Z",
"severity": "MODERATE"
},
"details": "Server-Side Request Forgery (SSRF) vulnerability in Brave Brave Popup Builder.This issue affects Brave Popup Builder: from n/a through 0.6.5.",
"id": "GHSA-fr96-wc8w-hg4c",
"modified": "2026-04-28T21:34:26Z",
"published": "2024-03-29T18:30:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-30453"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/vulnerability/brave-popup-builder/wordpress-brave-plugin-0-6-5-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FRFJ-9FCW-2CXW
Vulnerability from github – Published: 2025-12-13 18:30 – Updated: 2025-12-13 18:30The Emplibot – AI Content Writer with Keyword Research, Infographics, and Linking | SEO Optimized | Fully Automated plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.0.9 via the emplibot_call_webhook_with_error() and emplibot_process_zip_data() functions. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.
{
"affected": [],
"aliases": [
"CVE-2025-11970"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-12-13T16:16:45Z",
"severity": "MODERATE"
},
"details": "The Emplibot \u2013 AI Content Writer with Keyword Research, Infographics, and Linking | SEO Optimized | Fully Automated plugin for WordPress is vulnerable to Server-Side Request Forgery in all versions up to, and including, 1.0.9 via the emplibot_call_webhook_with_error() and emplibot_process_zip_data() functions. This makes it possible for authenticated attackers, with Administrator-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
"id": "GHSA-frfj-9fcw-2cxw",
"modified": "2025-12-13T18:30:19Z",
"published": "2025-12-13T18:30:19Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-11970"
},
{
"type": "WEB",
"url": "https://plugins.trac.wordpress.org/changeset?sfp_email=\u0026sfph_mail=\u0026reponame=\u0026old=3398720%40emplibot\u0026new=3398720%40emplibot\u0026sfp_email=\u0026sfph_mail="
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/095c6359-112d-4abc-a69b-a623dfd103c0?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-FRFV-49QC-79R8
Vulnerability from github – Published: 2026-09-04 15:36 – Updated: 2026-09-04 15:36Douyin_TikTok_Download_API through 4.1.2 contains a server-side request forgery vulnerability in the /api/download and /api/hybrid/video_data endpoints that allows unauthenticated attackers to fetch arbitrary URLs by supplying a url query parameter. Attackers can request internal services including cloud metadata endpoints and retrieve response bodies containing sensitive credentials through error messages.
{
"affected": [],
"aliases": [
"CVE-2026-85608"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-04T15:17:41Z",
"severity": "HIGH"
},
"details": "Douyin_TikTok_Download_API through 4.1.2 contains a server-side request forgery vulnerability in the /api/download and /api/hybrid/video_data endpoints that allows unauthenticated attackers to fetch arbitrary URLs by supplying a url query parameter. Attackers can request internal services including cloud metadata endpoints and retrieve response bodies containing sensitive credentials through error messages.",
"id": "GHSA-frfv-49qc-79r8",
"modified": "2026-09-04T15:36:13Z",
"published": "2026-09-04T15:36:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-85608"
},
{
"type": "WEB",
"url": "https://github.com/Evil0ctal/Douyin_TikTok_Download_API/issues/729"
},
{
"type": "WEB",
"url": "https://github.com/Evil0ctal/Douyin_TikTok_Download_API"
},
{
"type": "WEB",
"url": "https://github.com/Evil0ctal/Douyin_TikTok_Download_API/blob/V4.1.2/crawlers/douyin/web/utils.py"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/douyin-tiktok-download-api-4.1.2-ssrf-via-url-parameter"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
"type": "CVSS_V4"
}
]
}
GHSA-FRMC-7GRC-FHJW
Vulnerability from github – Published: 2022-05-14 00:55 – Updated: 2025-05-30 18:30Zoho ManageEngine ADSelfService Plus 5.x before build 5703 has SSRF.
{
"affected": [],
"aliases": [
"CVE-2019-3905"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-01-03T19:29:00Z",
"severity": "CRITICAL"
},
"details": "Zoho ManageEngine ADSelfService Plus 5.x before build 5703 has SSRF.",
"id": "GHSA-frmc-7grc-fhjw",
"modified": "2025-05-30T18:30:34Z",
"published": "2022-05-14T00:55:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3905"
},
{
"type": "WEB",
"url": "https://cds.thalesgroup.com/en/tcs-cert/CVE-2019-3905"
},
{
"type": "WEB",
"url": "https://www.excellium-services.com/cert-xlm-advisory/cve-2019-3905"
},
{
"type": "WEB",
"url": "https://www.manageengine.com/products/self-service-password/release-notes.html#5703"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-FRQ9-3HP2-XVXG
Vulnerability from github – Published: 2025-05-29 06:31 – Updated: 2025-05-29 17:27All versions of the package mcp-markdownify-server are vulnerable to Server-Side Request Forgery (SSRF) via the Markdownify.get() function. An attacker can craft a prompt that, once accessed by the MCP host, can invoke the webpage-to-markdown, bing-search-to-markdown, and youtube-to-markdown tools to issue requests and read the responses to attacker-controlled URLs, potentially leaking sensitive information.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "mcp-markdownify-server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "0.0.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-5276"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2025-05-29T17:27:26Z",
"nvd_published_at": "2025-05-29T05:15:21Z",
"severity": "MODERATE"
},
"details": "All versions of the package mcp-markdownify-server are vulnerable to Server-Side Request Forgery (SSRF) via the Markdownify.get() function. An attacker can craft a prompt that, once accessed by the MCP host, can invoke the webpage-to-markdown, bing-search-to-markdown, and youtube-to-markdown tools to issue requests and read the responses to attacker-controlled URLs, potentially leaking sensitive information.",
"id": "GHSA-frq9-3hp2-xvxg",
"modified": "2025-05-29T17:27:26Z",
"published": "2025-05-29T06:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5276"
},
{
"type": "WEB",
"url": "https://github.com/zcaceres/markdownify-mcp/commit/0284aa8f34d32c65e20d8cda2d429b7943c9af03"
},
{
"type": "PACKAGE",
"url": "https://github.com/zcaceres/markdownify-mcp"
},
{
"type": "WEB",
"url": "https://github.com/zcaceres/markdownify-mcp/blob/224cf89f0d58616d2a5522f60f184e8391d1c9e3/src/server.ts#L20C17-L20C29"
},
{
"type": "WEB",
"url": "https://security.snyk.io/vuln/SNYK-JS-MCPMARKDOWNIFYSERVER-10249387"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:A/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N/E:P",
"type": "CVSS_V4"
}
],
"summary": "Markdownify MCP Server allows Server-Side Request Forgery (SSRF) via the Markdownify.get() function"
}
GHSA-FRVJ-C5QP-XJ4W
Vulnerability from github – Published: 2026-07-24 21:05 – Updated: 2026-07-24 21:05AI assistance was used to help inspect the code and prepare this report.
Summary
The fix for GHSA-r2wg-2mcr-66rv is incomplete in v0.9.6 and current main. backend/open_webui/routers/terminals.py documents _sanitize_proxy_path() as decoding until stable, but the implementation stops after 8 unquote() passes. A 9x percent-encoded ../... path parameter remains once-encoded after the loop, passes the posixpath.normpath() and cleaned.startswith('..') checks, and is forwarded to the configured terminal server. The upstream server then receives a decoded traversal path such as /base/../admin/system.
Impact
A user who has access to an admin-configured terminal connection can bypass the terminal proxy path traversal guard and cause Open WebUI to forward requests with the configured terminal credentials and X-User-Id header to paths outside the intended normalized proxy path. For orchestrator-backed terminal connections the same sanitized path is placed under /p/{policy_id}/{safe_path}, so the bypass can also target sibling or parent routes after upstream decoding. This is a bypass of the same terminal proxy boundary covered by GHSA-r2wg-2mcr-66rv.
This does not require adding a malicious terminal server or convincing an administrator to weaken settings. The attacker only needs normal access to an existing configured terminal connection.
Reproduction
The following standalone Python script mirrors the current sanitizer and uses a local aiohttp server as the terminal-server canary. It shows that 8x encoding is rejected but 9x encoding is accepted and forwarded as a traversal after the upstream framework decodes the path.
import asyncio, posixpath
from urllib.parse import unquote
from aiohttp import web, ClientSession, ClientTimeout
def sanitize(path):
decoded = path
for _ in range(8):
once = unquote(decoded)
if once == decoded:
break
decoded = once
cleaned = posixpath.normpath(decoded).lstrip('/')
if cleaned.startswith('..') or cleaned == '.':
return None
return cleaned
def enc(s, rounds):
out = ''.join(f'%{b:02X}' for b in s.encode())
for _ in range(rounds - 1):
out = out.replace('%', '%25')
return out
async def main():
async def handler(request):
return web.json_response({'raw_path': request.raw_path, 'path': request.path})
app = web.Application()
app.router.add_route('*', '/{tail:.*}', handler)
runner = web.AppRunner(app)
await runner.setup()
site = web.TCPSite(runner, '127.0.0.1', 0)
await site.start()
port = site._server.sockets[0].getsockname()[1]
for rounds in (8, 9):
safe = sanitize(enc('../admin/system', rounds))
print(rounds, safe)
if safe:
url = f'http://127.0.0.1:{port}/base/{safe}'
async with ClientSession(timeout=ClientTimeout(total=10)) as session:
async with session.get(url) as response:
print(await response.json())
await runner.cleanup()
asyncio.run(main())
Observed output on current main and v0.9.6 sanitizer:
8 None
9 %2E%2E%2F%61%64%6D%69%6E%2F%73%79%73%74%65%6D
{'raw_path': '/base/..%2Fadmin%2Fsystem', 'path': '/base/../admin/system'}
The 9x encoded path argument is 285 bytes long, so this is not a megabyte-sized or impractical URL. When sent through the real route, account for the ASGI server decoding the HTTP path once before filling the {path:path} parameter: an external request can use one additional encoding layer so _sanitize_proxy_path() receives the 9x encoded parameter shown above.
Root Cause / Technical Details
_sanitize_proxy_path() in backend/open_webui/routers/terminals.py performs this loop:
decoded = path
for _ in range(8):
once = unquote(decoded)
if once == decoded:
break
decoded = once
The subsequent traversal check is applied only to the value after those 8 iterations. If the input still contains encoded dot and slash bytes after the loop, posixpath.normpath() treats them as ordinary characters rather than path separators. The code then builds target_url = f'{base_url}/{safe_path}' and sends it with aiohttp.ClientSession.request(). The upstream server receives and decodes the forwarded path, turning the accepted %2E%2E%2F... into ../....
The same vulnerable sanitizer is present in v0.9.6, the latest release. I verified the v0.9.6 backend/open_webui/routers/terminals.py hash matches current main for this file.
Remediation
Do not rely on a fixed decode-depth cap for a traversal security boundary. Recommended fixes:
- Decode until stable with a strict input length cap, and reject if the final value still contains encoded dot, slash, or backslash separators.
- Reconstruct the allowed relative path from fully decoded segments: split on path separators, reject empty/current/parent segments, then join allowed segments with
/. - Add regression tests for at least 9x and 10x encoded
../payloads, including a route-level test that accounts for the ASGI server's initial path decode before the{path:path}parameter reaches_sanitize_proxy_path().
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.6"
},
{
"fixed": "0.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-59221"
],
"database_specific": {
"cwe_ids": [
"CWE-22",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-24T21:05:51Z",
"nvd_published_at": "2026-07-09T18:16:55Z",
"severity": "HIGH"
},
"details": "AI assistance was used to help inspect the code and prepare this report.\n\n## Summary\n\nThe fix for GHSA-r2wg-2mcr-66rv is incomplete in v0.9.6 and current main. `backend/open_webui/routers/terminals.py` documents `_sanitize_proxy_path()` as decoding until stable, but the implementation stops after 8 `unquote()` passes. A 9x percent-encoded `../...` path parameter remains once-encoded after the loop, passes the `posixpath.normpath()` and `cleaned.startswith(\u0027..\u0027)` checks, and is forwarded to the configured terminal server. The upstream server then receives a decoded traversal path such as `/base/../admin/system`.\n\n## Impact\n\nA user who has access to an admin-configured terminal connection can bypass the terminal proxy path traversal guard and cause Open WebUI to forward requests with the configured terminal credentials and `X-User-Id` header to paths outside the intended normalized proxy path. For orchestrator-backed terminal connections the same sanitized path is placed under `/p/{policy_id}/{safe_path}`, so the bypass can also target sibling or parent routes after upstream decoding. This is a bypass of the same terminal proxy boundary covered by GHSA-r2wg-2mcr-66rv.\n\nThis does not require adding a malicious terminal server or convincing an administrator to weaken settings. The attacker only needs normal access to an existing configured terminal connection.\n\n## Reproduction\n\nThe following standalone Python script mirrors the current sanitizer and uses a local aiohttp server as the terminal-server canary. It shows that 8x encoding is rejected but 9x encoding is accepted and forwarded as a traversal after the upstream framework decodes the path.\n\n```python\nimport asyncio, posixpath\nfrom urllib.parse import unquote\nfrom aiohttp import web, ClientSession, ClientTimeout\n\ndef sanitize(path):\n decoded = path\n for _ in range(8):\n once = unquote(decoded)\n if once == decoded:\n break\n decoded = once\n cleaned = posixpath.normpath(decoded).lstrip(\u0027/\u0027)\n if cleaned.startswith(\u0027..\u0027) or cleaned == \u0027.\u0027:\n return None\n return cleaned\n\ndef enc(s, rounds):\n out = \u0027\u0027.join(f\u0027%{b:02X}\u0027 for b in s.encode())\n for _ in range(rounds - 1):\n out = out.replace(\u0027%\u0027, \u0027%25\u0027)\n return out\n\nasync def main():\n async def handler(request):\n return web.json_response({\u0027raw_path\u0027: request.raw_path, \u0027path\u0027: request.path})\n app = web.Application()\n app.router.add_route(\u0027*\u0027, \u0027/{tail:.*}\u0027, handler)\n runner = web.AppRunner(app)\n await runner.setup()\n site = web.TCPSite(runner, \u0027127.0.0.1\u0027, 0)\n await site.start()\n port = site._server.sockets[0].getsockname()[1]\n\n for rounds in (8, 9):\n safe = sanitize(enc(\u0027../admin/system\u0027, rounds))\n print(rounds, safe)\n if safe:\n url = f\u0027http://127.0.0.1:{port}/base/{safe}\u0027\n async with ClientSession(timeout=ClientTimeout(total=10)) as session:\n async with session.get(url) as response:\n print(await response.json())\n await runner.cleanup()\n\nasyncio.run(main())\n```\n\nObserved output on current main and v0.9.6 sanitizer:\n\n```text\n8 None\n9 %2E%2E%2F%61%64%6D%69%6E%2F%73%79%73%74%65%6D\n{\u0027raw_path\u0027: \u0027/base/..%2Fadmin%2Fsystem\u0027, \u0027path\u0027: \u0027/base/../admin/system\u0027}\n```\n\nThe 9x encoded path argument is 285 bytes long, so this is not a megabyte-sized or impractical URL. When sent through the real route, account for the ASGI server decoding the HTTP path once before filling the `{path:path}` parameter: an external request can use one additional encoding layer so `_sanitize_proxy_path()` receives the 9x encoded parameter shown above.\n\n## Root Cause / Technical Details\n\n`_sanitize_proxy_path()` in `backend/open_webui/routers/terminals.py` performs this loop:\n\n```python\ndecoded = path\nfor _ in range(8):\n once = unquote(decoded)\n if once == decoded:\n break\n decoded = once\n```\n\nThe subsequent traversal check is applied only to the value after those 8 iterations. If the input still contains encoded dot and slash bytes after the loop, `posixpath.normpath()` treats them as ordinary characters rather than path separators. The code then builds `target_url = f\u0027{base_url}/{safe_path}\u0027` and sends it with `aiohttp.ClientSession.request()`. The upstream server receives and decodes the forwarded path, turning the accepted `%2E%2E%2F...` into `../...`.\n\nThe same vulnerable sanitizer is present in v0.9.6, the latest release. I verified the v0.9.6 `backend/open_webui/routers/terminals.py` hash matches current main for this file.\n\n## Remediation\n\nDo not rely on a fixed decode-depth cap for a traversal security boundary. Recommended fixes:\n\n1. Decode until stable with a strict input length cap, and reject if the final value still contains encoded dot, slash, or backslash separators.\n2. Reconstruct the allowed relative path from fully decoded segments: split on path separators, reject empty/current/parent segments, then join allowed segments with `/`.\n3. Add regression tests for at least 9x and 10x encoded `../` payloads, including a route-level test that accounts for the ASGI server\u0027s initial path decode before the `{path:path}` parameter reaches `_sanitize_proxy_path()`.",
"id": "GHSA-frvj-c5qp-xj4w",
"modified": "2026-07-24T21:05:51Z",
"published": "2026-07-24T21:05:51Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-frvj-c5qp-xj4w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59221"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/pull/26050"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/05098d25a58d03738e01c4e85e8852c3b4ad849c"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.10.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "open-webui terminal proxy path traversal guard bypass via 9x encoded traversal"
}
GHSA-FV5P-P927-QMXR
Vulnerability from github – Published: 2026-04-16 22:53 – Updated: 2026-06-06 00:58Summary
HTMLHeaderTextSplitter.split_text_from_url() validated the initial URL using validate_safe_url() but then performed the fetch with requests.get() with redirects enabled (the default). Because redirect targets were not revalidated, a URL pointing to an attacker-controlled server could redirect to internal, localhost, or cloud metadata endpoints, bypassing SSRF protections.
The response body is parsed and returned as Document objects to the calling application code. Whether this constitutes a data exfiltration path depends on the application: if it exposes Document contents (or derivatives) back to the requester who supplied the URL, sensitive data from internal endpoints could be leaked. Applications that store or process Documents internally without returning raw content to the requester are not directly exposed to data exfiltration through this issue.
Affected versions
langchain-text-splitters< 1.1.2
Patched versions
langchain-text-splitters>= 1.1.2 (requireslangchain-core>= 1.2.31)
Affected code
File: libs/text-splitters/langchain_text_splitters/html.py — split_text_from_url()
The vulnerable pattern validated the URL once then fetched with redirects enabled:
validate_safe_url(url, allow_private=False, allow_http=True)
response = requests.get(url, timeout=timeout, **kwargs)
Attack scenario
- A developer passes external URLs to
split_text_from_url(), relying on its built-invalidate_safe_url()check to block requests to internal networks. - An attacker supplies a URL pointing to a public host they control. The URL
passes
validate_safe_url()(public hostname, public IP). - The attacker's server responds with a
302redirect to an internal endpoint (e.g., an unauthenticated internal admin API, or a cloud instance metadata service that does not require request headers — such as AWS IMDSv1). requests.get()follows the redirect automatically. The redirect target is not revalidated.- The response body is parsed and returned as
Documentobjects to the application.
Notes:
- The core issue is a bypass of an explicitly provided SSRF protection.
split_text_from_url()includedvalidate_safe_url()specifically to be safe with untrusted URLs — the redirect loophole defeated that guarantee. - Cloud metadata endpoints that require special headers (AWS IMDSv2, GCP, Azure) are not reachable through this bug because the attacker does not control request headers. AWS IMDSv1, which requires no headers, is reachable.
- Data exfiltration requires the application to return Document contents to the party that supplied the URL. The SSRF itself — forcing the server to issue a request to an internal endpoint — does not require this.
Fix
The fix replaces requests.get() with an SSRF-safe httpx transport (SSRFSafeSyncTransport from langchain-core) that validates DNS results and pins connections to validated IPs on every request, including redirect targets, eliminating redirect-based bypasses.
Additionally, split_text_from_url() has been deprecated. Users should fetch HTML content themselves and pass it to split_text() directly.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langchain-text-splitters"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-41481"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-16T22:53:32Z",
"nvd_published_at": "2026-04-24T21:16:19Z",
"severity": "MODERATE"
},
"details": "## Summary\n\n`HTMLHeaderTextSplitter.split_text_from_url()` validated the initial URL using `validate_safe_url()` but then performed the fetch with `requests.get()` with redirects enabled (the default). Because redirect targets were not revalidated, a URL pointing to an attacker-controlled server could redirect to internal, localhost, or cloud metadata endpoints, bypassing SSRF protections.\n\nThe response body is parsed and returned as `Document` objects to the calling application code. Whether this constitutes a data exfiltration path depends on the application: if it exposes Document contents (or derivatives) back to the requester who supplied the URL, sensitive data from internal endpoints could be leaked. Applications that store or process Documents internally without returning raw content to the requester are not directly exposed to data exfiltration through this issue.\n\n## Affected versions\n\n- `langchain-text-splitters` \u003c 1.1.2\n\n## Patched versions\n\n- `langchain-text-splitters` \u003e= 1.1.2 (requires `langchain-core` \u003e= 1.2.31)\n\n## Affected code\n\n**File:** `libs/text-splitters/langchain_text_splitters/html.py` \u2014 `split_text_from_url()`\n\nThe vulnerable pattern validated the URL once then fetched with redirects enabled:\n\n```python\nvalidate_safe_url(url, allow_private=False, allow_http=True)\nresponse = requests.get(url, timeout=timeout, **kwargs)\n```\n\n## Attack scenario\n\n1. A developer passes external URLs to `split_text_from_url()`, relying on its\n built-in `validate_safe_url()` check to block requests to internal networks.\n2. An attacker supplies a URL pointing to a public host they control. The URL\n passes `validate_safe_url()` (public hostname, public IP).\n3. The attacker\u0027s server responds with a `302` redirect to an internal endpoint\n (e.g., an unauthenticated internal admin API, or a cloud instance metadata\n service that does not require request headers \u2014 such as AWS IMDSv1).\n4. `requests.get()` follows the redirect automatically. The redirect target is\n **not** revalidated.\n5. The response body is parsed and returned as `Document` objects to the\n application.\n\n**Notes:**\n\n- The core issue is a bypass of an explicitly provided SSRF protection.\n `split_text_from_url()` included `validate_safe_url()` specifically to be\n safe with untrusted URLs \u2014 the redirect loophole defeated that guarantee.\n- Cloud metadata endpoints that require special headers (AWS IMDSv2, GCP, Azure)\n are not reachable through this bug because the attacker does not control\n request headers. AWS IMDSv1, which requires no headers, is reachable.\n- Data exfiltration requires the application to return Document contents to the\n party that supplied the URL. The SSRF itself \u2014 forcing the server to issue a\n request to an internal endpoint \u2014 does not require this.\n\n## Fix\n\nThe fix replaces `requests.get()` with an SSRF-safe httpx transport (`SSRFSafeSyncTransport` from `langchain-core`) that validates DNS results and pins connections to validated IPs on every request, including redirect targets, eliminating redirect-based bypasses.\n\nAdditionally, `split_text_from_url()` has been deprecated. Users should fetch HTML content themselves and pass it to `split_text()` directly.",
"id": "GHSA-fv5p-p927-qmxr",
"modified": "2026-06-06T00:58:49Z",
"published": "2026-04-16T22:53:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/langchain-ai/langchain/security/advisories/GHSA-fv5p-p927-qmxr"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41481"
},
{
"type": "PACKAGE",
"url": "https://github.com/langchain-ai/langchain"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/langchain-text-splitters/PYSEC-2026-77.yaml"
}
],
"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": "LangChain Text Splitters: HTMLHeaderTextSplitter.split_text_from_url SSRF Redirect Bypass"
}
GHSA-FV99-5WJ3-4752
Vulnerability from github – Published: 2024-08-13 18:31 – Updated: 2024-08-13 18:31An authenticated attacker can exploit an Server-Side Request Forgery (SSRF) vulnerability in Microsoft Azure Health Bot to elevate privileges over a network.
{
"affected": [],
"aliases": [
"CVE-2024-38109"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-08-13T18:15:11Z",
"severity": "CRITICAL"
},
"details": "An authenticated attacker can exploit an Server-Side Request Forgery (SSRF) vulnerability in Microsoft Azure Health Bot to elevate privileges over a network.",
"id": "GHSA-fv99-5wj3-4752",
"modified": "2024-08-13T18:31:16Z",
"published": "2024-08-13T18:31:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38109"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38109"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-664: Server Side Request Forgery
An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.