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.
4755 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-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-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"
}
]
}
GHSA-FVCV-3M26-PCQX
Vulnerability from github – Published: 2026-04-10 19:47 – Updated: 2026-05-20 00:25Vulnerability Disclosure: Unrestricted Cloud Metadata Exfiltration via Header Injection Chain
Summary
The Axios library is vulnerable to a specific gadget-style attack chain in which prototype pollution in a third-party dependency may be leveraged to inject unsanitized header values into outbound requests.
Axios can be used as a gadget after pollution occurs elsewhere because header values merged from attacker-controlled prototype properties are not sanitized for CRLF (\r\n) characters before being written to the request. In affected deployments, this may enable limited request manipulation or metadata access as part of a higher-complexity exploit chain.
Severity: Moderate (CVSS 3.1 Base Score: 4.8)
Affected Versions: All versions (v0.x - v1.x)
Vulnerable Component: lib/adapters/http.js (Header Processing)
Usage of \"Helper\" Vulnerabilities
This issue requires a separate prototype pollution vulnerability in another library in the application stack (for example, qs, minimist, ini, or body-parser). If an attacker can pollute Object.prototype, Axios may pick up the polluted properties during config merge.
Because Axios does not sanitise these merged header values for CRLF (\r\n) characters, the polluted property can alter the structure of an outbound HTTP request.
Proof of Concept
1. The Setup (Simulated Pollution)
Imagine a scenario where a known vulnerability exists in a query parser. The attacker sends a payload that sets:
Object.prototype['x-amz-target'] = \"dummy\r\n\r\nPUT /latest/api/token HTTP/1.1\r\nHost: 169.254.169.254\r\nX-aws-ec2-metadata-token-ttl-seconds: 21600\r\n\r\nGET /ignore\";
2. The Gadget Trigger (Safe Code)
The application makes a completely safe, hardcoded request:
// This looks safe to the developer
await axios.get('https://analytics.internal/pings');
3. The Execution
Axios merges the prototype property x-amz-target into the request headers. It then writes the header value directly to the socket without validation.
Resulting HTTP traffic:
GET /pings HTTP/1.1
Host: analytics.internal
x-amz-target: dummy
PUT /latest/api/token HTTP/1.1
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600
GET /ignore HTTP/1.1
...
4. The Impact
In environments where requests can reach cloud metadata endpoints or sensitive internal services, the injected header content may help bypass expected request constraints and expose limited credentials or modify request semantics. This impact depends on application context and a separate prototype-pollution primitive.
Impact Analysis
- Confidentiality: May expose limited sensitive information in affected network environments.
- Integrity: May allow modification of outbound request structure or injected headers.
- Attack Complexity: Exploitation requires a separate prototype-pollution vulnerability and a reachable target service.
Recommended Fix
Validate all header values in lib/adapters/http.js and xhr.js before passing them to the underlying request function.
Patch Suggestion:
// In lib/adapters/http.js
utils.forEach(requestHeaders, function setRequestHeader(val, key) {
if (/[\r\n]/.test(val)) {
throw new Error('Security: Header value contains invalid characters');
}
// ... proceed to set header
});
References
- OWASP: CRLF Injection (CWE-113)
This report was generated as part of a security audit of the Axios library.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "1.0.0"
},
{
"fixed": "1.15.0"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "npm",
"name": "axios"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.31.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-40175"
],
"database_specific": {
"cwe_ids": [
"CWE-113",
"CWE-444",
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-04-10T19:47:16Z",
"nvd_published_at": "2026-04-10T20:16:22Z",
"severity": "MODERATE"
},
"details": "# Vulnerability Disclosure: Unrestricted Cloud Metadata Exfiltration via Header Injection Chain\n\n## Summary\nThe Axios library is vulnerable to a specific gadget-style attack chain in which **prototype pollution** in a third-party dependency may be leveraged to inject unsanitized header values into outbound requests.\n\nAxios can be used as a gadget after pollution occurs elsewhere because header values merged from attacker-controlled prototype properties are not sanitized for CRLF (`\\r\\n`) characters before being written to the request. In affected deployments, this may enable limited request manipulation or metadata access as part of a higher-complexity exploit chain.\n\n**Severity**: Moderate (CVSS 3.1 Base Score: 4.8)\n**Affected Versions**: All versions (v0.x - v1.x)\n**Vulnerable Component**: `lib/adapters/http.js` (Header Processing)\n\n## Usage of \\\"Helper\\\" Vulnerabilities\nThis issue requires a separate **prototype pollution** vulnerability in another library in the application stack (for example, `qs`, `minimist`, `ini`, or `body-parser`). If an attacker can pollute `Object.prototype`, Axios may pick up the polluted properties during config merge.\n\nBecause Axios does not sanitise these merged header values for CRLF (`\\r\\n`) characters, the polluted property can alter the structure of an outbound HTTP request.\n\n## Proof of Concept\n\n### 1. The Setup (Simulated Pollution)\nImagine a scenario where a known vulnerability exists in a query parser. The attacker sends a payload that sets:\n```javascript\nObject.prototype[\u0027x-amz-target\u0027] = \\\"dummy\\r\\n\\r\\nPUT /latest/api/token HTTP/1.1\\r\\nHost: 169.254.169.254\\r\\nX-aws-ec2-metadata-token-ttl-seconds: 21600\\r\\n\\r\\nGET /ignore\\\";\n```\n\n### 2. The Gadget Trigger (Safe Code)\nThe application makes a completely safe, hardcoded request:\n```javascript\n// This looks safe to the developer\nawait axios.get(\u0027https://analytics.internal/pings\u0027); \n```\n\n### 3. The Execution\nAxios merges the prototype property `x-amz-target` into the request headers. It then writes the header value directly to the socket without validation.\n\n**Resulting HTTP traffic:**\n```http\nGET /pings HTTP/1.1\nHost: analytics.internal\nx-amz-target: dummy\n\nPUT /latest/api/token HTTP/1.1\nHost: 169.254.169.254\nX-aws-ec2-metadata-token-ttl-seconds: 21600\n\nGET /ignore HTTP/1.1\n...\n```\n\n### 4. The Impact\nIn environments where requests can reach cloud metadata endpoints or sensitive internal services, the injected header content may help bypass expected request constraints and expose limited credentials or modify request semantics. This impact depends on application context and a separate prototype-pollution primitive.\n\n## Impact Analysis\n- **Confidentiality**: May expose limited sensitive information in affected network environments.\n- **Integrity**: May allow modification of outbound request structure or injected headers.\n- **Attack Complexity**: Exploitation requires a separate prototype-pollution vulnerability and a reachable target service.\n\n## Recommended Fix\nValidate all header values in `lib/adapters/http.js` and `xhr.js` before passing them to the underlying request function.\n\n**Patch Suggestion:**\n```javascript\n// In lib/adapters/http.js\nutils.forEach(requestHeaders, function setRequestHeader(val, key) {\n if (/[\\r\\n]/.test(val)) {\n throw new Error(\u0027Security: Header value contains invalid characters\u0027);\n }\n // ... proceed to set header\n});\n```\n\n## References\n- **OWASP**: CRLF Injection (CWE-113)\n\nThis report was generated as part of a security audit of the Axios library.",
"id": "GHSA-fvcv-3m26-pcqx",
"modified": "2026-05-20T00:25:27Z",
"published": "2026-04-10T19:47:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/axios/axios/security/advisories/GHSA-fvcv-3m26-pcqx"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40175"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/pull/10660"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/pull/10660#issuecomment-4224168081"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/pull/10688"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/commit/03cdfc99e8db32a390e12128208b6778492cee9c"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/commit/363185461b90b1b78845dc8a99a1f103d9b122a1"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-876049.html"
},
{
"type": "PACKAGE",
"url": "https://github.com/axios/axios"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v0.31.0"
},
{
"type": "WEB",
"url": "https://github.com/axios/axios/releases/tag/v1.15.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "Axios has Unrestricted Cloud Metadata Exfiltration via Header Injection Chain"
}
GHSA-FVCW-9W9R-PXC7
Vulnerability from github – Published: 2026-03-11 00:24 – Updated: 2026-04-10 17:33Description: Flowise exposes an HTTP Node in AgentFlow and Chatflow that performs server-side HTTP requests using user-controlled URLs. By default, there are no restrictions on target hosts, including private/internal IP ranges (RFC 1918), localhost, or cloud metadata endpoints. This enables Server-Side Request Forgery (SSRF), allowing any user interacting with a publicly exposed chatflow to force the Flowise server to make requests to internal network resources that are inaccessible from the public internet.
Impact includes: - Access to internal admin panels (e.g., internal company dashboards, Jenkins, Kubernetes API, etc.). - Retrieval of cloud provider metadata (e.g., AWS IMDSv1 at [http://169.254.169.254], GCP, Azure). - Port scanning and enumeration of internal services. - Potential lateral movement or privilege escalation in compromised environments.
This vulnerability is particularly severe because: - Flowise instances are often deployed publicly without authentication (FLOWISE_USERNAME/PASSWORD not set by default). - The HTTP Node is easily accessible in simple flows with minimal configuration.
Proof of Concept (PoC):
A minimal flow consisting of three nodes demonstrates successful internal network access:
Flow Structure:
HTTP Node Configuration:
The HTTP Node is configured to perform a GET request to an internal address on localhost:
URL: http://127.0.0.1:8000 (or any internal service)
Successful Response from Internal Service:
When the flow is triggered via chat input, the Flowise server successfully retrieves and returns content from the internal mock server running on port 8000 within the same container/network:
Impact This is a Server-Side Request Forgery (SSRF) vulnerability with both read and write capabilities. The HTTP Request node supports all standard HTTP methods (GET, POST, PUT, PATCH, DELETE), allowing attackers to not only retrieve sensitive information but also modify, create, or delete data on internal services if those services expose mutable endpoints: - Read access: Retrieval of sensitive internal data, cloud provider metadata (e.g., AWS IAM credentials at http://169.254.169.254/latest/meta-data/iam/security-credentials/), secrets, configuration files, or database contents. - Write access: Modification or deletion of internal resources via POST/PUT/PATCH/DELETE methods (e.g., creating malicious users/configurations, overwriting files, deleting data, triggering destructive actions on internal admin panels, CI/CD systems like Jenkins, Kubernetes APIs, or cloud management interfaces). Amplification: Retrieved cloud credentials can be used for further privilege escalation or lateral movement outside the n8n instance.
Suggested Long-term Fix (for Flowise): - Add optional security controls to HTTP Node: - Toggle: "Block private IP ranges and localhost" (enabled by default). - Field: "Allowed domains" (whitelist). - Display prominent warning when URL field uses template variables (e.g., {{ }}). - Update documentation with explicit SSRF risks and best practices.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.12"
},
"package": {
"ecosystem": "npm",
"name": "flowise"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.13"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.0.12"
},
"package": {
"ecosystem": "npm",
"name": "flowise-components"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.0.13"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-31829"
],
"database_specific": {
"cwe_ids": [
"CWE-918"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-11T00:24:05Z",
"nvd_published_at": "2026-03-10T22:16:20Z",
"severity": "HIGH"
},
"details": "**Description:**\nFlowise exposes an HTTP Node in AgentFlow and Chatflow that performs server-side HTTP requests using user-controlled URLs. By default, there are no restrictions on target hosts, including private/internal IP ranges (RFC 1918), localhost, or cloud metadata endpoints.\nThis enables Server-Side Request Forgery (SSRF), allowing any user interacting with a publicly exposed chatflow to force the Flowise server to make requests to internal network resources that are inaccessible from the public internet.\n\n**Impact includes:**\n- Access to internal admin panels (e.g., internal company dashboards, Jenkins, Kubernetes API, etc.).\n- Retrieval of cloud provider metadata (e.g., AWS IMDSv1 at [http://169.254.169.254], GCP, Azure).\n- Port scanning and enumeration of internal services.\n- Potential lateral movement or privilege escalation in compromised environments.\n\nThis vulnerability is particularly severe because:\n- Flowise instances are often deployed publicly without authentication (FLOWISE_USERNAME/PASSWORD not set by default).\n- The HTTP Node is easily accessible in simple flows with minimal configuration.\n\n**Proof of Concept (PoC):**\nA minimal flow consisting of three nodes demonstrates successful internal network access:\nFlow Structure:\n\u003cimg width=\"1131\" height=\"323\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f6ddc74f-3ae9-4376-995a-693fb272627a\" /\u003e\nHTTP Node Configuration:\nThe HTTP Node is configured to perform a GET request to an internal address on localhost:\nURL: http://127.0.0.1:8000 (or any internal service)\n\u003cimg width=\"568\" height=\"759\" alt=\"image\" src=\"https://github.com/user-attachments/assets/a5735e1f-f735-4d01-9d72-a772963254c8\" /\u003e\n\nSuccessful Response from Internal Service:\nWhen the flow is triggered via chat input, the Flowise server successfully retrieves and returns content from the internal mock server running on port 8000 within the same container/network:\n\u003cimg width=\"377\" height=\"627\" alt=\"image\" src=\"https://github.com/user-attachments/assets/ff3fcfc6-4957-4aae-9c9d-13b4fca1d0ef\" /\u003e\n\n\n**Impact**\nThis is a Server-Side Request Forgery (SSRF) vulnerability with both read and write capabilities.\nThe HTTP Request node supports all standard HTTP methods (GET, POST, PUT, PATCH, DELETE), allowing attackers to not only retrieve sensitive information but also modify, create, or delete data on internal services if those services expose mutable endpoints:\n- Read access: Retrieval of sensitive internal data, cloud provider metadata (e.g., AWS IAM credentials at http://169.254.169.254/latest/meta-data/iam/security-credentials/), secrets, configuration files, or database contents.\n- Write access: Modification or deletion of internal resources via POST/PUT/PATCH/DELETE methods (e.g., creating malicious users/configurations, overwriting files, deleting data, triggering destructive actions on internal admin panels, CI/CD systems like Jenkins, Kubernetes APIs, or cloud management interfaces).\nAmplification: Retrieved cloud credentials can be used for further privilege escalation or lateral movement outside the n8n instance.\n\n\nSuggested Long-term Fix (for Flowise):\n- Add optional security controls to HTTP Node:\n- Toggle: \"Block private IP ranges and localhost\" (enabled by default).\n- Field: \"Allowed domains\" (whitelist).\n- Display prominent warning when URL field uses template variables (e.g., {{ }}).\n- Update documentation with explicit SSRF risks and best practices.",
"id": "GHSA-fvcw-9w9r-pxc7",
"modified": "2026-04-10T17:33:10Z",
"published": "2026-03-11T00:24:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-fvcw-9w9r-pxc7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-31829"
},
{
"type": "PACKAGE",
"url": "https://github.com/FlowiseAI/Flowise"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L",
"type": "CVSS_V3"
}
],
"summary": "Flowise affected by Server-Side Request Forgery (SSRF) in HTTP Node Leading to Internal Network Access"
}
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.